On Thu, 2011-06-02 at 17:02 -0500, Alejandro Gonzalez wrote: > 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. 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). Cheers, Arun
