Hi, I'm writing a multi-track recorder, so this is a problem I've encountered. My solution went like this.
Mux in own thread, Player in own thread with circular buffer in the middle.
The Mux takes all inputs and multiplexes them into the circular buffer. It blocks when the buffer is full. In the case of wine, I would guess the Mux isn't really needed, just some function that writes into the circular buffer, blocking if its full.
The player reads from the buffer, blocks on empty, writes to /dev/dsp otherwise.
Also the buffer size is a multiple of the fragment size of the output device. For OSS the output buffer is split into fragments, for SBLive 16 fragments of 4K each.
So the player also blocks on the buffer, when there are less than fragment_size bytes available.
In this model, there are no timed waits or yields, just blocks and notifies, so happily no spinlock type situations.
I have all this written, unfortunately its in Java, but the concept should be translatable to C.
I hope this is relevant/useful.
Paul Lorenz
--- Ove Kaaven ovehk@ping.uio.no wrote:
On Wed, 31 Oct 2001, Simon Britnell wrote:
- Removes the need to calculate a sleep interval
in
the wodPlayer main loop, as it loops only when dsp
is
ready to be written or a command is ready to be received.
Well, it seems like a bad idea to make the player thread enter a busy loop when there isn't enough data to fill the device buffers, don't you think? (Well, though I'd like buffer complete notifications to happen more frequently than they do in Wine's current implementation, making the player thread use 100% CPU isn't the way...)
__________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com