[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-audio-dev
Subject:    Re: [linux-audio-dev] Lots about latency and disk i/o and JACK...<g>
From:       Kai Vehmanen <kai.vehmanen () wakkanet ! fi>
Date:       2001-10-03 22:40:07
[Download RAW message or body]

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!

[prev in list] [next in list] [prev in thread] [next in thread]