List of JACK Frame & Period settings ideal for USB interface

[tbritton]

(This was split off by me from the SP/DIF discussion as it seemed appropriate to place this into its own thread.)

Since in Cadence you can over-ride the drop-down menu selections and type-in your own custom frames entry, you can enter the numbers below and thus achieve an even multiple of 1ms (that is, a whole-numbered latency figure) for use with USB interfaces which require that.

This follows the formula for latency from AutoStatic's post I found in Hardware that I'll replicate here for you:

(Frames/Sample Rate) * Period = Theoretical (or Math-derived) Latency

(actual latency depends upon other factors, but USB devices want the math-derived latency to be an even multiple of 1ms)

I created this spread-sheet that produced the numbers that generated even numbers for both periods (2 & 3), suggesting what may be possible ideal candidates for USB interfaces. I couldn't get the numbers to line-up under the labels, but you can figure out which are which.

NOTE: quite a few pieces of software and plug-ins expect frames that are a power of 2 (like guitarix). You might get weird errors when using frame numbers that are not a power of 2 or the plug-in/software may not even start at all.
ALSO note that JACK prefers a number of frames that is a power of two anyway. From the JACK man page:

-p, --period int
Specify the number of frames between JACK process() calls. This value must be a power of 2, and the
default is 1024. If you need low latency, set -p as low as you can go without seeing xruns. A
larger period size yields higher latency, but makes xruns less likely. The JACK capture latency in
seconds is --period divided by --rate

. [thx again to AutoStatic!]

