[pulseaudio-discuss] sink-input's membockq's read-index rewound to a huge negative causing silence delay, almost 2~3 seconds
wangxingchao2011 at gmail.com
Fri Jun 10 12:58:33 PDT 2011
2011/6/9 xing wang <wangxingchao2011 at gmail.com>:
> Thanks you replay Tanuk! :-)
> 2011/6/9 Tanu Kaskinen <tanuk at iki.fi>:
>> On Thu, 2011-06-09 at 05:42 -0400, xing wang wrote:
>>> hi all,
>>> i've a finding about silence delay, the background is looking like
>>> this post : "[pulseaudio-discuss] [PATCH] core: Drop empty gaps in the
>>> memblockq when playing data from it."
>>> with tsched=1 and using default 2s buffer size,,while alsa-driver
>>> provides a even bigger buffer(5s),after the first rewind of "latency
>>> change" before starting playback, the buffer had been shrinked to a
>>> smaller value according to app's request, this trigger sink-input's
>>> rewinding , read-index become a negative value,,nearly -buffer_size.
>>> in pa_sink_input_cb() , pa_memblockq_peek() will return silence before
>>> the readindex reach 0 from the negative value. that caused obvious
>> I'm not convinced that causes any delay. I tried to reproduce the
>> problem myself, and while my sound card (or its driver) is capable of
>> giving only 185ms buffer so I can't really observe the by listening,
> Yeah, on my board the buffer is more huge, so after the rewound the
> read_index is a very
> big negative value, such as ~320000, almost default tsched_size 2s.
> For your case, there's no so
> long latency, it's even hard to observe. :-)
>> adding some debug prints (patch attached) showed that yes, the read
>> index gets negative, but when the client data arrives and the "end of
>> underrun" rewind happens, the write index gets reset to be the same as
>> the read index (ie. negative).
> That's done in rewind of "end of underrun" by
> pa_memblockq_flush_write(), right. Note that after that
> the memblcokq is forced in pre_buf TRUE status. Both the
> read/write-index reached the same negative value.
>>Since the write index is not ahead of the
>> read index, there shouldn't be any silence because of the negative
> Not quite catch your point here! Because write index is not ahead, so
> the memblcokq is not readable,right? But on the contrary, if write
> index is ahead, there will coming silence until the read index reaches
> to 0(real data). I am not sure about this point. Although in the real
> debuging, i found the lengh of memblockq is nearly 36000, that means
> write_index is ahead.
> Here's a quick guess about the calling situation;
> 1) after rewind of "end of underrun", pa_memblcokq_flush_write() will
> make both read/write_index the same
> 2) alsa-sink keeps on requesting data, in pa_sink_input_peek(), for
> pa_memblcokq_is_readable() false, so there's a chance to fill
> "slength" long silence. i->pop() may return 0, for implementor didnot
> give any data, so handout some silence.
> After that, the memblcokq is readable, and may drop in too long silence period.
>>This is different from the case that you linked to - there the
>> write index did not get reset to the read index.
>> That said, I can't think of any case where it would make sense to rewind
>> beyond the beginning of a stream (or any other memblockq), so I've
>> attached a patch that limits pa_memblockq_rewind() so that it never
>> rewinds to negative read index values. I'm not sure if it breaks
>> anything, but at least basic playback and volume control seems to work
>> without glitches... You can try it if it helps in your case.
>> Maybe the patch should be even committed to master? If the patch doesn't
>> break anything, it should make these two fixes redundant:
>> As I say in the commit message, if we're trying to limit the read index
>> to be always non-negative, then the write index should probably be
>> limited too. And then the index types could be changed from signed to
>> unsigned... I wonder if Lennart made them signed for a purpose?
> Thanks again! I will try your patch later!
Hi Tanuk, your patch didnot solve the issue. With your patch,
read_index will keep ahead of 0 after rewinding, but there's still
silence delay. Maybe a bit understanding about the data transfering
procedure, i will keep update status later.
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss at lists.freedesktop.org
More information about the pulseaudio-discuss