[pulseaudio-discuss] rewind and underrun issues on start of playback

[Baek Chang]

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.

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
> 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?
>
> 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...
>
> --
> Tanu
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>



-- 
-baeksanchang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110501/da7986f0/attachment.htm>