> > 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
