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

[seut]

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'? 

thanks a lot
seut

btw. I'm not a member of the mailing-list, so please send answer to me
too!
and please don't suggest us to use a native linux-player instead, for
some reasons, we have to use winamp..

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

[Eric Pouech]

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+
-- 
Eric Pouech

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+