Hi, I'd like to use Jack on a minimal Arch Linux install without X /
Wayland but I faced the problem that my USB MIDI controller doesn't show up
in the jack_lsp output. I tried to install jack and qjackctl on a Fedora
25 install and while under qjackctl everything works fine, the USB MIDI
controller is listed in the ALSA tab and I can connect it to any other Jack
client, it still doesn't show up under jack_lsp. I try to avoid a2jmidid
for keeping things simple, and because I read that it's not necessary under
Jack1 anymore, wich is the version I want to work with anyway. Is this
problem known to anyone or is it something peculiar to my setup?
Thanks, fweth
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.
Hi Guys,
I have 2 PCs, both with a 64 channel madi card. Machine 'A' is
runing Win7, and the RME TotalMix is running showing what is on each
channel. I am also running Reaper, which has a plugin generating
tone on the 1st 8 channels which is visible on the TotalMix.
Machine 'B' is a dual boot Win7/Ubuntu 16.04, and when booted into
Win7, the tone coming in on the madi stream channels 1-8 is clearly
present and audable. When I boot into Ubuntu, I run QjackCtl and
start Jack. I then start a simple program I have written from a
tutorial I found that copies from the inputs to the outputs.
Unfortunately, nothing is received on the inputs. On the outputs
however if I fill the output Buffer with random numbers, the resulting
noise appears on machine 'A', so not everything is a total disaster.
I have checked alsamixer for muting on the inputs and am now at a loss
for possible causes. (I am summing the abs value of each frame in
input and periodically printf the total, which is always zero.
Could someone more knowledgeable that myself suggest causes for the
lack of input.
Zappa Fan. (mostly to make searching digests easier, but also true).
On Thu, Sep 15, 2016 at 12:27 AM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
>
> JACK has been a long, strange and wondrous journey, and even if at this
> point I lean towards thinking that the whole idea was a bit of a mistake (!
> :),
>
Definitely not. I guess you were thinking about some sub parts of jack when
you wrote this.
Firstly, jack provided a simple to use API to send and receive audio with
low latency to and from the soundcard.
Secondly, it made it possible for several programs to access the
soundcard simultaneously,
so you didn't have to start and stop programs all the time.
There's a new release JACK1 now available.
http://jackaudio.org/downloads/jack-audio-connection-kit-0.125.0.tar.
gz
(tagged in git as 0.125.0)
Changes since 0.124.1, in rough order of significance:
* in the alsa_midi slave driver, fix hotpug device enumeration. JACK1
will now respond
to MIDI devices being connected and disconnected while running.
* increase maximum size of a single JACK MIDI event to 64 bytes
* in the alsa_midi slave driver, fix thread start/stop handling when
freewheeling
* add support for jack_port_rename()
* fix incorrect ALSA backend latency values when used with other than 2
periods/buffer.
* drop support for CPU cycle counting clock, use kernel clocksource
instead
* fix a double-fork that left zombie processes around
* improve the validity and usability of the return value of
jack_frame_time()
* fix failing metadata look up by clearing UUID parsing buffer before use
* support unescaped double quotes in $HOME/.jackdrc
* fix memory leaks of metata key/value pairs
* fix crash caused by incorrect jack_error() format string
* remove option help from jackd and point user at documentation
* fix problems with garbage keys in metadata
* fix negative x-run values on Linux with ALSA backend and kernel 4.0 or
later
* build and run on openBSD with new sndio backend
* fix out-of-tree builds
* update configure.ac to work with current-ish autotools with less errors
* fix building on MacOS 10.12 (Sierra) where clock_nanosleep() is not
available
* enable use with Travis (continuous integration for OS X on github)
* correctly avoid Valgrind warning in one instance.
* use gcc atomics and CLOCK_REALTIME for generic CPU builds
* a handful of other minor bug fixes
Contributors: Hans-Peter Portner, Fons Adriaensen, Erik de Castro Lopo,
Filipe Coehlo, David Robillard, Adrian Knoth, Dominic Sacré, Peter Nelson,
Rui Nuno Capela, Robin Gareus, Peter Nelson, Paul Davis, Miroslav Urbanek,
Uladox, Josh de Kock, Jeremy Hu, Bernhard Wiedemann.
With this release of JACK1, I (Paul Davis) am stepping down from my
position as Benevolent Dictator for the project, and in all likelihood from
any active involvement with the continuing development of JACK1. Filipe
Coehlo (falktx to many of us) will be taking over my role as JACK1
maintainer, and I believe that this leaves the project in excellent hands.
JACK has been a long, strange and wondrous journey, and even if at this
point I lean towards thinking that the whole idea was a bit of a mistake (!
:), I want to thank all the amazing developers and users who contributed
their time, intelligence, insights and interest to the project, and hope
that it will continue forwards in the best possible way.
