That is such good news. What(low cost) hardware would this development be
used on to support the developers with testing/debugging and maybe even
* MOTU LP32 (Preferred)
* MiniDSP https://www.minidsp.com/products/network-audio/avb-dg (I think
MOTU's switch uses midDSP switch hardware)
I hope someday it will be possible to connect 4 or more 8 channel ADAT
modules (32 channels) to a PC under Ubuntu via AVB with low latency. The
only option to get this done under Windows is a Focursrite DANTE based
Rednet 3 right now because Thunderbolt is not really available there as
well. Plan to get Rednet3, but that does not solve the Linux environment
which I prefer. Would love to be able to use the Rednet 3 under Linux but
since DANTE is proprietary , so unlikely.
My two wishes:
[a] Multi (16+) channel low latency audio I/O using ADAT audio AD/DA
[b[ Bitwig supporting LV2 plugins.
With those two, the Linux Audio environment would be perfect and the world
a better place.
*(Apology for the re-sends and ignore the previous edits. Web based Gmail
is such a annoyance and un-logically structured)*
capturing from ALSA capture devices via the Jack2 sound server (1.9.12),
results in too high pitched wav files (they are playing "too fast" and
sound like the "chipmunks"). If I run the same capture directly from the
ALSA devices (without Jack involved), everything sounds as expected
without any problems.
Capture via jackrec: https://filebin.ca/3pyMxBw8cexQ/test-jackrec.wav
Capture via arecord: https://filebin.ca/3pyOPjcKGym5/test-arecord.wav
The device in question is a "virtual" Axia-ALSA (Livewire+) audio device
on CentOS 7 which operates at a sample rate of 48kHz and a bit depth of
either 16 or 32. As far as I can see, the sample rate and format
detection on the Jack side looks correct. I'm therefore looking for some
guidance on how to further debug this, I most certainly missed something
I've also tried to play an mp3 file via mpg123 over jack (without the
involvement of the Alsa device) and record it again with jackrec. This
works and sounds correct.
Here is what I've tried and what the environment looks like:
# Capabilities of the Axia-ALSA device
arecord -D hw:0 --dump-hw-params
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:0":
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE S32_LE
SAMPLE_BITS: [16 32]
FRAME_BITS: [16 256]
CHANNELS: [1 8]
PERIOD_TIME: (41 1365334)
PERIOD_SIZE: [2 65536]
PERIOD_BYTES: [64 131072]
PERIODS: [1 1024]
BUFFER_TIME: (41 1365334)
BUFFER_SIZE: [2 65536]
BUFFER_BYTES: [64 131072]
arecord: set_params:1299: Sample format non available
# Capture via arecord directly from the ALSA device (without jackd)
# This works as expected and the WAV file sounds fine
arecord -D hw:0 -c 2 -d 10 -r 48000 -f S32_LE -v /tmp/test-arecord.wav
Recording WAVE '/tmp/test-arecord.wav' : Signed 32 bit Little Endian,
Rate 48000 Hz, Stereo
Hardware PCM card 0 'Axia' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 32
buffer_size : 16384
period_size : 4096
period_time : 85333
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 4096
period_event : 0
start_threshold : 1
stop_threshold : 16384
silence_size : 0
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
# playing arecord wav (via my local notebook's HDA Intel PCH
# device), sounds correct
Playing WAVE 'test-arecord.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
# Starting jackd
# Verbose output at: https://pastebin.com/YzHEGSnR
jackd -d alsa -d hw:0
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
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
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 20
self-connect-mode is "Don't restrict self connect requests"
Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|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
# Capture via jackrec
# This results in a too high pitched WAV file
# Verbose output at: https://pastebin.com/PCnymKLA
jackrec -f /tmp/test-jackrec.wav -d 10 -b 32 system:capture_1
# playing jackrec wav (via my local notebook's HDA Intel PCH
# device), sounds incorrect
Playing WAVE 'test-jackrec.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
Distribution: CentOS 7.4.1708
ALSA Utils: 1.1.3
The jackd was rebuilt from Fedora source RPM to be able to test with the
Many thanks and best regards
Sorry, posted with wrong sender ...
Am Mittwoch, 31. Januar 2018 17:25 CET, "Ralf Mattes" <r.mattes(a)mh-freiburg.de> schrieb:
> Am Mittwoch, 31. Januar 2018 17:07 CET, Robert Bielik <Robert.Bielik(a)dirac.com> schrieb:
> > [...]
> > jackd 578 pi 3u REG 0,16 12 11510 /dev/shm/jack_sem.1000_default_system (deleted)
> > jackd 578 pi 4u CHR 116,0 0t0 11412 /dev/snd/controlC0
> > jackd 578 pi 5u unix 0xb78a4380 0t0 8031 /dev/shm/jack_default_1000_0 type=STREAM
> > jackd 578 pi 6u CHR 116,16 0t0 11413 /dev/snd/pcmC0D0p
> > jackd 578 pi 7u CHR 116,24 0t0 11414 /dev/snd/pcmC0D0c
> > jackd 578 pi 8u unix 0xb78a7b80 0t0 8033 type=STREAM> jackd 578 pi 9u REG 0,16 12 8034 /dev/shm/jack_sem.1000_default_freewheel (deleted)
> > jackd 578 pi 10u unix 0xb78a7800 0t0 11511 /dev/shm/jack_default_1000_0 type=STREAM
> > /home/pi/start_jack
> > Interesting to see the DEL for file descriptor.
> Well, that means that "someone" removed those files from the filesystem. Since the jackd process still
> hase the file descriptors open the files are still there, but since the have no name anymore they are
> inaccessible ...
> Now you only have to find out _who_ did it ;-.)
> Cheers, RalfD
On Wed, January 31, 2018 9:03 am, Robert Bielik wrote:
> Ok ð although this is jack2 built *without* dbus and running on a
> headless RPi3.
How does the rc.local start jackd under the user account? Maybe it could
start a screen session at that point, and when you ssh in you can connect
to the screen session. If you are not familiar with screen it is an
application that (among other features) will let you disconnect an ssh
session while the underlying terminal session continues to run (usually
breaking the ssh session will kill the terminal session associated with
that login). When you connect again with ssh you start screen with the -r
argument to restore connection to the already running screen session
rather than starting a new session.
On Wed, January 31, 2018 9:30 am, Robert Bielik wrote:
> As shown here (I wrote that msg in the forum):
"You have been notified about this topic, please login to view it."
I don't really feel like going through the effort of creating a new
account on some web site I've never heard of to fix your problem. If you
would like help on this mailing list then I recommend you send relevant
information to this mailing list.
> The files in /dev/shm aren't supposed to vanish during
> lifetime of jackd process, right ?
I found this in common/JackShmMem.cpp:
jack_log("JackShmMem::delete size = %ld index = %ld", size, info.index);
So it seems like at least some shared memory operations get logged.
Maybe try -v for verbose logging.
New to JACK wrt actual usage, I'm having a project which I want to setup as follows:
1. JACK in (hw:0,0) -> "JACK mixer"
(This one should be as low a latency as possible, preferably 48 frames @48 Khz, i.e. 1ms buffer size)
2. Any-app-using-ALSA -> ALSA JACK plugin -> JACK "mixer"
3. JACK "mixer" -> JACK DSP plugin -> JACK out (hw:0,0)
This will, in this particular case, run on a RPi3. Design goals are: One low latency route between input and output on a I2S sound card (1. above) and the rest of the applications using ALSA should share a higher latency route. The output of the JACK "mixer" should pass a JACK plugin before reaching hw:0,0.
Before I get my hands too dirty I'd just like to ask if this architecture is feasible to do ?
Am Mittwoch, 31. Januar 2018 16:03 CET, Robert Bielik <Robert.Bielik(a)dirac.com> schrieb:
> > >> Socket is associated with the desktop session?
> > >
> > > Ah, seems like a very reasonable explanation. Although I'm not nearly
> > > linux-savvy enough to "fix" this, so I'd appreciate pointers ��
> > I'm just regurgitating buzzwords connected to "dbus". Maybe they help
> > trigger the memory of someone who actually has a clue.
> Ok �� although this is jack2 built *without* dbus and running on a headless RPi3.
Yes, D-Bus is only one part of Linux session handling. Both systemd (most likely your init system) and PAM
will do some magic. To find out where your jack client expexts jackd's socket run:
$ strace -e connect,open jack_lsp -c > /dev/null
> Yes, I managed to get it working with that guide, however now I have
> intermittent problems when rebooting, I think it is due to the LD cache,
> sometimes .so files in /usr/local/lib are not found.
In these cases, when it doesn't work I get:
Could not open driver directory /usr/lib/arm-linux-gnueabihf/jack: No such file or directory
Could not find any drivers in driver directory!
Failed to create server object
So I do:
sudo ldconfig /usr/local/lib/
and voila, it works again. As you probably can tell, Linux is not my forte...
when looking at jack_evmon output, it tells numeric port ids when a new
port is registered, unregistered or connected.
I wondered if there is an API method to get the same number from a
jack_port_t or port name string.
On Mon, January 15, 2018 10:13 am, Benny Alexandar wrote:
> I want both PC and USB sound card ports to be accessed at the same time.
The design of jackd (really any sound server) requires it to be
synchronized to the sampling clock of the interface, and since your two
interfaces are not synchronized to each other then jackd cannot use both
at the same time without some intervention.
Using two at the same time requires choosing one card to the be the main
backend device, then loading a sample rate converter to make the sample
stream rate to and from the secondary card(s) match exactly that of the
The packages you want are zita-alsa2jack and zita-jack2alsa, in Fedora
both come together in a package named zita-ajbridge.
This is covered in the jack FAQ, which needs to be updated, the section
describing alsa_in and alsa_out bridges is the relevant section, but those
older implementations had some problems, the zita bridges are higher
The zita tools are included in the audio aware distributions, if you are
using a distribution which does not package them for some reason you can
get them along with the other zita applications here:
The jackd v1 implementation includes the equivalent of the zita bridges
internally, they need to be enabled from the command line but not loaded
as an external component. The jackd v2 implementation (I think you said
you were using jackd 1.9.12, that is considered jackd v2) does not yet
include the zita bridges as part of the server, you will need to load them