[En-Nut-Discussion] Release Candidate 3.4.3

[Pavel Chromy]

Harald Kipp wrote:

> What else can I do to get you guys to report any
> missing fix _before_ I release 3.4.3 (See my previous
> post with the same subject)? Shall I pack an archive?
> 
>  From experience missing fixes are reported shortly
> _after_ I release it and I'll try to make this the
> final 3.4.

Hello Harald, I have a proposal for a fix of a bug I know of for a while,
but I have not had a time made a patch yet - so just to let you and others know.

It is concerned with new VS1001 driver with segmented buffer support.
Though I have not tested it yet, I noticed that there was a significant change in 
how the VS1001 buffer flushing is handled.

Let's compare the position of the "if (vs_flush)" statement in VsPlayerFeed() in the new source
versus my original source (available in the CVS in the mod/dev directory).

In my code it is  inside a loop and inside "if (vs_readptr == vs_writeptr)" statement (line 354).
The aim of this was to flush internal VS1001 buffer in the background after all data 
had been sent out of main buffer and then announce VS_STATUS_EMPTY, so that user application
knows that whole track was played and it is safe to reset the decoder and play next one.

In the new code the "if (vs_flush)" statement in VsPlayerFeed() is directly at the beginning of
VsPlayerFeed() (line 379) before the feeding loop, causing the decoder buffer to be flushed
immediately after call to VsPlayerFlush() - or in the first following interrupt, to be exact,
which is obviously wrong, since there may be still some data in the main buffer which never gets played!

Is anyone interrested in fixind this bug? Otherwise it must wait for a while
till I have some time to do this and I suggest to put the original driver back 
in final 3.4.3 and state the new one as development mod.


-- 
#define QUESTION ((bb)||!(bb))

Mgr. Pavel Chromy
ASIX s.r.o.
Staropramenna 4
150 00 Praha 5