Jack on macOSX
Jack on macOSX
- Subject: Jack on macOSX
- From: Stephane Letz <email@hidden>
- Date: Thu, 27 Feb 2003 19:18:07 +0100
Hi,
I am porting the Jack system on MacOSX. Jack is low-latency audio server
wrtitten for Linux. It can connect a number of different audio applications
to an audio device as weell as allowing them so share audio between
themselves. (jackit.sourceforge.net)
The Jack system is composed of a server and clients that are connected to
it. Clients declare audio input/ouput ports that can be freely connected to
the server audio in/out (corresponding to the audio driver) or to other
clients port. Thus a graph of connected audio applications can be built.
On Linux the Jack server uses an ALSA driver and works like this. At each
cycle:
- the ALSA driver make a blocking call to read an audio buffer
- the buffer is copied to a shared memory area
- the graph of client is executed : basically clients are triggered in
order to excute a "process audio" callback in the correct order depending
of the graph topology. Clients communicate using system fifo.
- control goes back to the server
- the produced buffer is copied from the shared memory area and written
with the ALSA driver.
On MaxOSX things must be done differently since it is a callback based
system. For now the CoreAudio callback calls directly the whole server
processing code:
- copy buffer, execute graph, get result buffer.
Audio client execution threads (called during the graph execution) are made
fixed priority thread of 63.
The result is quite satisfactory with "reasonable" buffer size.
But with really small buffer size (like 128 or 256), they are some gliches
even if the client audio graph does not consume too much cpu (like 25-30 %)
Of course in the current design, the CoreAudio callback "wait" for the
audio graph to be executed using blocking call on system fifo.
After reading the previous messages on "Multi-threading and glitchless
audio" i could also try to have lock-free ring buffers between the
CoreAudio callback and the audio graph execution code. But it will add a
one buffer latency to the system.
Another question if to find the best way to execute the graph, that is the
fastest way of having one client to suspend itself and resumes the next
client in the graph.
Any suggestion on these different aspect?
Thanks
Stephane Letz
Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72-07-37-00
Fax: 04-72-07-37-01
Web: www.grame.fr
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.