audio.c converted from WaitForSingleObject to poll

[Paul Lorenz]

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 at ping.uio.no> wrote:
> 
> On Wed, 31 Oct 2001, Simon Britnell wrote:
> 
> > 2) 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