It would be awesome to have an option to use Ardour without it reserving your sound card in an exclusive manner.
I would be happy to suffer the consequences on latency or whatever the problems might be to have this option. Latency is very rarely an issue for me, but on the other hand when I have Ardour open I often times wish to have audio on in other programs, perhaps in my browser, at times previewing samples from my command line. Many such use cases for me, and it’s frustrating to have to quit Ardour. Jack is well overkill, and not all programs play 100% nicely with jack, or require extra setup.
I have alsa set up with dmix and dsnooper so if I have an option to use those as opposed to my HW device directly, things ought to work for me.
I recognize that I don’t know what technical difficulties there may be implementing this, but I thought I would still suggest it.
That’s what JACK is for. You can get more or less any application on Linux to output via JACK - how complex this is depends on the distribution and the application in question. On any given day while developing Ardour, I have Clementine, Firefox, Chrome, Telegram and Quassel (IRC) all sharing my audio interface via JACK, while Ardour runs.
ALSA does not allow multiple applications to access the hardware in a way that is acceptable for an application like Ardour - dmix and dsnoop are not OK. That said, the way that Ardour uses ALSA depends on the device it is told to use. There are ways to force Ardour to use “unacceptable” ALSA pseudo-devices that in theory would share the hardware. This is almost no less complex than using JACK, but you can force Ardour to use such a device with the environment variable “ARDOUR_ALSA_DEVICE”. We do not support this, so you are on your own using it. If you specify this, then Ardour’s own ALSA backend will only list this device as the one to use.
For me it’s not about complexity so much, I don’t mind mucking about with settings etc and trial and error until I get things working. For me it’s about avoiding having extra programs on if I don’t need them. Even then, it’s not so much about the principle, I use Ardour on many different computers of various types, and it’s not always feasible to have jack set up on each one. Having this option for Ardour makes it just that much handier for occasional casual use. (Sunvox manages to do this for example)
But once again, I don’t know if it’s really hard to implement in which case I’m sure it’s not worth it. I would be happy if you considered it though, if it’s not. I know I’m not alone in this, if that makes any sort of difference.
JACK’s main purpose is sharing the soundcard and inter-application routing in a pro-audio context. Sounds like you actually do want (and need) jackd.
You may be able to find other solutions and/or workarounds, but they will have more overhead and/or won’t be as reliable as jack and are probably even more complicated to setup. Actually I don’t see how you could achieve your goal without extra programs. You’ll have to run some ALSA dmix or dnoop or similar adapter processes.
If you check my original post, I mention that I indeed actually have dmix and dsnoop already set up.
Don’t get me wrong, I love JACK and I used it for a long time. Now I’ve just been looking to make my setup more minimal, and so far ALSA alone has been doing the job well. And also the problem of having 3 different computers with various requirements, some have pulse because of other requirements (I do a lot of stuff on my various computers, some work related etc, where programs might have some assholish requirements), so it would be neat to have Ardour “play together” with these various pseudo devices and other systems.
In any case, it likely won’t help @speak since pulseaudio doesn’t have MIDI support.
I suppose it might be handy for auditioning some mixes (playback only, where latency and alignment does not matter). It may also be the most painless way to get a bluetooth output for on the road editing.