[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: dsound questions
From:       Marcus Meissner <marcus () jet ! franken ! de>
Date:       2000-05-31 17:58:09
[Download RAW message or body]

> 1) There's a race condition between DSOUND_WriteAudio, DSOUND_CloseAudio and
>    DSOUND_OpenAudio. Calls to these methods have the pseudo guard of
>    if ( audioOK == 1) {...} which isn't strictly required (at least to a 
>    cursory glance). What is required is a consistent critical section locking
>    scheme. Presently either the primarybuf->lock or the dsound->lock are used,
>    but not consistently. As a result we have thread clash that usually wacks
>    sound out badly.

At the time I wrote this, I was rather unsure and not very knowledgeable about
all the locking stuff and just prodded it until it worked.


>    I would suggest that the code should be the primarybuf->lock, but would 
>    like confirmation.

>    Also, what order should the dsound and primarybuf locks be acquired in the
>    case where both are needed (to avoid deadlocking)? dsound then primarybuf?

Feel free to work out a new scheme.

> 2) What is the intention of the global dsound and primarybuf pointers? I'm 
>    thinking that when multiple interfaces from multiple processes/programs are 
The rationale for that one was that we just have one audiodevice to open
and are mixing into that.

>    using these things we'll end up with problems. Or, is it possible to have 
>    per instance dll data (call me ignorant)? Would it not be better to just 
>    pass something from the interface around - perhaps a little more clumsy 
>    but more correct?

Yes.

>    At present they at least partially confuse the code and make reference 
>    counting a complete annoyance (and broken).

Feel free to fix it. :)

Ciao, Marcus

[prev in list] [next in list] [prev in thread] [next in thread]