For years now I am using Mixbus and Ardour with Jack. Pure bliss. It works like a charm.
The reason I am considering to use Alsa directly with Ardour is due to the fact that Ardour demands you use the pesky jack-alsa midi bridge in order to get midi into Ardour when using Jack.
That kills it for me, since if I switch the alsa2jack midi bridge to enable then I lose all the communication that my myriad of other midi programs have with devices. It is really a pathetic situation. Very few midi software apps are jack-midi supporting, and just forget all the legacy stuff. the alsa-jack bridge just grabs all the devices and shuts all the legacy midi out of using them even if alsa itself doesnt use them. Irresponsible at best. Furthermore there is no alsa config to prevent the bridge from grabbing everything. If you could set it up to only grab certain midi devices it would be workable, but no… the bridge was written in totalitarian mode confiscating all midi.
So I have to rather reluctantly send all my audio directly through alsa in order to free up the midi.
Problem is that Ardour/Alsa just doesnt work here for literally years over several distributions…
Here is a video showing Jack connecting like a charm, but no connection to alsa.
It makes NO DIFFERENCE if I totally disable jack and try to connect to alsa.
The Ardour/alsa implementation seems like junk to me it never works having tried it on about 5 different distros.
Jack always works like a charm/sans midi
You have to stop JACK, which hogs the device, before you can use the soundcard with some other application (like ardour/ALSA). In the video “Failed to open audio device” indicates that it is in-use.
Hi Robin
I DID stop jack completely and Ardour and Mixbus wont connect to ALSA.
I even uninstalled jack and tried on several distros.
To no avail. I can never connect directly to Alsa but immediately connect with jackl.
I currently have the alsa2jack bridge off so my other software can communicate with midi devices, But I now have need for midi in Ardour/mixbus. That is where jack kills me as Ardour/mixbus can only send midi through alsa2jack-midi bridge, which disconnects all my other software from devices.
Is there ANY way to get Ardour to connect to Alsa. as mentioned years went past trying it and several distros later. No success.
Jack works spectacular though and I have extreme low latency (1.5ms) with no xruns, but I need to connect straight to alsa in order to shake the pesky a2jbridge to nowhere.
This is the jack version I currently use.
jack is version (3.1.1+cvs20050801-29.2).
I dont really understand what the page you linked try to say.
Does it say what Jack1 vs Jack2 will do with Ardour.
Will Ardour have midi ports available independent from Jack midi. It seems Jack1 doesnt have midi support, which would be great, but what happens to the Ardour midi ports in this case. Are they just made available like any other non-jack enabled program. So does ardour midi work then like any other non-jack enabled midi software program ?
That would be great
Yes the exact settings jack uses successfully
2 periods worked out best here.
I used to use windows and protools and such and latencies were horrible with all daws I used never mind the crashes and perpetual windows degredation with time.
With Linux Ardour/Mixbus I get 5 times better latency. Cant be happier. So I can use the low latency for live monitoring. Works really great.
It is just this darn midi snafu with Ardour/Mixbus and Jack that is a bad show stopper and the only thing that still stands in the way. The stability of my system and functionality is astounding. Cant be happier. It took a lot of coding and scripts and getting rid of things like systemD to make it work perfect, but I digress.
Only this pesky midi snafu remains and there seems to be no way out.
I would suggest it’s a local condition. ALSA works just fine for me using a UCM204HD at up to 192k.
I wonder if it’s related to the ALSA driver for your device?
I know of some issues with some devices due to ALSA issues, which causes them to work in Jack but not necessarily with ALSA apps.
This may seem counter-intuitive as Jack uses ALSA. However, the issue is with the way that Jack and other apps use ALSA. Typically the issue arises when a device does not work properly when capture or playback are opened individually, but does work when both are opened together. In this case, as Jack opens both capture and playback together when started, Jack works.
There is no version 3.1.1 of jackd, so you are reporting the version of some other software, not the version of jack.
In the video you posted you changed immediately between using the Ardour jack backend and attempting to use the ALSA backend. As Robin (x42) pointed out, you have to stop jackd before you can use the ALSA backend. Since you did not show stopping jackd in the video, and since the version you reported for jack does not make sense, it seems likely that when you think you are stopping jackd, you are not actually stopping jack, but just closing some control application. I do not know what that application would be, the latest version of qjackctl is 0.6.3, that is the most commonly use jack control application. The latest version of jack2 is 1.9.16, the latest version of jack1 is 0.125, so not sure what application has version 3.1.1. Does that cvs number indicate you are using some software which is patched from a 15 year old CVS commit?
I think you will have to make a short video of the software you are calling “jack” so someone can identify it and explain how to really do what you want. You could always try brute force, open a terminal and run “killall jackd” then “killall jackdbus” to make sure there are no jackd instances running, then connect the Ardour ALSA backend.
Some devices only work with 16bit and/or 16bit stereo. Others only with a given sample-rate.
jack silently falls back and can use settings other than the requested one. Ardour/ALSA does not do that.
@retnev could you try to start Ardour from a terminal window like
ZITA_ALSA_PCMI_DEBUG=15 Ardour6
That will print Ardour/ALSA related debug messages in the terminal window, and might help to shed light on the issue. The output of jackd when you start it may also provide some hints.
Sorry Chris you are jumping to conclusions.
Did you read that I also UNINSTALLED jack, and still alsa wont work with Ardour independent from my video ?
Did you read that I tried it with several Distros all of which I also UNINSTALLED jack.
As for your claim there is no such jack, see the apt output here
> $]apt install jack
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> jack is already the newest version (3.1.1+cvs20050801-29.2).
> The following packages were automatically installed and are
> trunc
This problem is way past the trivial killing deamons and the inability to uninstall a program.
You are talking to someome who did linux certification
Thanks len but quite obviously I did that and even better uninstalled jack.
BTW kill -9 or KILLALL is useless if you dont check with
ps -A |grep -i jack
That is correct. Only if jackd was running and using the device, Ardour/ALSA would not be able to open it (both require exclusive access to the device).
Could you run Ardour with debug flags, like I’ve mentioned above? That may shed some light.
PS. which version of Ardour are you using ? The mono-space font hints that it may be an old 5.12 build on a modern system (with incompatible libfontconfg).
If so, try Ardour 6.5 (or Mixbus 6.2.70)
Ardour6 has a couple of fixes for the ALSA backend which may be pertinent here.
Robin.
Here is the debug.
I did not truncate anything so I left all the fontconfig errors.
Let me know if you dont need them (which you shouldn’t) and I will truncate them;
$ ZITA_ALSA_PCMI_DEBUG=15 ardour >ardour.log
------------- Multiple lines of fontconfig errors truncated --------------------------
Fontconfig error: Cannot load default config file
bind txt domain [gtk2_ardour5] to /opt/ardour/share/locale
Cannot xinstall SIGPIPE error handler
Color shuttle bg not found
Cannot connect to server socket err = Connection refused
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Cannot connect to server socket err = Connection refused
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Cannot connect to server socket err = Connection refused
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Cannot connect to server socket err = Connection refused
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Found nothing along /home/johhnycrash/.config/ardour5/templates:/opt/ardour/share/templates
run dialog
Cannot connect to server socket err = Connection refused
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Cannot connect to server socket err = Connection refused
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Cannot connect to server socket err = Connection refused
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
ALSA: Cannot open device ‘hw:UMC1820,0’: Device or resource busy
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC2D0 failed: Device or resource busy
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC2D0 failed: Device or resource busy
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC4D0 failed: Device or resource busy
error: /usr/lib/lv2/Freakclip.lv2/Freakclip.ttl:36:4: missing ‘;’ or ‘.’
lilv_world_load_file(): error: Error loading file file:///usr/lib/lv2/Freakclip.lv2/Freakclip.ttl' error: /usr/lib/lv2/Granulator.lv2/Granulator.ttl:24:7: missing ';' or '.' lilv_world_load_file(): error: Error loading file file:///usr/lib/lv2/Granulator.lv2/Granulator.ttl’
Set cursor set to default
Butler drops pool trash
caught signal - shutting down.
Process is still running! trying SIGKILL
OK. now we’re getting somewhere. It seems Ardour’s request to ask pulseadio to release the device fails.
Now you have a few options:
run pasuspender Ardour6 (or your local equivalent to start ardour after pasuspender).
or
run pasuspender sleep 300 then start ardour in the next 5 mins while pulseaudio released the device
or
configure pulseaudio to instead use a different soundcard (using your desktop’s Sound Preferences)
or
… get rid of pulse
Eventually It’d also be great t get to the bottom why Ardour’s request for pulse to release the device fails. But ideally we’d do that with Ardour 6 (which may or may not already fix this).
PS. Kudos for being persistent trying to get to the bottom of the issue.
