I am hearing that very very short sounds, smaller than hw buffer size, occasionally not heard. The initial portion of audio is silenced. If i remove the rewind request from protocal-native.c, then the problem is resolved, but other issues are there, audible glitches when doing volume changes. <div class="gmail_quote">On Sun, May 1, 2011 at 12:22 AM, Tanu Kaskinen <<a href="mailto:tanuk@iki.fi">tanuk@iki.fi</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">On Sat, 2011-04-30 at 15:38 -0700, Baek Chang wrote: > Hi, > > I'm seeing some issue with underruns/rewinds occurring on the beginning of > every sink input playback. > I see rewind requests on alsa sink of 9600 bytes. The alsa driver is > configured with the following buffer sizes > > I: sink.c: device.buffering.buffer_size = "9600" > I: sink.c: device.buffering.fragment_size = "4800" > > So it seems like one buffer size is always being rewinded on the beginning > of playback. > Is there a way to prevent these rewinds/underruns when starting playback? </div>Not to my knowledge, except by changing the code. <div class="im"> > after the stream has started, there is no issue with audio dropouts or > underruns, just on the beginning. > > If i log the data that gets sent to alsa, from pulseaudio or in the alsa > driver, i do see the beginning being dropped as well. > > please see attached logs using both tshed=0 and tsched=1. > > any help with this? > thanks! </div>Are there any real problems with this rewinding, like the beginning of the stream disappearing, or an audible drop-out in the audio? The sink buffer has to be always rewound when a new stream is created, because initially the sink buffer contains silence. That silence has to be overwritten with the stream data, so that there's no unnecessary latency due to waiting for the silence to be played. That said, the underrun seems strange, because it happens after the "Requesting rewind due to end of underrun" message. I don't know the code well enough to be sure that it indicates any error, though. If the messages would be ordered the other way around, then it would make more sense: first when the stream is created, the buffer doesn't have any data, but when the prebuffering phase ends, then a rewind is requested on the sink to allow the stream playback to start immediately. I don't know if this was helpful at all... -- Tanu _______________________________________________ pulseaudio-discuss mailing list <a href="mailto:pulseaudio-discuss@mail.0pointer.de">pulseaudio-discuss@mail.0pointer.de</a> <a href="https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss" target="_blank">https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss</a> </blockquote></div> -- -baeksanchang