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.
Oh lordy … so it is the poetterNIX effect again.?
Pulseaudio is the last PoetterNIX software I allow to run as all my problems the last 5 years were systenD/PoetterNIX, I mean everything.
As I understand, Pulseaudio … nice as it is is, is also a PoetterNIX creation.
But as all such things treats the rest of Linux with absolute disregard.
Replaces SYSVinit with horrible results for sysadmins trying to run SYSV scripts on the systemd INIT system. Completely drops @reboot support in CRON, with bad bad results. Most of the time you are not even aware that SYSVinit was not started but systemDinit instead. You install a small gnome app and low and behold without you noticing it also replases SYSV with SystemDInit and you usually dont notice. I now have cronjobs on all the servers I manage just looking out for PoetterNIX software installing without consent.
My systems stabilised nicely since I run NO systemD or PoetterNIX.
No I can only thank you, for asking pointed questions.
I can see where the fish rots now.
It seems that jack manages to wrestle Alsa out of the coils of Pulseaudio, but knowing the PoetterNIX software behavior I would not blame Ardour a bit !
The solution at this stage is to UNINSTALL Pulseaudio.
Pulseaudio is rather nice, but since it is PoetterNIX it has to go as it will bite, as it has.
Unless Ardour6 didnt fix this;
Is it possible that you can wrestle a bit harder in subsequent Ardour implementations to get Interface out of Pulse’s coils ?. You have my sympathy… This is technically not Ardour’s fault, but from my experience the PoetterNIX family of software is in general flux, break things/norms/customs and then just turns around and do something else in the next release.
I am pretty sure I am one of the few that uses Pulse with Alsa/Ardour. Alsa/Jack/Ardour
So, I uninstalled Pulseaudio and now it works.
Better to continue this discussion once I install the latest Ardour.
But this has been giving me headaches for years.
I really appreciate it that you solved it and technically not even Ardour’s problem.
Thanks a lot Robin. You’re the ACE.
