[En-Nut-Discussion] Bug in NutSegReadCommit

[Pavel Chromy]

Harald Kipp wrote:
> it can't work. That's 16kByte/s and Internet often
> hangs for more than just a second. Beside that,
> streaming servers initially send a buffer of 100kByte
> or more. Due to lack of memory, the old routines had
> to through it away. The old "crap" worked reliably
> up to 32kBit only, while the new VS1001K driver
> can even stream 56kbit over GSM with a very good
> connection.

Oh, that's a missunderstanding, I meant that the _recent_ driver
works for long streams as the issue I was talking about
is concerned just to sepratate tracks (flushing at the end of the track
does not work, which you probably never notice when listening to a sinlge long stream).

Anyway, I'm using the old driver for streaming 128kbit MP3s over UDP (proprietary protocol)
with cca 60KB of memory (Nut/OS compatible board, not Ethernut) but just over the LAN.
It works fine though - 8 devices connected to a switch with a server.
TCP proved unsuitable for this task (with such small amount of memory), as it tends to 
either eating a lot of memory or to delays when the receive buffer is full.

> Nevertheless, I'll check my changes to your code.
> I remember, when writing it, I thought by myself
> "Oh, let's do it this way. If it's wrong, Pavel will
> protest". :-)

:-) Well, I noticed the bug some time ago and I was planing to fix it and submit a new version,
but as the device with VS1001 (commercial project) is no longer under development 
I would have find some of my own free time which I was not able to do yet, sorry.

Pavel