rewind and underrun issues on start of playback

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 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
>



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


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux