Lowest latency: JACK, or ALSA directly?

Lowest latency: JACK, or ALSA directly?

[Asbjørn Sæbø]

As I understand it, JACK acts as a middle layer between a (jack-aware)
application and the underlying ALSA libraries.  But it is also possible
to program against the ALSA libraries directly (which I am doing now).

I am writing an application for audio transfer over network, where the
main goal is to achieve the lowest latency possible.  I would assume
that, as JACK adds an extra layer, it may also introduce extra latency.  
Is that so?  And in that case, how much may be gained by using the ALSA
libs directly, instead of going through ALSA?


Although I so far barely have gotten into ALSA programming, it does seem
to be manageable in difficulty. (Don't laugh, I am an acoustican, not a 
programmer.)  How is programming against JACK in comparison?


As far as I understand it, the main advantages of JACK are the 
possibility to connect together several applications, as well as the 
ability to keep these applications in sync.  That is however not very 
important to me now, as I will probably not need to connect to other 
programs.  Are there other important advantages?  And what are the 
disadvantages?


(As an aside, if anybody knows of any open source applications for very
low latency transfer of audio over IP, I would appreciate it if you let
me know.  Although this audio programming is some of the most fun I have 
had in years, I can hardly defend spending my time duplicating work.)


With kind regards
Asbjørn Sæbø



-------------------------------------------------------
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

Re: Lowest latency: JACK, or ALSA directly?

