[pulseaudio-discuss] rewind and underrun issues on start of playback
baeksan at ccrma.stanford.edu
Sun May 1 20:52:03 PDT 2011
Also, if i revert to pulseaudio 0.9.14, i do not see this issue happening.
I can hear the very short samples in the beginning fine.
On Sun, May 1, 2011 at 8:45 PM, Baek Chang <baeksan at ccrma.stanford.edu>wrote:
> 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
> On Sun, May 1, 2011 at 12:22 AM, Tanu Kaskinen <tanuk at iki.fi> wrote:
>> 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
>> > 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
>> > of playback.
>> > Is there a way to prevent these rewinds/underruns when starting
>> Not to my knowledge, except by changing the code.
>> > 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!
>> 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...
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss at mail.0pointer.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pulseaudio-discuss