Hi,
I'm trying to use Jack with an Odroid-U3. I re-installed a Debian Wheezy
image which had Jack installed and was working fine with a Focusrite
Scarlett 2i4 sound card.
I did an "apt-get update && apt-get upgrade" and then I installed
libasound2-dev and libjack-dev because I wanted to compile Pure Data from
source, and these packages are necessary.
After compiling Pure Data I realized that Jack had been uninstalled (no
idea why), so I installed it again, along with Qjackctl, via apt-get.
Now when I try to run Jack through Qjackctl, with the same sound card, Jack
starts but after half a second it stops. Here are the messages I get:
20:34:15.291 Patchbay deactivated.
20:34:15.293 Statistics reset.
20:34:15.424 ALSA connection change.
connect(2) call to /tmp/jack-1000/default/jack_0 failed (err=Connection
refused)
attempt to connect to server failed
20:34:15.443 ALSA connection graph change.
20:34:37.680 JACK is starting...
20:34:37.681 /usr/bin/jackd -dalsa -r48000 -p1024 -n2 -Xraw -D -Chw:USB
-Phw:USB -i2 -o4
connect(2) call to /tmp/jack-1000/default/jack_0 failed (err=Connection
refused)
attempt to connect to server failed
jackd 0.124.1
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn
and others.
jackd 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
20:34:37.696 JACK was started with PID=21882.
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:USB|hw:USB|1024|2|48000|2|
4|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
20:34:39.919 JACK connection change.
20:34:39.920 Server configuration saved to "/home/odroid/.jackdrc".
20:34:39.922 Statistics reset.
20:34:39.971 Client activated.
20:34:39.977 Buffer size change (1024).
20:34:40.493 Shutdown notification.
20:34:40.495 Client deactivated.
20:34:40.497 JACK is being forced...
cannot read server event (Success)
cannot continue execution of the processing graph (Bad file descriptor)
graph error - calling shutdown handler
cannot send request type 7 to server
cannot read result for request type 7 from server (Broken pipe)
cannot send request type 7 to server
cannot read result for request type 7 from server (Broken pipe)
20:34:40.594 JACK has crashed.
20:34:40.704 JACK was stopped
Can anyone shed some light on this one?
Thanks
Hi all!,
Has anyone seen this and hopefully found a workaround?
To make a long story short, it takes a Motu card of the new generation
(24ao, 1248, etc) about 6 seconds to change the sampling rate (!). That
happens when switching from one sampling rate to another, and also after
first connecting the card to a Linux system over USB (Fedora 23).
When Jack is started for the first time after changing sampling rate, or
right after the card is plugged into the system, it probably asks the
ALSA driver "can this card do this sampling rate with these other
parameters?" and the answer is "yes", but when actually setting it it
apparently fails and jack does not start.
Now, if after that you slowly count to 7 (just to be safe) and try to
start Jack again, it just works (I presume the card has already finished
switching sampling rates in the background while you wait, and
everything is fine).
When using aplay to help debug this it turns out that aplay does not
complain, and it happily plays the soundfile, but nothing comes out of
the speakers for the first few seconds - I presume until the card
switches sampling rate.
Once the sampling rate has been defined at least _once_ then Jack has no
problem to start (over and over again) and aplay plays files with sound
from the beginning.
If you access the status and configuration web server in the Motu you
can switch the sampling rate and you see the clock lock icon turn
blinking red and then solid white once the change is done. Also,
alsamixer and amixer show a single read only "control" that is actually
the lock status indicator (the lsusb descriptors also show another r/w
control that can be used to _set_ the frequency but that is somehow not
reflected in the alsamixer/amixer interface).
Suggestions? Patches? :-)
-- Fernando
Hi,
I am using JACK to connect an A/D interface to Processing (through the
Beads library), and JACK, when running, has recently stopped recognizing
the inputs from my interface, even though I setup to recognize the
interface before the server starts. This is on a MacBook Pro, El Capitan,
and I fear that the error was caused by a recent security update
(2016-001). (I have considered upgrading the OS to Sierra but am now
nervous to do so.) Is this probably the cause, and might there be any
work-arounds?
Thank you for any help!
- Emily M.
