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