Using Ardour without "hijacking" the sound card

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.

Any thoughts?

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.

You can simply ask Ardour to dis/re-connect in the Audio/MIDI Setup dialog. There’s no need to quit.

Beautiful!! You guys rock! :smiley: I can’t wait to try this out.

That is mainly for overriding device detection. I’d be surprised if it works with non hardware devices.

While you’re at it, set the environment variable ZITA_ALSA_PCMI_DEBUG=15 that’ll print verbose messages about the ALSA backend interacting with libasound.

Ah yeah, this is actually what I’ve done if I really need to switch it often. Thanks for the tip, nonetheless!

Alright thanks, I’ll try this out. :slight_smile:

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. :smiley:

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. :smiley:

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.

ZITA_ALSA_PCMI_DEBUG=15 ARDOUR_ALSA_DEVICE=pcm.asymed ardour6

Find a trout and repeatedly slap the nearest C++ who throws exceptions without catching them.
Ardour will likely crash now, giving you time to get the trout.

(ardour-6.0.pre0.2088:8292): glibmm-ERROR **: 11:48:17.146:
unhandled exception (type std::exception) in signal handler:
what: std::exception

Trace/breakpoint trap (core dumped)

Hah, well at least the error message is funny. :stuck_out_tongue:

Welp, it was worth a try!

This exception is from the Audio/MIDI setup dialog, when the available buffersize list is empty, and/or the default buffersize is not a number.

Is there an earlier error message in the terminal output? A line that begins with ALSA: perhaps something like

ALSA: Cannot open device 'pcm.asymed': ... 
ALSA: Cannot get minimum buffer size: ... 

Can you try again with today’s git: 6.0-pre0-2092-g771f2d2499 or later?

Make sure that the amixer slave configuration includes period_time 0 period_size 1024 rate 48000 settings (or similar values). Also use ARDOUR_ALSA_DEVICE=asymed - you need to specify the device name.

Thanks I will try asap! Back on my desktop in a day or two, will get back to you. Thanks for the help!

I see Robin was finally beaten down by the constant stream of requests to use a system sound server instead of jackd:

commit 384c97e12db22c102cc4723aa7bcda13f3ec8d0d
Author: Robin Gareus robin@gareus.org
Date: Thu Jul 25 16:39:23 2019 +0200
Puls der Zeit
Prototype a basic stereo-playback only pulseaudio backend.

“beaten down”? no, more like “went insane” :slight_smile:

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.

1 Like

Just tested it. Works fine with asymed device and correct parameters on slaves. Thanks for the work, Robin!

Hey can you present your whole command for the launch so that we can learn from you? Thanks :slight_smile:

Sure. Please note that I’m solving a different problem with help of ARDOUR_ALSA_DEVICE Different ALSA input and output devices

Command is ARDOUR_ALSA_DEVICE=asymed ardour6

ALSA configuration. I set S16_LE because my record card only support that one

    pcm.dmixed {
      ipc_key 1025
      type dmix
      slave {
        pcm "hw:0,0"
        period_time 0
        period_size 1024
        rate 48000
        format S16_LE
      }
    }
    pcm.dsnooped {
      ipc_key 1027
      type dsnoop
      slave {
        pcm "hw:1,0"
        period_time 0
        period_size 1024
        rate 48000
        format S16_LE
      }
    }
    pcm.asymed {
      type asym
      playback.pcm "dmixed"
      capture.pcm "dsnooped"
    }
1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.