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