my dsound/winealsa hacks

[Tomas Carnecky]

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)
and
  - 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 
using 'playpos+period'.

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 :-/

tom