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
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.
well, as a comparison from the rest of Wine, WineOSS codes tended to be rather verbose, and there is getting more and more of it anyway, you'd better use the winedbg_sprintf function for the memory management side of things
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.
yes, but the way it's coded doesn't change anything for example, if two threads concurrently try to do enable for the first one, and disable for the second one, you still don't know with operation will be done first and second, and furthermore the final status (enabled/disabled) of the operation => the state is never tested, so even if the crst allow to do atomically the bit operation and the ioctl, the rest is still flawed IMO
The current behavior of the driver reorders commands by placing ones that must be waited on at the head of the queue.
this is required: - the app has queued 10 wavehdr:s which still haven't been queued in OSS driver's queue (so they are still in message ring) - the app requires to stop the playback... the stop message must by pass all waiting wavehdr (which will be then released to the application)
the same is needed for capture, so it shouldn't been changed
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.
agreed (we did the same for the playback). what I don't like here is that there is lots of code duplication
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?
as of today, full duplex code in audio.c mainly contains sharing the fd access (and access rights) across all threads. you're right, we shouldn't need two worker threads for capture and playback and we could interleave their duties
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?
IMO, what could be done at some points is that lots of audio drivers work on the same infrastructure (working thread, a couple of basic operations: read/write/getstatus). what we may end up with is a core driver infrastructure shared by lots of drivers (OSS, arts...) and some specific limited bits
What about hardware mixing? Is anyone working on redesigning this?
IMO, we shouldn't reinvent the wheel here for wine. using arts, jack... would provide this (at least for playback)
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.
you're welcomed ;-)
A+
-
Eric Pouech -
Robert Reif