my dsound/winealsa hacks
tom at dbservice.com
Sun Sep 24 13:31:04 CDT 2006
James Courtier-Dutton wrote:
> As Direct Sound does not know anything about periods, I don't really
> know how you will be able to get it to work well with ALSA. I expect
> that some sort of double buffer will be required.
> Does Direct Sound have a concept of position of the ADC, and also a
> concept of where in the buffer it is sensible to fill with new samples?
When the application creates a buffer, it passes a structure to
CreateSoundBuffer() that describes what kind of sound the buffer will
contain, and the data include:
- format (PCM/ALAW/ULAW etc)
- number of channels
- bits per sample
- rate (Hz)
- size of the buffer it wants, in bytes
The application can use Lock() to request s pointer to a buffer where it
can write X bytes of sound data to, once it has written the data, it
calls Unlock() and then DirectSound passes the data to the soundcard.
World of Warcraft calls Lock to get a pointer where it can fill 4096
bytes (regardless of how big the period is, because DirectSound doesn't
know about periods), writes the sound to the buffer and calls Unlock(),
I'm using the async handler that invokes a function that reads the data
from the intermediary buffer and passes it to the alsa).
And yes, the app can call GetCurrentPosition() to find out the 'Play'
and 'Write' positions in the buffer, play is where the soundcard is at
the moment (eg. the position where I will read the data from and pass it
to alsa), write is where the app can write the data to, currently I'm
I haven't implemented the DirectSoundCapture, but I guess that it will
work the same: the app calls Lock() and when the call returns it will
receive a pointer to a buffer where X bytes of the captured data is, so
if the app wants 4096 bytes, I'll have to wait until alsa has returned Y
periods (where frames_to_bytes(Y) > X) and then return to the app.
I'm sorry, I didn't explain myself clearly in the previous mail :-/
More information about the wine-devel