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

[Alejandro Gonzalez]

> [Please create a new message rather than replying next time as it
messes
> up the threading :)]

Thanks for the quick reply and sorry for messing up with other threads.
Not intentional.

> Hiya


>'Twas brillig, and Alejandro Gonzalez at 01/06/11 00:17 did gyre and
gimble:
>> Hi there, 
>> 
>> I'm new to PA so please forgive me if what I said have no much sense.
>> 
>> I'm using PA 0.9.22 + UCM patches from Margarita Olaya in an Ubuntu
>> Maverik FS. And I have an alsa UCM profile that sets the playback
>> controls and define 2 devices (Headset and Handset), so I can
manually
>> change between these two profiles using gnome-sound-preferences. PA
>> shows them as different profiles Playback__Handset and
>> Playback__Headset.
>> 
>> The issue is that if I change profiles on a 'live stream' the audio
is
>> correctly routed every time, but after a couple of tries it starts to
>> get distorted and I can see a lot of buffer underruns and 'Requested
to
>> rewind'. 
>> 
>> I know there is a 'module-rescue-streams' that does the stream
>> 're-routing' when the sink it is playing at dies, and this is exactly
>> what happens when I do change profiles, the old-sink is deleted and a
>> new sink is created, both have the same properties but a different
name
>> and each one set different alsa controls. 
>> 
>> D: sink.c: Processing rewind...
>> D: sink-input.c: Have to rewind 208 bytes on render memblockq.
>> D: sink-input.c: Have to rewind 184 bytes on implementor.
>> D: source.c: Processing rewind...
>> E: protocol-native.c: handle_seek: 0 -- 1
>> D: protocol-native.c: Requesting rewind due to rewrite.
>> D: alsa-sink.c: Requested to rewind 1360 bytes.
>> D: alsa-sink.c: Limited to 1360 bytes.
>> D: alsa-sink.c: before: 170
>> D: alsa-sink.c: after: 170
>> D: alsa-sink.c: Rewound 1360 bytes.
>> D: sink.c: Processing rewind...
>> D: sink-input.c: Have to rewind 1360 bytes on render memblockq.
>> D: sink-input.c: Have to rewind 1256 bytes on implementor.
>> 
>> 
>> I'm playing the file with a simple gstreamer pipeline:
>> 
>> gst-launch playbin2
>> uri=file:///home/ubuntu/DaftPunk_Homework_AroundTheWorld.mp3
>> 
>> So my questions are:
>> Can I fix the 'Underruns' increasing the default latency or buffer
size?
>> if so, Can I do this through a configuration parameter in
>> default.pa/daemon.conf/client.conf?
>> 
>> Or is this 'on-the-fly' sink change simply not supported?
>> and the 'module-rescue-streams' is not really a feature but a
'security
>> harness'?
>
> It very much should work as you expect, but somewhere along the lines
> something is messing up :s

> I'm not sure of the top of my head but I just wanted to reply to you
to
> let you know that the move itself should not be affecting underruns
etc.

> Can I ask if you are using the 0.9.22 vanilla or the patches from
> "stable-queue" git branch (in particular David's "Fighting Rewinds"
> patches)? I would very much recommend using stable-queue. Also there
are
> corresponding patches in David's set to the GST side too. I'd first
> ensure you have all of these patches installed to see if this helps
your
> situation.

I'm using the Ubuntu Natty 0.9.22 version, (I mean the debianized
package). I found 2 patches from David Henningsson:

Fighting rewinds: Reduce calls to handle_seek 
Fighting rewinds: Seek and write data in the same message

I apply them but it doesn't seem to do any improvement, after a couple
of switches I start hearing glitches on the playback.

I guess the issue starts when the 'request to rewinds' and the
'limitation' differs by two-digit magnitudes like in:

D: protocol-native.c: Requesting rewind due to rewrite.
D: alsa-sink.c: Requested to rewind 130944 bytes.
D: alsa-sink.c: Limited to 2336 bytes.
D: alsa-sink.c: before: 292
D: alsa-sink.c: after: 292
D: alsa-sink.c: Rewound 2336 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 2336 bytes on render memblockq.
D: sink-input.c: Have to rewind 2160 bytes on implementor.

This usually happens just when the new sink starts rendering, the rest
of the differences are just of a few bytes, usually < 50 bytes.

That's why I was asking if there is any parameter I can increase
(buffer-sizes/latencies) in order to lower this difference.

Thanks, 


Alejandro.