A while ago I initiated work on a Linux driver for Line6 devices (now under sound/usb/line6 in the Linux kernel tree). Some of these devices have weird sample rates (39062.5Hz, derived from the 10MHz USB clock divided by 256). The alsa_in and alsa_out jack clients are convenient tools to use such Line6 devices together with more standardized hardware operating at, e.g., 48kHz. However, alsa_in only supports integer sample rates, and even after a couple of minutes, alsa_in doesn't detect the correct resampling factor 1.2288 (48000/39062.5), but still reports the initial approximated value 1.228816 (48000/39062). Admittedly, the error isn't too big, but is larger than the error of high-quality crystal oscillators. And, after all, why use an approximation if we know better?
I modified alsa_in and alsa_out such that they accept a sample rate in floating point format (command line option "-r") and query the fractional sample rate from the ALSA driver to compute the initial estimation of the resampling factor (see attached patch).
What do you think about this patch?
Hello JACK community,
I’m planning my new audio editing setup (both hard- and software) and before investing in hardware, I’d like to ask for advice.
Here’s what I want to do:
– Both computers run Linux.
– On Computer A, I can browse the web and see Youtube videos, I can listen to MP3 files with Totem and I can do DAW stuff with Ardour.
– Computer B does nothing more than getting all the sound output from A and feed it to the speaker through it’s soundcard.
Here’s my theoretical approach:
– Both computers run JACK.
– A runs PulseAudio in top of JACK.
– A runs with the net backend using netJACK2.
– B has the Net Manager loaded which gets the audio from A and pipes it to the soundcard.
– Every time I boot the two computers, they are ready to work. No daemons I have to launch manually, etc. I want the configuration to be done one time for all.
I got my understanding of JACK through the network from here: https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_Net… And this site would also be my guide for setting up the thing.
But I’m not a JACK expert at all. It’s the first time I’m doing something like this. So I want to make shure I got the basics right. And, maybe you now even a better step-by-step tutorial which does exactly what I want.
So, I appreciate any comments on this.
Here's a quick fix for alsa_in and alsa_out, which currently set the
playback latency of their ports to the target delay, but forget to
convert this delay to JACK frames. See PR for more info.
Also convert the result of jack_frames_since_cycle_start() into ALSA
frames, before subtracting it from the delay for the controller.
Note that this change only has effect if ALSA and JACK sample rates
differ, otherwise the behavior stays the same.
I'd like to suggest two new tools. I find myself using them frequently
whenever I'm dealing with sets of outputs / inputs of different
latencies, or sometimes when I'm using software that adds noticeable
(i.e. >= 15ms) latency.
I think it would be best to add them as standard JACK tools because:
- They perform a very basic task.
- JACK has almost no latency-related tools AFAIK.
- They demonstrate the power of JACK's latency API and could serve
as [non-trivial] examples for devs trying to understand it.
What do you think? I've attached a patch with both tools. If they get
included, I'll write documentation about its usage and the latency API
in general. Below is a summary of what they do:
Synchronizes a set of ports for playback or capture, by inserting
appropriate delays to compensate for latency. Example:
Suppose you have one output `playback_1` with 20ms output latency, and
another output `playback_2` with 50ms output latency:
jack_lsync -a2 &
jack_connect lsync:output_1 playback_1
jack_connect lsync:output_2 playback_2
lsync will insert a 30ms delay on the first output, giving you two
outputs of 50ms latency. Instead of connecting to the original outputs,
you'd connect to `lsync:input_1` and `lsync:input_2` respectively.
Corrects the reported latency of a port. Example: to increment the
playback latency of `port` by 30ms:
jack_lset 30ms &
jack_connect lset:output_1 port
Then connect everything to `lset:input_1` instead of `port`.
Clients should ideally set the correct latency at their ports, or
provide an option (as with -I and -O) for users to set them. This is not
the case in practice, and there are also a number of legitimate reasons
why users may want to correct latency externally.
at some point I am getting the following errors from JACK
Jun 9 11:57:19 001-can1-plumber jackd: shm registry full
Jun 9 11:57:19 001-can1-plumber jackd: Cannot create shared memory
segment of size = 422
Jun 9 11:57:19 001-can1-plumber jackd: JackShmMem::new bad alloc
Jun 9 11:57:19 001-can1-plumber jackd: Cannot open client
Jun 9 11:57:19 001-can1-plumber jackd: Cannot create new client
Max locked memory for this process is set to 134217728 while launching JACK
It effectively causes JACK to hang.
I am using 1.9.10 (commit 1ed50c92) on ubuntu 16.04.
The configure flags are --clients=500 --ports-per-application=4 (I am not
reaching 500 clients limit when that occurs, they are around 250).
JACK is started with dummy driver, and --port-max set to 2000.
What is the reason for hitting SHM limit? Can I overcome this in any way?
I am compiling JACK2 from commit 7de15e7a (the same as shipped with Ubuntu
14.04). I need to set --clients to quite high value, and I have found out
that setting --clients=512 causes jackd to segfault while --clients=500 is
Is that a bug or limitation by design?