[En-Nut-Discussion] Bug in NutSegReadCommit

[Harald Kipp]

Hi Pete,

I do not think that this causes hiccups. Did you check
"Step 3: Refining the Player" at
http://www.ethernut.de/en/medianut/index.html
(hiccups due to embedded meta data)?
If NutSegBufReadRequest() reports, that no more bytes
are available, then the VS1001 driver _stops_ playing.

Anyway the implementation looks wrong to me too.
The player stops when read and write pointers are at
the same address in different segments. This is a
rare condition, but it exists and I agree, that your
proposal fixes it.

Regarding Sourceforge bug tracking: I always plan to
use this tool more often and regularly fail to do so.
Sorry for that.

Thanks for spending your time to figure this out. I'll
try your fix and commit it to the CVS head.

Harald

At 20:38 24.11.2004 +0000, you wrote:
>Hello Harald,
>
>Have I spotted a bug in NutSegReadCommit() and NutSegReadLast().  (I've 
>got release 3.9.2 of Nut/OS.)
>
>These routines set the segbuf_empty flag when the read pointer and the 
>write pointer are equal.  I think the test should include a comparison of 
>the read and write segments as well:
>
>if ((segbuf_rp == segbuf_wp) && (segbuf_rs == segbuf_ws)) {
>     segbuf_empty = 1;
>}
>
>With the test as it is I find that NutSegBufReadRequest(bcp) sets bcp to 
>zero when there is in fact a multiple of 16384 (NUTBANK _SIZE) bytes in 
>the buffer.
>This leads to hiccups in the feed to the VS1001K.
>
>If the bug is real, let me know and I'll log it at SourceForge.
>
>Regards,
>Pete Allinson