(no subject)

Simon Britnell ughbash at yahoo.com
Tue Oct 30 17:50:59 CST 2001

--- Eric Pouech <eric.pouech at voila.fr> wrote:
> well, from a generic point of view this is something
> to be done
> however, I don't see where you'd like to dispatch
> the event to ?
> the playback thread in this case would have to wait
> on two different things:
> - the /dev/dsp fd (when the queue becomes non full)
> - the external events (play/pause/stop/quit)

The idea is to have a (new) thread which does nothing
but sit in a select and then generate wine events
whenever the select returns.  Various sound system
events cause /dev/dsp to be added to or removed from
the select list so that it generates a (new)

the (existing) wodPlayer thread then sits in a 

WaitForSingleObject( wwo->msgEvent, INFINITE )

and the following case statement, as well as handling
WINE_WM_PAUSING, etc has an extra case being:
/* pseudocode */
    /* Write data out to the DSP whenever there's
     * space in the queue.
    if( more_to_be_written() ) {
    } else {

We also need to add code to the WINE_WM_HEADER case:
    if( !dsp_in_select_list() )

> so you have to decide whether you use unix or
> Windows sync mechanisms here.

I'm not really familiar enough with the windows
mechanism, but as far as I can tell, there's basically
an event, which gets waited for by WaitForSingleObject
and the waiting process is told to proceed by

If wodPlayer is entirely internal to wine, there's no
reason we couldn't just replace the entire innards of
audio.c with something that's fed by a unix pipe and
replace the WaitForSingleObject and ring buffer
management with writing it all into and reading it
from a pipe and using select on the data pipe and the

> unix would be more
> effective, but a bit harder to do. Windows would be
> nice (you just need to call the wine server request
> to create from a unix fd into a windows handle and
> wait on it.

Do You Yahoo!?
Make a great connection at Yahoo! Personals.

More information about the wine-devel mailing list