[PD] PD and latency on kernel 220.127.116.11-lsm
geiger at xdv.org
Mon Nov 21 11:27:50 CET 2005
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.
> 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 at gmx.de ICQ: 96771783
> latest mp3: kMW.mp3
> latest cd: Goh Lee Kwang & Tim Blechmann: Drone
> After one look at this planet any visitor from outer space
> would say "I want to see the manager."
> William S. Burroughs
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list