wine + winamp: fixme:wave:OSS_AddRingMessage two fast messages in the queue!!!!

[seut]

thanks a lot for this detail explanation.
good to know that this FIXME message is not the reason for our 15sec
pause, but bad for us because we have to search other problems which
could occure this pause.. ;-)

anyway thanks for this answer!

On Sat, 2005-03-12 at 14:50 +0100, Eric Pouech wrote:
> seut a écrit :
> > hello,
> > 
> > we are using winamp 2.95 with latest wine 0.0.20040914 and are wondering
> > what there is about these 'fixme:wave:OSS_AddRingMessage two fast
> > messages in the queue!!!!' messages dumped out at the console every few
> > seconds...
> > Same happens(but with 'ALSA_AddRingMessages' of course) if we're using
> > the wine alsa-driver.
> > 
> > Winamp normally works, but sometimes there is a 15sec pause at the
> > playback, so we are trying to search the problem.
> > 
> > I watched the wine source-code, but as my less C knowledge I didn't
> > really understand the part where this 'FIXME' message is implemented.
> > As I understand the code, why somebody added the 'FIXME' message to the
> > code, if the code can handle this problem(two fast messages)?
> > 
> > Or can somebody explain me the reason for this 'two fast messages'? 
> basically, the playback thread can receive two kinds of messages:
> - header message, containing data to be played
> - control message (start, stop, pause...), which have to be handled before any 
> header message, hence the "fast" notion
> 
> what happens in your case is that two different threads in your program (winamp) 
> are using APIs which need to send fast messages... we're not prepared for that 
> yet (this would just mean adding the new "fast" message after the existing fast 
> messages, and before the other ones). the code only assumes there's no existing 
> fast message, and just piles the new fast message on top of the queue
> 
> BTW, on a pure theoritical analysis, always putting the fast messages at the 
> start of the buffer (and even before existing ones) shouldn't hurt, as there's 
> no order to be assumed when two threads call the APIs (if the program needs to 
> maintain the order, it has to do it at the thread level)
> 
> to make a long story short, the FIXME is useless
> 
> so, the issue you're seeing come from somewhere else
> A+