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