[pulseaudio-discuss] sink-input's membockq's read-index rewound to a huge negative causing silence delay, almost 2~3 seconds

[xing wang]

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."
>>> (http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg09579.html)
>>>
>>> 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
>>> delay.
>>
>> 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
>> indexes.
>
> 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:
>>
>> http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=6bd34156b130c07b130de10111a12ef6dab18b52
>> http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=495c1ed2361f7bab5eaa6978d2fda624a2944bb9
>>
>> 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.

Thanks
--xingchao



>
> --xingchao
>>
>> --
>> Tanu
>>
>> _______________________________________________
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>>
>>
>