[pulseaudio-discuss] Underruns when changing sinks on a 'live stream'

[Alejandro Gonzalez]

> > I'm seeing to different behaviors here:
> > 
> > 1) using only 'paplay my_file.wav': I couldn't see progressive
> > audio-degradation or a progressive increase of Underruns, but after
> > several profile switches I hit a state where the audio is only noise.
> > Subsequent playbacks are all noisy. Only after setting a again a new
> > profile audio was rendered properly, 
> > 
> > 2) using gstreamer: After 4-5 profile switching audio start to degrade
> > with glitches and Underruns messages increase with each profile switch.
> > But, if I let the playback finish and I start a new one, audio is fine
> > again, without switching profiles again. 
> > 
> > So, if you can help me with a couple of functions names I can start
> > adding some debug traces. I assume that when the stream is rerouted to a
> > new sink, part of the old buffer has to be copied to the new sink
> > buffer, right? Maybe there is a bug in this procedure, but I'm not sure
> > where to start looking at. 
> 
> Nice, thanks for trying to pin this down. I'd suggest you start with
> figuring out where the rewind is happening in
> pulsecore/protocol-native.c (there are a bunch of callers to
> handle_seek() which is what spits the message you see in debug logs).
> 
Hi Arun, 

So far this is what I can see just before the Underruns start (obviously
after is starts rendering on the new sink):

D: protocol-native.c: SINK_INPUT_MESSAGE_UPDATE_LATENCY
D: protocol-native.c: command_get_playback_latency 
D: protocol-native.c: Underrun on ''Aerodynamic' by 'Daft Punk'', 0
bytes in queue.
D: protocol-native.c: SINK_INPUT_MESSAGE_UPDATE_LATENCY
D: protocol-native.c: pstream_memblock_callback 
D: protocol-native.c: command_get_playback_latency 
D: protocol-native.c: sink_input_process_msg 11 SINK_INPUT_MESSAGE_SEEK
D: protocol-native.c: Requesting rewind due to rewrite.
D: alsa-sink.c: Requested to rewind 17304 bytes.
D: alsa-sink.c: Limited to 7616 bytes.

The sequence of call is:

pstream_memblock_callback-> command_get_playback_latency ->
sink_input_process_msg -> handle_seek 

The event sent to 'process_msg' is SINK_INPUT_MESSAGE_SEEK but
previously there are always a couple of
'SINK_INPUT_MESSAGE_UPDATE_LATENCY' messages.

I'll focus on find out who triggers the 'UPDATE_LATENCY' message.

Any comments are welcome,

Regards, 

Alejandro