On Wed, 2011-06-01 at 12:18 -0500, Alejandro Gonzalez wrote: > 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. Arun, Answering your post on the other email thread: "It would be helpful to see if this happens only on GStreamer based applications or all of them." 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. Thanks and regards, Alejandro.
