more direct sound capture fixes

[Robert Reif]

Thanks for the feedback.

I know the debugging code is getting out of hand but
what is the recommended way of providing useable traces.
Should the debug code be put in a separate file?  Are there
standard routines for converting constants to readable
strings? I'm new to wine so I don't know what the current
practices are yet.

The critical section was put in there because there is the potential
of accessing that variable from all three threads.  It's overkill now
and probably not needed but I'm trying to track down some weird
behavior in full duplex mode. That variable stores the state of both
the read and write threads so we need to do bit opps on it.

The current behavior of the driver reorders commands by placing
ones that must be waited on at the head of the queue.  Not sure why
but I added that #define to allow it to be disabled.  It makes the
capture code more stable and deterministic. It defaults to the current
behavior.

I was running into under run problems in the capture thread where it
had data to save but no headers to put it in.  The headers were in the
queue but ignored until after the timeout period.  I added code to peek
into the queue rather than giving up and it fixed the under run problem.

I'm also having problems with the mixer and primary buffers and am
trying to figure them out but I suspect a similar problem.

The OSS people don't recommend using multiple threads for reading and
writing.  Three are currently used:  the main app thread where the
sound device is opened, one for writing and one for reading.
Could this have something to do with my full duplex problems?  audio.c
is getting big with both input and output and wave and direct sound all
together.  Do we want to break it up someday?  What about hardware
mixing?  Is anyone working on redesigning this?

My needs are short term.  I need to get my app working under wine
right now but I would like to see direct sound audio better integrated
someday and am willing to help.

Thanks,

Bob.


Eric Pouech wrote:

> > wineoss.diff:
> > Added more debugging code.
> it really starts being ugly and inefficient
> > Started work on direct sound capture driver.
> > Tried to get wave driver to work better in full duplex mode.
> > Capture works but playback has problems.
> just a few questions:
> - I don't think you need the enable_crst, do you ? I don't think the
> ioctl will be done in parallel anyway
> - why do you need to change the message order ? you'd better in wave
> capture, when you run out of waveheaders try to process the pending
> messages (as we do in wave playback) before sending back an error,
> without reordering them
>
> A+
>
> --
> Eric Pouech