> To avoid glitches, audio buffers have to be filled earlier so that
there are
> (say) three buffers between writing to the buffer and sending it to the
> soundcard. To decrease latency, the buffers have to be failry small
,maybe
> 256 or 512 samples (maybe smaller if possible)
This is a problem. Small buffers really only work with high-end audio cards
(if at all). If you think about what happens here, you can understand why
you're getting glitches. Assume that you have a non-intelligent audio card,
that DMAs audio data to the chip (true of most soundcards). This means that
the DMA pointers have to be updated every 256 or 512 samples. If Windows
can't service the end-of-DMA interrupt in time, you fail to write the next
DMA pointer before the Audio card runs out of data, and you get a glitch.
Windows really isn't that good at servicing interrupts in a timely manner.
Cards like the newer SB-Live cards that have DirectSound hardware buffers
will do ok with small buffer sizes. Older audio cards such as SB-classics,
SB-clones, Yamaha Peices of Junk, and the like will have trouble.
You either need to use large buffers, or (preferrably) use a large circular
buffers and chase the
read pointer.
Something else to keep in mind is that any heap allocation that occurs on
the realtime synthesis thread is going to cause problems. Heap allocations
on a realtime thread are not a good idea, since alloc calls can be very time
consuming, but unpredictably so.
I haven't been through the sfront code in detail, but I'd hazard a guess
that if you really want snappy realtime performance, I would avise making
sure that all your tables are allocated in the global context, not the local
context, avoid calls to kline,
If you're not worried about interactive responsiveness, just give
DirectSound a large circular buffer, and stay as far away from the read
pointer as you can.
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:38 EST