[Items in dark-red won't work ideally with USB but were included to have the most common figures all represented in there.)
[Items in Green will work with any software or plugin requiring powers of two.]

(Frames / Sample Rate ) * Periods = Latency in ms
( 16 / 48000 ) * 3 = 1
( 24 / 48000 ) * 3 = 1.5
( 32 / 48000 ) * 3 = 2
( 48 / 48000 ) * 3 = 3
( 64 / 48000 ) * 3 = 4
( 72 / 48000 ) * 3 = 4.5
( 80 / 48000 ) * 3 = 5
( 96 / 48000 ) * 3 = 6
( 112 / 48000 ) * 3 = 7
( 128 / 48000 ) * 3 = 8
( 144 / 48000 ) * 3 = 9
( 160 / 48000 ) * 3 = 10
( 176 / 48000 ) * 3 = 11
( 256 / 48000 ) * 3 = 16
( 512 / 48000 ) * 3 = 32
( 960 / 48000 ) * 3 = 60
( 1024 / 48000 ) * 3 = 64
( 2048 / 48000 ) * 3 = 128
( 16 / 48000 ) * 2 = 0.6666666667
( 24 / 48000 ) * 2 = 1
( 32 / 48000 ) * 2 = 1.3333333333
( 48 / 48000 ) * 2 = 2
( 64 / 48000 ) * 2 = 2.6666666667
( 72 / 48000 ) * 2 = 3
( 80 / 48000 ) * 2 = 3.3333333333
( 96 / 48000 ) * 2 = 4
( 120 / 48000 ) * 2 = 5
( 128 / 48000 ) * 2 = 5.3333333333
( 144 / 48000 ) * 2 = 6
( 168 / 48000 ) * 2 = 7
( 192 / 48000 ) * 2 = 8
( 216 / 48000 ) * 2 = 9
( 240 / 48000 ) * 2 = 10
( 256 / 48000 ) * 2 = 10.6666666667
( 512 / 48000 ) * 2 = 21.3333333333
( 1024 / 48000 ) * 2 = 42.6666666667
( 2048 / 48000 ) * 2 = 85.3333333333
( 16 / 96000 ) * 3 = 0.5
( 24 / 96000 ) * 3 = 0.75
( 32 / 96000 ) * 3 = 1
( 48 / 96000 ) * 3 = 1.5
( 64 / 96000 ) * 3 = 2
( 72 / 96000 ) * 3 = 2.25
( 80 / 96000 ) * 3 = 2.5
( 96 / 96000 ) * 3 = 3
( 128 / 96000 ) * 3 = 4
( 160 / 96000 ) * 3 = 5
( 192 / 96000 ) * 3 = 6
( 224 / 96000 ) * 3 = 7
( 256 / 96000 ) * 3 = 8
( 288 / 96000 ) * 3 = 9
( 320 / 96000 ) * 3 = 10
( 512 / 96000 ) * 3 = 16
( 1024 / 96000 ) * 3 = 32
( 2048 / 96000 ) * 3 = 64
( 16 / 96000 ) * 2 = 0.3333333333
( 24 / 96000 ) * 2 = 0.5
( 32 / 96000 ) * 2 = 0.6666666667
( 48 / 96000 ) * 2 = 1
( 64 / 96000 ) * 2 = 1.3333333333
( 72 / 96000 ) * 2 = 1.5
( 80 / 96000 ) * 2 = 1.6666666667
( 96 / 96000 ) * 2 = 2
( 128 / 96000 ) * 2 = 2.6666666667
( 144 / 96000 ) * 2 = 3
( 192 / 96000 ) * 2 = 4
( 240 / 96000 ) * 2 = 5
( 256 / 96000 ) * 2 = 5.3333333333
( 288 / 96000 ) * 2 = 6
( 336 / 96000 ) * 2 = 7
( 384 / 96000 ) * 2 = 8
( 432 / 96000 ) * 2 = 9
( 480 / 96000 ) * 2 = 10
( 512 / 96000 ) * 2 = 10.6666666667
( 1024 / 96000 ) * 2 = 21.3333333333
( 2048 / 96000 ) * 2 = 42.6666666667
( 16 / 192000 ) * 3 = 0.25
( 24 / 192000 ) * 3 = 0.375
( 32 / 192000 ) * 3 = 0.5
( 48 / 192000 ) * 3 = 0.75
( 64 / 192000 ) * 3 = 1
( 72 / 192000 ) * 3 = 1.125
( 96 / 192000 ) * 3 = 1.5
( 128 / 192000 ) * 3 = 2
( 192 / 192000 ) * 3 = 3
( 256 / 192000 ) * 3 = 4
( 512 / 192000 ) * 3 = 8
( 1024 / 192000 ) * 3 = 16
( 2048 / 192000 ) * 3 = 32
( 16 / 192000 ) * 2 = 0.1666666667
( 24 / 192000 ) * 2 = 0.25
( 32 / 192000 ) * 2 = 0.3333333333
( 48 / 192000 ) * 2 = 0.5
( 64 / 192000 ) * 2 = 0.6666666667
( 72 / 192000 ) * 2 = 0.75
( 96 / 192000 ) * 2 = 1
( 128 / 192000 ) * 2 = 1.3333333333
( 256 / 192000 ) * 2 = 2.6666666667
( 512 / 192000 ) * 2 = 5.3333333333
( 1024 / 192000 ) * 2 = 10.6666666667
( 2048 / 192000 ) * 2 = 21.3333333333

Are those "oddball" frame values really going to work for you? Try them and please report back!

Would this matter to non-USB devices to have latencies which were whole multiples of 1ms? Or would they perhaps PREFER non-whole numbers?

BTW - Though AutoStatic had declared (probably true in reality) that this even-multiple latency was only possible with 48000, 96000 and 192000 sample rates, it seems that 44100 actually does have two frame rate values that come out even that might work for USB! (Not sure these would really work in practicality...)

(147 frames / 44100) * 3 periods = 10ms
(441 frames / 44100) * 2 periods = 20ms

Terry

A small caveat when using Guitarix

Many of the effects and amp simulators in Guitarix depend on a library which expects your frames/period to be a power of two (16, 32, 64, 128, etc), and large parts of Guitarix fail to work properly if this is not the case. This can easily be resolved by choosing periods=3, which enables most of the “conventional” 2^n frames/period values. In fact, if you choose periods=2, it will be impossible to get Guitarix to work properly while also having a latency which is an integral number of ms.

[autostatic]

(Frames/Sample Rate) * Period = Theoretical (or Math-derived) Latency

Actually you're calculating the system or nominal latency here, so the minimal latency a JACK client has when recording, producing or processing audio.

(actual latency depends upon other factors, but USB devices want the math-derived latency to be an even multiple of 1ms)

I'll try to look up the mail by Clemens Ladisch in which he explains this. For more information on latency I'd like to point out this great Wiki article: http://apps.linuxaudio.org/wiki/jack_latency_tests

I created this spread-sheet that produced the numbers that generated even numbers for both periods (2 & 3), suggesting what may be possible ideal candidates for USB interfaces. I couldn't get the numbers to line-up under the labels, but you can figure out which are which.

Very handy! You might want to put it in our Wiki as a Wiki allows to create tables. Actually, information such as you're providing here doesn't belong on a forum I think, it fits better in a Wiki.

Are those "oddball" frame values really going to work for you? Try them and please report back!

Well, I can run my USB interface at 48/48000*2, haven't tried any other oddball frame values.

Would this matter to non-USB devices to have latencies which were whole multiples of 1ms? Or would they perhaps PREFER non-whole numbers?

It only matters for bus-driven devices like USB and FireWire devices. It doesn't apply to PCi(e).

BTW - Though AutoStatic had declared (probably true in reality) that this even-multiple latency was only possible with 48000, 96000 and 192000 sample rates, it seems that 44100 actually does have two frame rate values that come out even that might work for USB! (Not sure these would really work in practicality...)

(147 frames / 44100) * 3 periods = 10ms
(441 frames / 44100) * 2 periods = 20ms

Ha, never thought of this actually, I'm going to try these settings out on my Raspberry Pi as I can only use my USB interface @ 44.1KHz with the RPi. I'm now using 128/44100*2 and have to use the -s ALSA option with JACK to suppress the continuous stream of xruns. Maybe using 147 frames improves the situation.

[tbritton]

AutoStatic,

I put it into a Wiki entry as you suggested. (didn't figure out how to do tables yet, but I will delve more deeply into the documentation for the wiki syntax later.)

http://wiki.linuxmusicians.com/doku.php ... _interface

Thanks for the feedback and corrections!

Terry

[autostatic]

Looks good! Thanks! Just one thing, I think you can't license an article in the Wiki the way you'd want to. The whole Wiki is CC by-nc-sa licensed at the moment and I'm not sure what the implications are if you impose a different license on an article.

[tbritton]

Looks good! Thanks! Just one thing, I think you can't license an article in the Wiki the way you'd want to. The whole Wiki is CC by-nc-sa licensed at the moment and I'm not sure what the implications are if you impose a different license on an article.

Oh, I didn't know - I'll change it. I was just following (well, copied and pasted) the lead of the JACKD article I had been reading.

Thanks for letting me know!

Terry

[autostatic]

Maybe something worthwhile to add to the article: quite some software and plug-ins expect frames that are a power of 2 (like guitarix). You might get weird errors when using frame numbers that are not a power of 2 or the plug-in/software won't even start at all.

[tbritton]

Maybe something worthwhile to add to the article: quite some software and plug-ins expect frames that are a power of 2 (like guitarix). You might get weird errors when using frame numbers that are not a power of 2 or the plug-in/software won't even start at all.

Great information to have! I've added that to the WIKI article and to the forum version.

Thank you once again, AutoStatic!

Terry

[LeadOut]

I put this into the wiki as well, but thought I'd mention it here: I discovered yesterday that Guitarix doesn't like frames/period values that are not powers of two. If you have periods=2 and are trying a weird value of frames/period (like 48) to get your latency to be an integral number of milliseconds, then about half of Guitarix will throw errors and fail.

This is not too much of a problem, as there are plenty of settings you can choose with periods=3, but it did confuse me for a little while.

[autostatic]

Maybe it would be better to add some kind of preface with a warning that JACK prefers a number of frames that is a power of two. From the JACK man page:

-p, --period int
Specify the number of frames between JACK process() calls. This value must be a power of 2, and the
default is 1024. If you need low latency, set -p as low as you can go without seeing xruns. A
larger period size yields higher latency, but makes xruns less likely. The JACK capture latency in
seconds is --period divided by --rate.

I have to admit though that using numbers that are not a power of two seems to work just fine in most cases. Maybe we need to ask on the jack-devel mailing list if this statement in the man page is still valid.

[AnthonyCFox]

Hey cool! I just used this to cut my latency from 23.2 to 5.3 ms and with fewer start up xruns than I normally see. That was just a quick "let's see what this can do" test, maybe I can cut it down even more when I have some time to fool with it.

Thanks you guys!

[tbritton]

Heh... I guess this rule would definitely break the 44.1 items, then! They are very odd!

Seems all the others in this list are even, so they would follow the rule you mention. But I added the warning as another note at the top in this version and the wiki version to be clear on that issue.

[Edit: I wasn't getting it at first about the powers of two thing - reading it as "even numbers" - well, I got it now! I've edited the article to emphasize this information, made the "most legal" settings green in this version and bold in the wiki version. -- THANKS EVERYONE!!!]

Terry

Maybe it would be better to add some kind of preface with a warning that JACK prefers a number of frames that is a power of two. From the JACK man page:

-p, --period int
Specify the number of frames between JACK process() calls. This value must be a power of 2, and the
default is 1024. If you need low latency, set -p as low as you can go without seeing xruns. A
larger period size yields higher latency, but makes xruns less likely. The JACK capture latency in
seconds is --period divided by --rate.

I have to admit though that using numbers that are not a power of two seems to work just fine in most cases. Maybe we need to ask on the jack-devel mailing list if this statement in the man page is still valid.

[tbritton]

The Guitarix issue is interesting to note - thanks for adding that to the wiki. I'll edit this article to match.

Terry

I put this into the wiki as well, but thought I'd mention it here: I discovered yesterday that Guitarix doesn't like frames/period values that are not powers of two. If you have periods=2 and are trying a weird value of frames/period (like 48) to get your latency to be an integral number of milliseconds, then about half of Guitarix will throw errors and fail.

This is not too much of a problem, as there are plenty of settings you can choose with periods=3, but it did confuse me for a little while.

[autostatic]

if you start jack with a non-power-of-2 (say 1023), then try change buffer-size on the fly to another non-power-of-2, jack will refuse. you can only change buffer-size on the fly to a power-of-2.
I think this is correct, but I was never able to try it myself.

You can test this with jack_bufsize:

Code: Select all

jackdmp 1.9.8
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2011 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 70
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... hw:PCH|hw:PCH|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
09:48:34.621 JACK connection change.
09:48:34.622 Server configuration saved to "/home/jeremy/.jackdrc".
09:48:34.623 Statistics reset.
09:48:34.629 Client activated.
09:48:34.656 JACK connection graph change.
configuring for 48000Hz, period = 1240 frames (25.8 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
09:48:44.507 Buffer size change (1240).
09:48:44.508 JACK connection graph change.
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
configuring for 48000Hz, period = 1241 frames (25.9 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
09:48:48.461 Buffer size change (1241).
09:48:48.462 JACK connection graph change.
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
09:48:48.499 JACK connection graph change.

As you can see I can set the number of frames to 1240 and 1241 with jack_bufsize which means you can change the buffer size to a non-power-of-2 value on the fly, even or uneven. I've also tested this when starting JACK with a buffer size of 1023.