Re: Lowest latency: JACK, or ALSA directly?

["Jack O'Quin" <joq@io.com>]

asbjs@stud.ntnu.no (Asbjørn Sæbø) writes:

> On Thu, Nov 11, 2004 at 09:11:28AM -0600, Jack O'Quin wrote:
> > JACK *does* constrain the ALSA period to a power of two.  If that is
> > not your ideal buffer size, then you could experience extra latency
> > due to that.
> 
> By "period" you mean the size of the period (in frames), not the number 
> of periods, right?

Right.  That is ALSA terminology, IIUC.

> (As an aside, there is another thing that is not clear to me.  A set of 
> samples from all channels is called a frame, and a set of frames is a 
> period.  But the total buffer is made up from a set of periods again.  
> How does this buffer function? Does one get data from the sound card 
> each and every period (which I believe), or only when the buffer is 
> full?  Do you get the data from a period when it is full, or do you 
> have to wait some periods?)

The sound card generates an interrupt at the end of each period.  This
determines the input latency.  The hardware buffer holds multiple
periods (you need at least two).  Its size determines the maximum
output latency.  With JACK, there's not much reason to use more than
two or three periods, unless you're running without realtime
privileges.

> > [...]
> > The JACK interface is simpler, but you have to get comfortable with
> > programming using callbacks.  Here's a simple JACK example client...
> > 
> >   http://cvs.sourceforge.net/viewcvs.py/jackit/jack/example-clients/simple_client.c?rev=1.15&view=markup
> 
> That was quite understandable, at least the callback principle.  I 
> do have a few questions, though.  
> 
> I can not see the application setting any parameters, like f.i. the 
> number of channels.  Does it just accept whatever data it is given from 
> jack?  

It defines its own input and output ports using jack_port_register().
The example client has one of each.  These are independent of
hardware, the input may come from one or more other clients or go
somewhere else.  The example client then checks for physical capture
and playback ports, the hardware input and output channels.  If there
are any, it connects to one of each.

> How does the application know what the data it receives from jack are
> (number of frames, number of channels)?  (In the case it is supposed to
> be processing them, not just passing them on?)

The number of frames is a parameter to the process() callback.  That
could change from one cycle to the next.  

If you need to know in advance (perhaps to set internal buffer sizes),
call jack_get_buffer_size() to reveal the current limit and register a
callback with jack_set_buffer_size_callback() before activating your
process() callback...

  http://jackit.sourceforge.net/docs/reference/html/jack_8h.html#a13

> The program I have now is very simple, it just reads samples from the
> sound card and writes them to a network socket.  If jackified, would it
> in essence do the same thing, only using jack as an asbtraction layer
> over ALSA?  Or would it be splitted into two parts, one that reads the
> samples (and sends them to jack) and one that receives samples from jack
> and sends them to the network?

If you only send samples, I suppose it would work similarly to the
JACK example capture_client.  Define JACK input ports for each
channel.  You could automatically connect them to hardware inputs, or
you could connect them externally using qjackctl or some other
patchbay client.

You will need a separate thread for writing to the network socket.
Otherwise, it might block and blow the realtime response deadline of
the process cycle.  The capture_client.c example uses a ringbuffer to
send data from the process thread to its disk writer thread...

  http://cvs.sourceforge.net/viewcvs.py/jackit/jack/example-clients/capture_client.c?view=markup

> > [...]
> > Even if you don't want to connect other programs, they might want to
> > connect to yours.
> 
> How can they?  If I write an application that reads data from the 
> soundcard using jack, can other programs intercept the data?  (That 
> could of course be very useful in some circumstances.)

Yes, the user can alter the JACK connection graph at any time.  Your
program doesn't need to know about that, unless it wants to.
-- 
  joq


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id\x12065&op=click