Audio input with DirectSound?
udo_giacomozzi at rolmail.net
Mon Mar 29 08:02:24 EST 1999
>>Yes. There is DirectSoundCapture for what you are asking for. It seems atm
>>it only emulates capturing i.e. it uses standard MM API, but it's still
>>better than using MM API directly. You have (more or less) direct access
>>the sound buffers. This means you can read the data when it has been just
>>recorded (using the right cursor info).
>>If you want low latency under Win95 you won't have luck. I tried >1 year
>>make a near-realtime DSP program for Win95, tried hundreds of techniques,
>>but I could not get under 30 ms latency (unstable).
>I have the same problems and 30 ms sounds great to me. Perhaps you can post
>some of your favorite techniques, especially for the MM API;
Please note 30 ms only work if I do *nothing* else with the computer. A
little disk write is enough to skip some buffers. That doesn't sound very
However I use a periodical MM timer (see timeSetEvent) to call a callback
function 1000 times per second (unfortunately that does *not* necessarily
mean the CB is called every ms ... :-( ). In this CB function I check the
DirectSound buffer position. If it has reached a new block (1 block is half
the desired latency) I do sound processing, otherwise I exit the func. I
don't fill up multiple blocks because I need as much realtime as possible.
Let's say the buffer is divided in 5 blocks (you can have as much you want,
that doesn't matter). When block 2 has been filled with input data (and
block 3 is being recorded), block 1 starts playing and then block 2 is being
processed (DSP). This way the latency is just the duration of two blocks.
The problem isn't the way how blocks are mantained or processed (processing
1 block never can take longer than the block duration, otherwise it isn't
realtime) but the CB func. Win95 isn't very accurate (say what you want but
it is absolutely no realtime OS, no way). When you request 1000 calls per
second you get them, but not at 1000 Hz. Sometimes Windows hasn't time for
your callback and it isn't called for about 50-100 ms (or even longer). Then
the CB func is being called 50 times ASAP. This is inacceptable for realtime
sound I/O because you need to know when a block has been recorded ASAP.
Unfortunately there is no direct interrupt feature under Win95. The block
latency (the time it takes until you know the block has been
recorded/played) must be kept *very* short (<5 ms at least).
This is where I searched various methods to check buffer position. You can
forget DirectSound's notification interface, it's sooo slow.
Multimedia timers are the best (but not very good...) for this case. I
noticed the callback performance is very bad when you open a DOS Shell. In
this case a secondary thread is better. This thread checks buffer position,
sleeps for 1 ms, checks, sleeps, and so on. The best is when you combine MM
timer and thread.
You get the best performance using a high-priority thread that never does
sleep. But, hehe, then the thread takes all CPU time, no other thread is
processed. The latency is very good, but it's useless if windows is freezed.
(I had to do a cold boot).
Well, spoken enough. If you have any further question, just ask. ;-)
And hey: All these problems you don't have under Linux. That's why I love
>Is there a way to get the minimum capture buffer size of a waveIn device?
I don't know. I don't use the MM API directly (I use DirectSoundCapture).
* Email: udo_giacomozzi at rolmail.net
* UIN: 17745247 (@pager.mirabilis.com)
dupswapdrop: the music-dsp mailing list and website
More information about the music-dsp