On Wed, 3 Oct 2001, John Lazzaro wrote:
>> If an application uses a callback model, and even better, if it uses
>> JACK's callback model, then it can send and receive data to and from
> It took around 3 weeks of design and coding to set sfront up to handle
> audio drivers that used callbacks -- so for some sorts of applications,
> at least, its a pretty straightforward retrofit. The sfront changes were
True. And I don't think using callbacks is actually the big thing in LAAGA
- it's synchronous operation. Basicly it's just the same whether:
(1) - client has registered callbacks (client app)
- library sleeps on socket (libjack.so)
- wake up (libjack.so)
- call registered client callback (libjack.so)
- execute the callback (client app)
... or ...
(2) - client issues a blocking library call (client app)
- in the function, we sleep on a socket (libjack.so)
- wake up (libjack.so)
- return from the blocking call (libjack.so)
- do processing and issue another blocking call (client)
So no real difference there. The really important features are:
- only one component is active at a time (not including
separate disk i/o, midi i/o, etc subsystems)
- it's an error condition if next component in
the execution chain a) is not ready for wakeup
when its turn comes, or b) is not able to complete
its turn in time
- because of the above requirements, a system-wide
blocksize and sample-rate must be used
--
http://www.eca.cx
Audio software for Linux!
