[sdiy] New to list - and DSP development

[ASSI]

The comments below are generic, I don't have any useful programming 
experience with Macs...

On Montag, 29. November 2004 07:12, Kenneth Elhardt wrote:
> 3)  If anybody has any soft synth programming experience, what is the
> normal way to keep a softsynth generating data at 44.1KHz.  Since
> Mac's and PC's usually only have 1ms clocks it's not like I can sync
> up to a 44.1KHz clock. Do you simply wait for the current sound
> buffer to finish playing and that acts as your limit?  Or do you set
> up some kind of 44.1KHz interrupt?  Or is there some other better
> way?

That the clock (tick interrupt) is at 1ms doesn't mean you can't ouput 
at higher frequencies, but this requires special support from the OS. 
Most systems have a hardware timer that can produce periodic interrupts 
at much higher rates provided you can service them fast enough. Syncing 
to an external clock would require a hardware buffer to work properly, 
but depending on the interface you send out the data you might already 
have that. Serial ports normally have a 16byte FIFO and most soundcards 
should have them as well if they don't use DMA to fetch the data 
themselves with the right timing. If the OS you're using has any notion 
of streamed audio support, you don't have to deal with these problems 
anyway, instead you just register with some sound API and just fill the 
buffers or frames that the OS should play back.

A software PLL might work if the external clock is very low with respect 
to the processor clock and the interrupt latency for an external 
trigger is constant (this is unfortunately not true for most general 
purpose processors) or at least the variance for the interrupt latency 
is bounded (lots of OS's won't give you that guarantee either).

> 4)  Also I assume I generate sound in one buffer while another plays.
>  On the Mac it's possible to jump to a call back routine when the
> buffer finishes playing.  Is that the method used to switch to the
> 2nd buffer to start playing and is that fast enough so no glitches
> occur?

You would use at least three buffers: one that is currently playing, one 
that is queued for swap with the one that is currently playing when 
it's played back to the end and the third that you fill. Size and 
number of the buffers depend on the interrupt rate the OS allows you to 
use and how much variance you have in the interrupt latency for the 
sound producer thread. The buffer swapping needs to be a very tight and 
high priority interrupt routine, if you use a queue longer than a 
single buffer it also needs to deal with taking frames from the queue 
list, whhile squashing/recycling used frames and appending new ones is 
done by the producer. If you can fix the maximum queue length, a ring 
buffer for the frame pointers is easier to handle for both sides. 
Again, if you're using a sound API, you don't deal with that; you may 
not even have to allocate the buffers yourself.


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46 Neuron microQkb Andromeda XTk sonic heaven]>+

Q series MIDI Implementation & additional documentation:
http://Stromeko.Synth.net/#WaldorfQDocs