On Sat, 19 Nov 2005, Tim Blechmann wrote:
but this is the contrary, how the audio hardware of all modern audio apis (jack, asio, coreaudio, portaudio, possibly alsa) works. the sound card sends an interrupt to the os, the driver calls a function in the program that should send/receive the audio data...
In an modern OS the driver doesn't call a user function.
There is no difference between callback based and blocking I/O in terms of latency, its only about scheduling.
On linux, the audio driver (in kernel space) only offers a blocking API. What JACK does is, it converts the blocking into a callback.
The way this is done is that the JACK library code in the application waits (blocks !!) until it gets a "go" from JACK directly (or the application that runs before in the JACK chain). Then the jack library calls a callback within the application. There is no (technical) reason why the application can't wait on the lock by itself, and if it gets a "go" does the calculations. One thing that has to be assured in this scenario is that the calculations are done fast enough (no blocking I/O, memory allocation, etc stuff) and that after the calculation control is handed over to the right process (the next one in the jack calculation chain).
Similar scenarios for portaudio, coreaudio, ASIO. Callback API doesn't mean lower latency, it is just easier and less errorprone than having to do the blocking explicitly.
Guenter
my approach for devel was to use this callback to drive the dsp computation, but to keep the system in sync, i have to lock the global pd mutex. so basically all functions that are run, while the global pd mutex is locked, should be executed, without locking the system for a too long time ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list