xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Changes between Initial Version and Version 1 of Ticket #849, comment 28


Ignore:
Timestamp:
08/27/15 17:31:45 (6 years ago)
Author:
Antoine Martin
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #849, comment 28

    initial v1  
    11Replying to [comment:27 antoine]:
    22> @pvenkateswaralu: I don't know what the "default codec" is, as this will vary depending on what codecs you have installed and what the server supports.
    3 >
    4 > [[BR]]
    5 >
    6 > {{{
    7 > sound-source pipeline warning: Can't record audio fast enough
    8 > sound-source pipeline warning: ["gstbaseaudiosrc.c(840): gst_base_audio_src_create (): \
    9 >     /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:\nDropped 1080640 samples. \
    10 >     This is most likely because downstream can't keep up and is consuming samples too slowly."]
    11 > }}}
    12 > [[BR]]
    13 > That's interesting. If the buffers accumulate too quickly, we do drop them, but we do this in the gstreamer capture element at the end of the compression pipeline (aka "appsink") not in the soundcard capture element at the beginning of the pipeline (aka "pulsesrc" on Linux).
    14 > The pipeline goes something like this: pulsesrc -> audioconvert (changes sample rate, etc) -> volume control -> encoder -> container -> capture (appsink).
    15 >
    16 > So my guess is that the compression is taking too long.. And I don't want to add a queue element in this pipeline, as this adds latency and is difficult enough to deal with client side (that's the point of this ticket).
    17 > We may have an issue if the CPU is not capable of compressing in realtime. Most modern CPUs are more than fast enough to compress sound in realtime no matter what encoding is used. So I am tempted to just make a note of this and hope for the best.
    18 >
    19 >
    20 > [[BR]]
    21 > > When I started the mp3 player in addition to the video, I heard another short stutter, but didn't see any sign of output either client or server side.
    22 > [[BR]]
    23 > Does this show up on the latency graph as a spike?
    24 > If you can reproduce, you may want to run the client and/or server with {{{-d sound}}} and capture the few KB of log output around the time of the event, then look for underruns or overruns in the output. Those events are no longer logged at "info" level, only at "debug" level because the new sound code triggers them far too often.
    25 >
    26 > [[BR]]
    27 > > I then tried to start the server with {{{--speaker-codec=mp3}}}, but checking in the session info I saw that it was listing the microphone codec as being mp3, but the speaker codecs as unaffected.
    28 > [[BR]]
    29 > Thanks, that's fixed in r10454.
    30 >
    31 > This graph shows a spike in latency (probably as you started scrolling):
    32 > [[Image(ticket849_0-16-0-r10442-win_r10306-fedora21_youtube-music-while-scrolling.PNG)]]
    33 > * did you hear any crackling?
    34 > * did the level come back down again later?
    35 >
    36 > This graph shows the latency going through the roof:
    37 > [[Image(ticket849_0-16-0-r10442-win_r10306-fedora21_youtube-music_video-fullscreen-4K.PNG)]]
    38 > So I don't think we should worry too much about the sound doing badly in this case, we should deal with the underlying problem instead which is that the encode+send takes far too long (over 2 seconds!). Can you please file a separate ticket for this?
    39 >
    40 > All the other graphs look fairly normal to me: the latency is in the 50 to 150ms range which is fine.
    41 >
    42 > The xpra info looks about right. FYI: the important bits are found using:
    43 > {{{
    44 > $ xpra info | grep client.speaker
    45 > client.speaker.buffers=4829
    46 > client.speaker.bytes=971134
    47 > client.speaker.caps={'application/x-gdp': {}}
    48 > client.speaker.codec=vorbis
    49 > client.speaker.codec_description=Vorbis
    50 > client.speaker.pid=11353
    51 > client.speaker.pipeline=pulsesrc ! volume name=volume volume=1.0 ! vorbisenc ! gdppay crc-payload=0 crc-header=0 ! appsink name=sink emit-signals=true max-buffers=10 drop=true sync=false async=false qos=false
    52 > client.speaker.state=active
    53 > client.speaker.time=1440641552
    54 > client.speaker.volume=100
    55 > }}}
    56 >
    57 >
    58 > As per comment:14 :
    59 > * do you see the level going back down again after a spike
    60 > * testing with wifi / slower / bad network conditions
    61 > * testing the other codecs
    62 > * compatibility with older clients and servers
    63 > * etc..
    64 >
    65 >
    66 >
    67 > PS: r10451 is the final code cleanup which completely separates the gstreamer bits from the main process, it even prevents the gstreamer bindings from ever being imported into the main process by accident.
    68 > This should have no user visible changes, but will reduce the memory footprint of the client and server quite a bit. (though the same libraries will still be imported by the sound helper subprocess when used)
    69 
    703
    714@antoine: The default speaker codec is the "Vorbis".