[Jack O'Quin]

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

> I am writing an application for audio transfer over network, where the
> main goal is to achieve the lowest latency possible.  I would assume
> that, as JACK adds an extra layer, it may also introduce extra latency.  
> Is that so?  And in that case, how much may be gained by using the ALSA
> libs directly, instead of going through ALSA?

JACK does not add extra latency.  Everything is synchronous with the
basic ALSA cycle.  

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.

> Although I so far barely have gotten into ALSA programming, it does seem
> to be manageable in difficulty. (Don't laugh, I am an acoustican, not a 
> programmer.)  How is programming against JACK in comparison?

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

> As far as I understand it, the main advantages of JACK are the 
> possibility to connect together several applications, as well as the 
> ability to keep these applications in sync.  That is however not very 
> important to me now, as I will probably not need to connect to other 
> programs.  Are there other important advantages?  And what are the 
> disadvantages?

Even if you don't want to connect other programs, they might want to
connect to yours.

The main disadvantage is that your system needs to be fairly well
tuned for low latency operation for JACK to work reliably.  But, you
probably need that anyway for this application.

> (As an aside, if anybody knows of any open source applications for very
> low latency transfer of audio over IP, I would appreciate it if you let
> me know.  Although this audio programming is some of the most fun I have 
> had in years, I can hardly defend spending my time duplicating work.)

There has been a lot of work in the arena of Voice over IP (VoIP) or
Internet Telephony.

I recall people mentioning some experimental work on linux-audio-dev,
but don't recall how much of it was low-latency.  Might be worth
googling for that or asking on the list.
-- 
  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

Re: Lowest latency: JACK, or ALSA directly?

[Asbjørn Sæbø]

On Thu, Nov 11, 2004 at 09:11:28AM -0600, Jack O'Quin wrote:
> asbjs@stud.ntnu.no (Asbjørn Sæbø) writes:
> 

> > I would assume that, as JACK adds an extra layer, it may also 
> > introduce extra latency. [...]

> JACK does not add extra latency.  Everything is synchronous with the
> basic ALSA cycle.  

That is very good.
 
> 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?

(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 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?  

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 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?


> [...]
> 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.)


> [...]
> There has been a lot of work in the arena of Voice over IP (VoIP) or
> Internet Telephony.

There has.  But as far as I know, most of it is concentrated on speech, 
and does not have the strict realtime requirements I have.  (A colleague 
of mine just measured the latency of normal phone-calls, which were 
from 100 to 200 milliseconds.)
 
> I recall people mentioning some experimental work on linux-audio-dev,
> but don't recall how much of it was low-latency.  Might be worth
> googling for that or asking on the list.

I will.

Thanks!
Asbjørn


-------------------------------------------------------
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

Re: Lowest latency: JACK, or ALSA directly?

[Jack O'Quin]

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

Re: Lowest latency: JACK, or ALSA directly?

[Takashi Iwai]

At 12 Nov 2004 10:42:33 -0600,
Jack O'Quin wrote:
> 
> > (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.

Regarding JACK's latency:  can JACK handle more than two periods with
the minimal latency?  That is, keeping only two periods active (the
current playing and the next periods), you can achieve the same
latency even if the buffer consists of more than two periods.

I'm asking this because some boards (e.g. RME32/96) have the fixed
buffer size, and can't take the configuration as two periods per
buffer.  IIRC, JACK fills all the buffer at the first sequence, and
this results in the higher latency than necessary.

Correct me if I'm wrong.


Takashi


-------------------------------------------------------
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_id=5588&alloc_id=12065&op=click

Re: Lowest latency: JACK, or ALSA directly?

[Jack O'Quin]

Takashi Iwai <tiwai@suse.de> writes:

> At 12 Nov 2004 10:42:33 -0600,
> Jack O'Quin wrote:
> > 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.
> 
> Regarding JACK's latency:  can JACK handle more than two periods with
> the minimal latency?  That is, keeping only two periods active (the
> current playing and the next periods), you can achieve the same
> latency even if the buffer consists of more than two periods.
> 
> I'm asking this because some boards (e.g. RME32/96) have the fixed
> buffer size, and can't take the configuration as two periods per
> buffer.  IIRC, JACK fills all the buffer at the first sequence, and
> this results in the higher latency than necessary.
> 
> Correct me if I'm wrong.

I believe you are correct about this.  You probably understand it
better than I do.  :-)

Is this something we could fix in JACK's ALSA driver backend?
-- 
  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_id=5588&alloc_id=12065&op=click

Re: Lowest latency: JACK, or ALSA directly?

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]

At 12 Nov 2004 11:19:25 -0600,
Jack O'Quin wrote:
> 
> Takashi Iwai <tiwai@suse.de> writes:
> 
> > At 12 Nov 2004 10:42:33 -0600,
> > Jack O'Quin wrote:
> > > 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.
> > 
> > Regarding JACK's latency:  can JACK handle more than two periods with
> > the minimal latency?  That is, keeping only two periods active (the
> > current playing and the next periods), you can achieve the same
> > latency even if the buffer consists of more than two periods.
> > 
> > I'm asking this because some boards (e.g. RME32/96) have the fixed
> > buffer size, and can't take the configuration as two periods per
> > buffer.  IIRC, JACK fills all the buffer at the first sequence, and
> > this results in the higher latency than necessary.
> > 
> > Correct me if I'm wrong.
> 
> I believe you are correct about this.  You probably understand it
> better than I do.  :-)
> 
> Is this something we could fix in JACK's ALSA driver backend?

We can set different values to avail_min for playback and capture
directions.  For getting the minimal latency, set
(nperiods - 1) * period_size for playback and period_size for
capture.

The patch attached adds a new option -f to specify the filling
periods.  As default (= 0), it's identical with nperiods, so the old
behavior is kept.

Note that it's not tested at all, as usual ;)


Takashi

[-- Attachment #2: Type: text/plain, Size: 5417 bytes --]

--- jack-audio-connection-kit-0.99.0/drivers/alsa/alsa_driver.c-dist	2004-11-15 15:00:06.000000000 +0100
+++ jack-audio-connection-kit-0.99.0/drivers/alsa/alsa_driver.c	2004-11-17 15:53:45.517659988 +0100
@@ -508,8 +508,15 @@ alsa_driver_configure_stream (alsa_drive
 	}
 #endif
 
-	if ((err = snd_pcm_sw_params_set_avail_min (
-		     handle, sw_params, driver->frames_per_cycle)) < 0) {
+	if (handle == driver->playback_handle)
+		err = snd_pcm_sw_params_set_avail_min (
+			handle, sw_params,
+			driver->frames_per_cycle * (driver->user_nperiods - driver->user_nfills + 1));
+	else
+		err = snd_pcm_sw_params_set_avail_min (
+			handle, sw_params, driver->frames_per_cycle);
+			
+	if (err < 0) {
 		jack_error ("ALSA: cannot set avail min for %s", stream_name);
 		return -1;
 	}
@@ -527,6 +534,7 @@ static int 
 alsa_driver_set_parameters (alsa_driver_t *driver,
 			    jack_nframes_t frames_per_cycle,
 			    jack_nframes_t user_nperiods,
+			    jack_nframes_t user_nfills,
 			    jack_nframes_t rate)
 {
 	int dir;
@@ -542,6 +550,15 @@ alsa_driver_set_parameters (alsa_driver_
 	driver->frames_per_cycle = frames_per_cycle;
 	driver->user_nperiods = user_nperiods;
 
+	if (user_nfills < 2)
+		user_nfills = user_nperiods;
+	else if (user_nfills > user_nperiods) {
+		fprintf (stderr, "nfills %d > nperiods %d\n",
+			 (int)user_nfills, (int)user_nperiods);
+		user_nfills = user_nperiods;
+	}
+	driver->user_nfills = user_nfills;
+
 	fprintf (stderr, "configuring for %" PRIu32 "Hz, period = %"
 		 PRIu32 " frames, buffer = %" PRIu32 " periods\n",
 		 rate, frames_per_cycle, user_nperiods);
@@ -835,13 +852,15 @@ static int
 alsa_driver_reset_parameters (alsa_driver_t *driver,
 			      jack_nframes_t frames_per_cycle,
 			      jack_nframes_t user_nperiods,
+			      jack_nframes_t user_nfills,
 			      jack_nframes_t rate)
 {
 	/* XXX unregister old ports ? */
 	alsa_driver_release_channel_dependent_memory (driver);
 	return alsa_driver_set_parameters (driver,
 					   frames_per_cycle,
-					   user_nperiods, rate);
+					   user_nperiods,
+					   user_nfills,rate);
 }
 
 static int
@@ -955,11 +974,11 @@ alsa_driver_start (alsa_driver_t *driver
 		
 		for (chn = 0; chn < driver->playback_nchannels; chn++) {
 			alsa_driver_silence_on_channel (driver, chn,
-							driver->buffer_frames);
+							driver->user_nfills * driver->frames_per_cycle);
 		}
 		
 		snd_pcm_mmap_commit (driver->playback_handle, poffset,
-				     driver->buffer_frames);
+				     driver->user_nfills * driver->frames_per_cycle);
 		
 		if ((err = snd_pcm_start (driver->playback_handle)) < 0) {
 			jack_error ("could not start playback (%s)",
@@ -1444,6 +1463,7 @@ alsa_driver_bufsize (alsa_driver_t* driv
 {
 	return alsa_driver_reset_parameters (driver, nframes,
 					     driver->user_nperiods,
+					     driver->user_nfills,
 					     driver->frame_rate);
 }
 
@@ -1853,6 +1873,7 @@ alsa_driver_new (char *name, char *playb
 		 jack_client_t *client, 
 		 jack_nframes_t frames_per_cycle,
 		 jack_nframes_t user_nperiods,
+		 jack_nframes_t user_nfills,
 		 jack_nframes_t rate,
 		 int hw_monitoring,
 		 int hw_metering,
@@ -2092,7 +2113,8 @@ alsa_driver_new (char *name, char *playb
 	}
 
 	if (alsa_driver_set_parameters (driver, frames_per_cycle,
-					user_nperiods, rate)) {
+					user_nperiods,
+					user_nfills, rate)) {
 		alsa_driver_delete (driver);
 		return 0;
 	}
@@ -2270,6 +2292,14 @@ driver_get_descriptor ()
 	strcpy (params[i].long_desc, params[i].short_desc);
 
 	i++;
+	strcpy (params[i].name, "nfills");
+	params[i].character  = 'f';
+	params[i].type       = JackDriverParamUInt;
+	params[i].value.ui   = 0;
+	strcpy (params[i].short_desc, "Number of filled periods");
+	strcpy (params[i].long_desc, params[i].short_desc);
+
+	i++;
 	strcpy (params[i].name, "hwmon");
 	params[i].character  = 'H';
 	params[i].type       = JackDriverParamBool;
@@ -2360,6 +2390,7 @@ driver_initialize (jack_client_t *client
         jack_nframes_t srate = 48000;
 	jack_nframes_t frames_per_interrupt = 1024;
 	unsigned long user_nperiods = 2;
+	unsigned long user_nfills = 0;
 	char *playback_pcm_name = "hw:0";
 	char *capture_pcm_name = "hw:0";
 	int hw_monitoring = FALSE;
@@ -2429,6 +2460,10 @@ driver_initialize (jack_client_t *client
 			user_nperiods = param->value.ui;
 			break;
 				
+		case 'f':
+			user_nfills = param->value.ui;
+			break;
+
 		case 's':
 			soft_mode = param->value.i;
 			break;
@@ -2462,7 +2497,7 @@ driver_initialize (jack_client_t *client
 	return alsa_driver_new ("alsa_pcm", playback_pcm_name,
 				capture_pcm_name, client,
 				frames_per_interrupt, 
-				user_nperiods, srate, hw_monitoring,
+				user_nperiods, user_nfills, srate, hw_monitoring,
 				hw_metering, capture, playback, dither,
 				soft_mode, monitor, 
 				user_capture_nchnls, user_playback_nchnls,
--- jack-audio-connection-kit-0.99.0/drivers/alsa/alsa_driver.h-dist	2004-11-15 15:06:52.000000000 +0100
+++ jack-audio-connection-kit-0.99.0/drivers/alsa/alsa_driver.h	2004-11-15 15:14:30.000000000 +0100
@@ -91,6 +91,7 @@ typedef struct {
     snd_pcm_format_t              capture_sample_format;
     float                         max_sample_val;
     unsigned long                 user_nperiods;
+    unsigned long                 user_nfills;
     unsigned long                 nfragments;
     unsigned long                 last_mask;
     snd_ctl_t                    *ctl_handle;

Re: Lowest latency: JACK, or ALSA directly?

[Jack O'Quin]

> > Takashi Iwai <tiwai@suse.de> writes:
> > > I'm asking this because some boards (e.g. RME32/96) have the fixed
> > > buffer size, and can't take the configuration as two periods per
> > > buffer.  IIRC, JACK fills all the buffer at the first sequence, and
> > > this results in the higher latency than necessary.
> > > 
> > > Correct me if I'm wrong.

> At 12 Nov 2004 11:19:25 -0600,
> Jack O'Quin wrote:
> > I believe you are correct about this.  You probably understand it
> > better than I do.  :-)
> > 
> > Is this something we could fix in JACK's ALSA driver backend?

Takashi Iwai <tiwai@suse.de> writes:
> We can set different values to avail_min for playback and capture
> directions.  For getting the minimal latency, set
> (nperiods - 1) * period_size for playback and period_size for
> capture.
> 
> The patch attached adds a new option -f to specify the filling
> periods.  As default (= 0), it's identical with nperiods, so the old
> behavior is kept.

Thanks for the patch!

Not sure I completely understand how to document this.  Is -f
effectively setting the output latency, with -n as the default?

Is there some way users could just set the desired latency directly,
or even request the minimum number of periods?  Is the minimum always
2?  What happens if the user specifies -f1?
-- 
  joq


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Lowest latency: JACK, or ALSA directly?

[Takashi Iwai]

At 17 Nov 2004 11:32:15 -0600,
Jack O'Quin wrote:
> 
> 
> > > Takashi Iwai <tiwai@suse.de> writes:
> > > > I'm asking this because some boards (e.g. RME32/96) have the fixed
> > > > buffer size, and can't take the configuration as two periods per
> > > > buffer.  IIRC, JACK fills all the buffer at the first sequence, and
> > > > this results in the higher latency than necessary.
> > > > 
> > > > Correct me if I'm wrong.
> 
> > At 12 Nov 2004 11:19:25 -0600,
> > Jack O'Quin wrote:
> > > I believe you are correct about this.  You probably understand it
> > > better than I do.  :-)
> > > 
> > > Is this something we could fix in JACK's ALSA driver backend?
> 
> Takashi Iwai <tiwai@suse.de> writes:
> > We can set different values to avail_min for playback and capture
> > directions.  For getting the minimal latency, set
> > (nperiods - 1) * period_size for playback and period_size for
> > capture.
> > 
> > The patch attached adds a new option -f to specify the filling
> > periods.  As default (= 0), it's identical with nperiods, so the old
> > behavior is kept.
> 
> Thanks for the patch!
> 
> Not sure I completely understand how to document this.  Is -f
> effectively setting the output latency, with -n as the default?
 
Well, it's so just because I didn't want to break the compatible
behavior.

With this model, basically the number of periods in the buffer doesn't
mean the latency at all but is required just for the stream
configuration.  The required condition is only nperiods >= 2.
So, this option isn't even necessary if we query the nearest buffer
size to "f-val * period_size".  Maybe this would be a better
implementation from the perspective of usability.

The playback latency is defined with -f option (the capture latency is
always minimal).  The minival value is 2.  Larger value means more
robustness.  For example, on some boards with the unreliable interrupt
handling (like ymfpci), one should set bigger than 2.
As mentioned, its default is as same as -n value, corresponding to the
_maximal_ latency.  It's just for compatibility.
It's fine to set this default to 2 if you think it's better.


> Is there some way users could just set the desired latency directly,
> or even request the minimum number of periods?  Is the minimum always
> 2?  What happens if the user specifies -f1?

2 periods (i.e. double buffer) are effectively the minimal latency.
The -f option doesn't acccept less than 2 or bigger than -n.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Lowest latency: JACK, or ALSA directly?

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

At Wed, 17 Nov 2004 19:28:46 +0100,
I wrote:
> 
> With this model, basically the number of periods in the buffer doesn't
> mean the latency at all but is required just for the stream
> configuration.  The required condition is only nperiods >= 2.
> So, this option isn't even necessary if we query the nearest buffer
> size to "f-val * period_size".  Maybe this would be a better
> implementation from the perspective of usability.

Ok, the attached below is more radical change.  The -f option is
removed and the semantics of -n option is changed.  It means the
minimal playback latency requested by user.
The buffer size doesn't have to be exactly nperiods * period_size.
JACK accepts more periods returned from the driver than requested.
Also, the different number of periods are accepted, too, for playback
and capture directions.

Untested as usual :)


(BTW, the jack code is still based on the older ALSA API.
 Is this intentional?)

Takashi

[-- Attachment #2: Type: text/plain, Size: 8768 bytes --]

--- jack-audio-connection-kit-0.99.0/drivers/alsa/alsa_driver.c-dist	2004-11-15 15:00:06.000000000 +0100
+++ jack-audio-connection-kit-0.99.0/drivers/alsa/alsa_driver.c	2004-11-17 20:34:42.623799183 +0100
@@ -325,6 +325,7 @@ alsa_driver_configure_stream (alsa_drive
 			      snd_pcm_t *handle, 
 			      snd_pcm_hw_params_t *hw_params, 
 			      snd_pcm_sw_params_t *sw_params, 
+			      unsigned int *nperiodsp,
 			      unsigned long *nchns,unsigned long sample_width)
 {
 	int err, format;
@@ -436,13 +437,23 @@ alsa_driver_configure_stream (alsa_drive
 		return -1;
 	}
 
-	if ((err = snd_pcm_hw_params_set_periods (handle, hw_params,
-						  driver->user_nperiods, 0))
+	*nperiodsp = driver->user_nperiods;
+	snd_pcm_hw_params_set_periods_min (handle, hw_params, nperiodsp, NULL);
+	*nperiodsp = driver->user_nperiods;
+	if ((*nperiodsp = snd_pcm_hw_params_set_periods_near (handle, hw_params,
+							      *nperiodsp, NULL))
 	    < 0) {
 		jack_error ("ALSA: cannot set number of periods to %u for %s",
-			    driver->user_nperiods, stream_name);
+			    *nperiodsp, stream_name);
 		return -1;
 	}
+
+	if (*nperiodsp < driver->user_nperiods) {
+		jack_error ("ALSA: got smaller periods %u than %u for %s",
+			    *nperiodsp, (unsigned int)driver->user_nperiods, stream_name);
+		return -1;
+	}
+	fprintf(stderr, "nperiods = %d for %s\n", *nperiodsp, stream_name);
 	
 	if (!jack_power_of_two(driver->frames_per_cycle)) {
 		jack_error("JACK: frames must be a power of two "
@@ -451,12 +462,12 @@ alsa_driver_configure_stream (alsa_drive
 	}
 
 	if ((err = snd_pcm_hw_params_set_buffer_size (handle, hw_params,
-						      driver->user_nperiods *
+						      *nperiodsp *
 						      driver->frames_per_cycle))
 	    < 0) {
 		jack_error ("ALSA: cannot set buffer length to %" PRIu32
 			    " for %s",
-			    driver->user_nperiods * driver->frames_per_cycle,
+			    *nperiodsp * driver->frames_per_cycle,
 			    stream_name);
 		return -1;
 	}
@@ -475,7 +486,7 @@ alsa_driver_configure_stream (alsa_drive
 		return -1;
 	}
 
-	stop_th = driver->user_nperiods * driver->frames_per_cycle;
+	stop_th = *nperiodsp * driver->frames_per_cycle;
 	if (driver->soft_mode) {
 		stop_th = (snd_pcm_uframes_t)-1;
 	}
@@ -496,20 +507,27 @@ alsa_driver_configure_stream (alsa_drive
 
 #if 0
 	fprintf (stderr, "set silence size to %lu * %lu = %lu\n",
-		 driver->frames_per_cycle, driver->user_nperiods,
-		 driver->frames_per_cycle * driver->user_nperiods);
+		 driver->frames_per_cycle, *nperiodsp,
+		 driver->frames_per_cycle * *nperiodsp);
 
 	if ((err = snd_pcm_sw_params_set_silence_size (
 		     handle, sw_params,
-		     driver->frames_per_cycle * driver->user_nperiods)) < 0) {
+		     driver->frames_per_cycle * *nperiodsp)) < 0) {
 		jack_error ("ALSA: cannot set silence size for %s",
 			    stream_name);
 		return -1;
 	}
 #endif
 
-	if ((err = snd_pcm_sw_params_set_avail_min (
-		     handle, sw_params, driver->frames_per_cycle)) < 0) {
+	if (handle == driver->playback_handle)
+		err = snd_pcm_sw_params_set_avail_min (
+			handle, sw_params,
+			driver->frames_per_cycle * (*nperiodsp - driver->user_nperiods + 1));
+	else
+		err = snd_pcm_sw_params_set_avail_min (
+			handle, sw_params, driver->frames_per_cycle);
+			
+	if (err < 0) {
 		jack_error ("ALSA: cannot set avail min for %s", stream_name);
 		return -1;
 	}
@@ -532,8 +550,6 @@ alsa_driver_set_parameters (alsa_driver_
 	int dir;
 	unsigned int p_period_size = 0;
 	unsigned int c_period_size = 0;
-	unsigned int p_nfragments = 0;
-	unsigned int c_nfragments = 0;
 	channel_t chn;
 	unsigned int pr = 0;
 	unsigned int cr = 0;
@@ -554,6 +570,7 @@ alsa_driver_set_parameters (alsa_driver_
 			    driver->capture_handle,
 			    driver->capture_hw_params,
 			    driver->capture_sw_params,
+			    &driver->capture_nperiods,
 			    &driver->capture_nchannels,
 			    driver->capture_sample_bytes)) {
 			jack_error ("ALSA: cannot configure capture channel");
@@ -569,6 +586,7 @@ alsa_driver_set_parameters (alsa_driver_
 			    driver->playback_handle,
 			    driver->playback_hw_params,
 			    driver->playback_sw_params,
+			    &driver->playback_nperiods,
 			    &driver->playback_nchannels,
 			    driver->playback_sample_bytes)) {
 			jack_error ("ALSA: cannot configure playback channel");
@@ -623,9 +641,6 @@ alsa_driver_set_parameters (alsa_driver_
 		p_period_size =
 			snd_pcm_hw_params_get_period_size (
 				driver->playback_hw_params, &dir);
-		p_nfragments =
-			snd_pcm_hw_params_get_periods (
-				driver->playback_hw_params, &dir);
 		driver->playback_sample_format = (snd_pcm_format_t)
 			snd_pcm_hw_params_get_format (
 				driver->playback_hw_params);
@@ -647,9 +662,6 @@ alsa_driver_set_parameters (alsa_driver_
 		c_period_size =
 			snd_pcm_hw_params_get_period_size (
 				driver->capture_hw_params, &dir);
-		c_nfragments =
-			snd_pcm_hw_params_get_periods (
-				driver->capture_hw_params, &dir);
 		driver->capture_sample_format = (snd_pcm_format_t)
 			snd_pcm_hw_params_get_format (
 				driver->capture_hw_params);
@@ -667,26 +679,6 @@ alsa_driver_set_parameters (alsa_driver_
 		}
 	}
 
-	if (driver->capture_handle && driver->playback_handle) {
-		if (p_nfragments != c_nfragments) {
-			jack_error ("alsa_pcm: different period counts for "
-				    "playback and capture!");
-			return -1;
-		}
-
-		driver->nfragments = c_nfragments;
-
-	} else if (driver->capture_handle) {
-
-		driver->nfragments = c_nfragments;
-
-	} else {
-
-		driver->nfragments = p_nfragments;
-
-	}
-
-	driver->buffer_frames = driver->frames_per_cycle * driver->nfragments;
 	driver->playback_sample_bytes =
 		snd_pcm_format_physical_width (driver->playback_sample_format)
 		/ 8;
@@ -934,7 +926,7 @@ alsa_driver_start (alsa_driver_t *driver
 		
 		pavail = snd_pcm_avail_update (driver->playback_handle);
 
-		if (pavail != driver->buffer_frames) {
+		if (pavail != driver->frames_per_cycle * driver->playback_nperiods) {
 			jack_error ("ALSA: full buffer not available at start");
 			return -1;
 		}
@@ -955,11 +947,11 @@ alsa_driver_start (alsa_driver_t *driver
 		
 		for (chn = 0; chn < driver->playback_nchannels; chn++) {
 			alsa_driver_silence_on_channel (driver, chn,
-							driver->buffer_frames);
+							driver->user_nperiods * driver->frames_per_cycle);
 		}
 		
 		snd_pcm_mmap_commit (driver->playback_handle, poffset,
-				     driver->buffer_frames);
+				     driver->user_nperiods * driver->frames_per_cycle);
 		
 		if ((err = snd_pcm_start (driver->playback_handle)) < 0) {
 			jack_error ("could not start playback (%s)",
@@ -1107,10 +1099,11 @@ alsa_driver_silence_untouched_channels (
 					jack_nframes_t nframes)
 {
 	channel_t chn;
+	jack_nframes_t buffer_frames = driver->frames_per_cycle * driver->playback_nperiods;
 
 	for (chn = 0; chn < driver->playback_nchannels; chn++) {
 		if ((driver->channels_not_done & (1<<chn))) { 
-			if (driver->silent[chn] < driver->buffer_frames) {
+			if (driver->silent[chn] < buffer_frames) {
 				alsa_driver_silence_on_channel_no_mark (
 					driver, chn, nframes);
 				driver->silent[chn] += nframes;
@@ -1686,7 +1679,7 @@ alsa_driver_attach (alsa_driver_t *drive
 		 * (external) latency
 		*/
 		jack_port_set_latency (port, driver->frames_per_cycle
-				       * driver->nfragments);
+				       * driver->user_nperiods);
 
 		driver->playback_ports =
 			jack_slist_append (driver->playback_ports, port);
@@ -1901,7 +1894,6 @@ alsa_driver_new (char *name, char *playb
 	driver->ctl_handle = 0;
 	driver->hw = 0;
 	driver->capture_and_playback_not_synced = FALSE;
-	driver->nfragments = 0;
 	driver->max_nchannels = 0;
 	driver->user_nchannels = 0;
 	driver->playback_nchannels = user_playback_nchnls;
--- jack-audio-connection-kit-0.99.0/drivers/alsa/alsa_driver.h-dist	2004-11-15 15:06:52.000000000 +0100
+++ jack-audio-connection-kit-0.99.0/drivers/alsa/alsa_driver.h	2004-11-17 20:34:46.671045579 +0100
@@ -84,14 +84,14 @@ typedef struct {
     char                         *alsa_name_playback;
     char                         *alsa_name_capture;
     char                         *alsa_driver;
-    snd_pcm_uframes_t             buffer_frames;
     unsigned long                 channels_not_done;
     unsigned long                 channel_done_bits;
     snd_pcm_format_t              playback_sample_format;
     snd_pcm_format_t              capture_sample_format;
     float                         max_sample_val;
     unsigned long                 user_nperiods;
-    unsigned long                 nfragments;
+    unsigned int                  playback_nperiods;
+    unsigned int                  capture_nperiods;
     unsigned long                 last_mask;
     snd_ctl_t                    *ctl_handle;
     snd_pcm_t                    *playback_handle;

Re: Lowest latency: JACK, or ALSA directly?

[Jack O'Quin]

Takashi Iwai <tiwai@suse.de> writes:

> At Wed, 17 Nov 2004 19:28:46 +0100,
> I wrote:
> > 
> > With this model, basically the number of periods in the buffer doesn't
> > mean the latency at all but is required just for the stream
> > configuration.  The required condition is only nperiods >= 2.
> > So, this option isn't even necessary if we query the nearest buffer
> > size to "f-val * period_size".  Maybe this would be a better
> > implementation from the perspective of usability.
> 
> Ok, the attached below is more radical change.  The -f option is
> removed and the semantics of -n option is changed.  It means the
> minimal playback latency requested by user.
> The buffer size doesn't have to be exactly nperiods * period_size.
> JACK accepts more periods returned from the driver than requested.
> Also, the different number of periods are accepted, too, for playback
> and capture directions.

I think that is much better from a user perspective.  IIUC, it is
backward compatible in the sense that every case that used to work
still does, but now some cards with minimum buffer sizes will be able
to support lower playback latency.

For user documentation, I can now describe --nperiods purely in terms
of playback latency, while noting that on some devices the actual
buffer may be larger.

> Untested as usual :)

I'll try it here with my Delta-66.  

That won't test any of the strange cases where -nperiods=2 but the
device actually requires a three-period buffer.  Which cards do you
know of that are affected by this?

> (BTW, the jack code is still based on the older ALSA API.
>  Is this intentional?)

It was intentional last year so JACK would work with all ALSA
versions.  A patch was recently submitted to use the newer interfaces.
The consensus on jackit-devel was that it is time to do that now, but
the patch has not yet been committed to CVS.

(Patch follows for your review...)

> From: Rohan Drape <rd@alphalink.com.au>
> Subject: [Jackit-devel] [Patch] Update alsa_driver to use new SW/HW param interface
> To: jackit-devel@lists.sourceforge.net
> Date: 02 Nov 2004 13:04:34 +1100
> 
> 
> As subject.  For curious reasons I had to make these changes some time
> ago.  I do not know if they are appropriate for the tree proper.
> 
> Regards,
> Rohan
> 
> [2. text/x-patch; 2004-11-02.0.patch]...

Index: alsa_driver.c
===================================================================
RCS file: /cvsroot/jackit/jack/drivers/alsa/alsa_driver.c,v
retrieving revision 1.57
diff -u -r1.57 alsa_driver.c
--- alsa_driver.c	20 Oct 2004 12:10:28 -0000	1.57
+++ alsa_driver.c	2 Nov 2004 01:44:25 -0000
@@ -385,9 +385,10 @@
 			break;
 	} 
 
-	if ((err = snd_pcm_hw_params_set_rate_near (handle, hw_params,
-						    driver->frame_rate, 0))
-	    < 0) {
+	unsigned int frame_rate = driver->frame_rate ;
+	err = snd_pcm_hw_params_set_rate_near (handle, hw_params, &frame_rate, NULL) ;
+	driver->frame_rate = frame_rate ;
+	if (err < 0) {
 		jack_error ("ALSA: cannot set sample/frame rate to %"
 			    PRIu32 " for %s", driver->frame_rate,
 			    stream_name);
@@ -396,7 +397,9 @@
 	if (!*nchns) {
 		/*if not user-specified, try to find the maximum
 		 * number of channels */
-		*nchns = snd_pcm_hw_params_get_channels_max (hw_params);
+		unsigned int channels_max ;
+		err = snd_pcm_hw_params_get_channels_max (hw_params, &channels_max);
+		*nchns = channels_max ;
 
 		if (*nchns > 1024) { 
 
@@ -529,14 +532,14 @@
 			    jack_nframes_t user_nperiods,
 			    jack_nframes_t rate)
 {
-	int dir;
-	unsigned int p_period_size = 0;
-	unsigned int c_period_size = 0;
+	snd_pcm_uframes_t p_period_size = 0;
+	snd_pcm_uframes_t c_period_size = 0;
 	unsigned int p_nfragments = 0;
 	unsigned int c_nfragments = 0;
 	channel_t chn;
 	unsigned int pr = 0;
 	unsigned int cr = 0;
+	int err, dir;
 
 	driver->frame_rate = rate;
 	driver->frames_per_cycle = frames_per_cycle;
@@ -579,13 +582,11 @@
 	/* check the rate, since thats rather important */
 
 	if (driver->playback_handle) {
-		int dir;
-		pr = snd_pcm_hw_params_get_rate (driver->playback_hw_params, &dir);
+		snd_pcm_hw_params_get_rate (driver->playback_hw_params, &pr, &dir);
 	}
 
 	if (driver->capture_handle) {
-		int dir;
-		cr = snd_pcm_hw_params_get_rate (driver->capture_hw_params, &dir);
+		snd_pcm_hw_params_get_rate (driver->capture_hw_params, &cr, &dir);
 	}
 
 	if (driver->capture_handle && driver->playback_handle) {
@@ -620,19 +621,15 @@
 	/* check the fragment size, since thats non-negotiable */
 	
 	if (driver->playback_handle) {
-		p_period_size =
-			snd_pcm_hw_params_get_period_size (
-				driver->playback_hw_params, &dir);
-		p_nfragments =
-			snd_pcm_hw_params_get_periods (
-				driver->playback_hw_params, &dir);
-		driver->playback_sample_format = (snd_pcm_format_t)
-			snd_pcm_hw_params_get_format (
-				driver->playback_hw_params);
-		driver->playback_interleaved =
-			(snd_pcm_hw_params_get_access (
-				driver->playback_hw_params)
-			 == SND_PCM_ACCESS_MMAP_INTERLEAVED);
+		err = snd_pcm_hw_params_get_period_size (
+			driver->playback_hw_params, &p_period_size, &dir);
+		err = snd_pcm_hw_params_get_periods (
+			driver->playback_hw_params, &p_nfragments, &dir);
+		err = snd_pcm_hw_params_get_format (
+			driver->playback_hw_params, &(driver->playback_sample_format));
+		snd_pcm_access_t access ;
+		err = snd_pcm_hw_params_get_access (driver->playback_hw_params, &access);
+		driver->playback_interleaved = (access == SND_PCM_ACCESS_MMAP_INTERLEAVED);
 
 		if (p_period_size != driver->frames_per_cycle) {
 			jack_error ("alsa_pcm: requested an interrupt every %"
@@ -644,20 +641,16 @@
 	}
 
 	if (driver->capture_handle) {
-		c_period_size =
-			snd_pcm_hw_params_get_period_size (
-				driver->capture_hw_params, &dir);
-		c_nfragments =
-			snd_pcm_hw_params_get_periods (
-				driver->capture_hw_params, &dir);
-		driver->capture_sample_format = (snd_pcm_format_t)
-			snd_pcm_hw_params_get_format (
-				driver->capture_hw_params);
-		driver->capture_interleaved =
-			(snd_pcm_hw_params_get_access (
-				driver->capture_hw_params)
-			 == SND_PCM_ACCESS_MMAP_INTERLEAVED);
-	
+		err = snd_pcm_hw_params_get_period_size (
+			driver->capture_hw_params, &c_period_size, &dir);
+		err = snd_pcm_hw_params_get_periods (
+			driver->capture_hw_params, &c_nfragments, &dir);
+		err = snd_pcm_hw_params_get_format (
+			driver->capture_hw_params, &(driver->capture_sample_format));
+		snd_pcm_access_t access ;
+		err = snd_pcm_hw_params_get_access (driver->capture_hw_params, &access);
+		driver->capture_interleaved = (access == SND_PCM_ACCESS_MMAP_INTERLEAVED);
+
 		if (c_period_size != driver->frames_per_cycle) {
 			jack_error ("alsa_pcm: requested an interrupt every %"
 				    PRIu32
[3. text/x-patch; 2004-11-02.1.patch]...

Index: alsa_driver.h
===================================================================
RCS file: /cvsroot/jackit/jack/drivers/alsa/alsa_driver.h,v
retrieving revision 1.5
diff -u -r1.5 alsa_driver.h
--- alsa_driver.h	25 Mar 2004 19:31:50 -0000	1.5
+++ alsa_driver.h	2 Nov 2004 01:44:43 -0000
@@ -21,8 +21,6 @@
 #ifndef __jack_alsa_driver_h__
 #define __jack_alsa_driver_h__
 
-#define ALSA_PCM_OLD_HW_PARAMS_API
-#define ALSA_PCM_OLD_SW_PARAMS_API
 #include <alsa/asoundlib.h>
 
 #if __BYTE_ORDER == __LITTLE_ENDIAN

-- 
  joq


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Lowest latency: JACK, or ALSA directly?

[Takashi Iwai]

At 17 Nov 2004 20:07:57 -0600,
Jack O'Quin wrote:
> 
> > Untested as usual :)
> 
> I'll try it here with my Delta-66.  
> 
> That won't test any of the strange cases where -nperiods=2 but the
> device actually requires a three-period buffer.  Which cards do you
> know of that are affected by this?

rme32, rme96 and korg1212 have the fixed buffer size.
ymfpci has 3 periods as minimum, too.


> > (BTW, the jack code is still based on the older ALSA API.
> >  Is this intentional?)
> 
> It was intentional last year so JACK would work with all ALSA
> versions.  A patch was recently submitted to use the newer interfaces.
> The consensus on jackit-devel was that it is time to do that now, but
> the patch has not yet been committed to CVS.
> 
> (Patch follows for your review...)
> > [2. text/x-patch; 2004-11-02.0.patch]...
> @@ -620,19 +621,15 @@
(snip)
> +		err = snd_pcm_hw_params_get_period_size (
> +			driver->playback_hw_params, &p_period_size, &dir);
> +		err = snd_pcm_hw_params_get_periods (
> +			driver->playback_hw_params, &p_nfragments, &dir);
> +		err = snd_pcm_hw_params_get_format (
> +			driver->playback_hw_params, &(driver->playback_sample_format));
> +		snd_pcm_access_t access ;

^^^ the variable declaration should be moved in the beginning of the
block.

Otherwise it looks fine.
You could check the return value of snd_pcm_hw_params_get_*, but it's
usually ok.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Lowest latency: JACK, or ALSA directly?

[Paul Davis]

>As I understand it, JACK acts as a middle layer between a (jack-aware)
>application and the underlying ALSA libraries.  But it is also possible
>to program against the ALSA libraries directly (which I am doing now).
>
>I am writing an application for audio transfer over network, where the
>main goal is to achieve the lowest latency possible.  I would assume
>that, as JACK adds an extra layer, it may also introduce extra latency. =20
>Is that so?  And in that case, how much may be gained by using the ALSA
>libs directly, instead of going through ALSA?

it doesn't *add* any latency at all. what it might conceivably do is
to prevent a given application from reaching the lowest possible
latency, because of the extra context switching involved in JACK. so
far, however, this doesn't appear to be the case - people have JACK
running at the same latency settings as they could get with ALSA. so
the effect is marginal if its measurable at all.

>Although I so far barely have gotten into ALSA programming, it does seem
>to be manageable in difficulty. (Don't laugh, I am an aconcy austican, not a=20
>programmer.)  How is programming against JACK in comparison?

JACK is *massively* simpler.

>As far as I understand it, the main advantages of JACK are the=20
>possibility to connect together several applications, as well as the=20
>ability to keep these applications in sync.  That is however not very=20
>important to me now, as I will probably not need to connect to other=20
>programs.  Are there other important advantages?  And what are the=20
>disadvantages?

You can forget all about h/w configuration, sample format, and program
structure. JACK takes care of all that, though some people would say imposes it own
choices on your application

--p


-------------------------------------------------------
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_id=5588&alloc_id=12065&op=click

Re: Lowest latency: JACK, or ALSA directly?

[Asbjørn Sæbø]

On Thu, Nov 11, 2004 at 10:34:08AM -0500, Paul Davis wrote:
> [JACK]
> it doesn't *add* any latency at all. what it might conceivably do is
> to prevent a given application from reaching the lowest possible
> latency, because of the extra context switching involved in JACK. so
> far, however, this doesn't appear to be the case - people have JACK
> running at the same latency settings as they could get with ALSA. so
> the effect is marginal if its measurable at all.

That sounds very good.
 
> >Although I so far barely have gotten into ALSA programming, it does seem
> >to be manageable in difficulty. (Don't laugh, I am an aconcy austican, not a=20
> >programmer.)  How is programming against JACK in comparison?
> 
> JACK is *massively* simpler.

That also sounds very good.  It looks like I am in for a switch to JACK.
(Although I may miss the opportunity to dig myself into a hole digesting 
the ALSA API. ;-)


Thanks!

Asbjørn


-------------------------------------------------------
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

Re: Lowest latency: JACK, or ALSA directly?

[Gilles Degottex]

On Thursday 11 November 2004 16:34, Paul Davis wrote:
> it doesn't *add* any latency at all. what it might conceivably do is
> to prevent a given application from reaching the lowest possible
> latency, because of the extra context switching involved in JACK. so
> far, however, this doesn't appear to be the case - people have JACK
> running at the same latency settings as they could get with ALSA. so
> the effect is marginal if its measurable at all.

no latency ?? so why qjackctl show latency information ? (around 50ms for me)

> >Although I so far barely have gotten into ALSA programming, it does seem
> >to be manageable in difficulty. (Don't laugh, I am an aconcy austican, not
> > a=20 programmer.)  How is programming against JACK in comparison?

I already meet A LOT of difficulties when programming with ALSA: at the time I 
did (about 6 month) doc was not synchronized to my devel library and examples 
I found was completly obsolete ...
But you can control more things with ALSA (and so ALSA code is longer than 
JACK code). Personnaly I recommend you start with JACK, If there is no 
latency problem and you wont fight with the library.

regards
Gilles


-------------------------------------------------------
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_id=5588&alloc_id=12065&op=click

Re: Lowest latency: JACK, or ALSA directly?

[Giuliano Pochini]

On Fri, 12 Nov 2004, Gilles Degottex wrote:

> On Thursday 11 November 2004 16:34, Paul Davis wrote:
> > it doesn't *add* any latency at all. what it might conceivably do is
> > to prevent a given application from reaching the lowest possible
> > latency, because of the extra context switching involved in JACK. so
> > far, however, this doesn't appear to be the case - people have JACK
> > running at the same latency settings as they could get with ALSA. so
> > the effect is marginal if its measurable at all.
>
> no latency ?? so why qjackctl show latency information ? (around 50ms for me)

No, reread the sentence above: "it doesn't *add* any latency at all".
Since the latency is the length of the buffer, as long as the overhead
introduced by Jack is "small", it doesn't add latency. By "small" i mean
that is does not cause underruns, which depends on the buffer size. For
example if your system can handle buffers down to 1ms long, with Jack that
time is longer is eg. 2ms. But there is not difference in latency using a
2ms long buffer with Jack and the same with alsa-lib, because it's always
2ms.


--
Giuliano.


-------------------------------------------------------
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_id=5588&alloc_id=12065&op=click