According to the Muting and Soloing page of the manual, it would seem to be impossible:
Specifically, the line:
Mute will mute the track or bus, so that it will not be heard anywhere (neither on the master nor monitor busses)
Is that true? Is it really impossible to listen to a track or bus while it’s muted?
Coming from a live-audio background with physical consoles, it’s incredibly important to be able to hear what something is doing and fix it BEFORE sending it to the audience! The typical way to do that is to keep it muted, listen to it and fix as needed, and then unmute. Can Ardour not do that?
In this case, I’m the technical setup, operation, and maintenance guy for a combined local and online-remote meeting. The visuals are handled by two instances of OBS (one for the local audience and one for the remote one), and the audio runs through Ardour 6.9.0 as a “custom console” of sorts, so that OBS can just pass it through unchanged. An HDMI-connected TV for the local audience display and speakers, makes the built-in audio available for monitoring. Mics are USB. All of this on a single laptop running Ubuntu Studio 22.04 LTS. (fully updated last night)
Okay, why did the global setting not do that?! I messed with it for way too long, thinking that that had to be it, but it didn’t do anything.
For others reading later, it’s the Control Outs option, and while right-clicking the Mute button DOES work, it only affects that one track. Good thing I only have a “small” rig as live consoles go, to have to do that separately for each one!
There already is a global control for this. Or at least there appears to be: Edit → Preferences → Signal Flow → Default Track / Bus Muting Options
I guess it’s called “Default” because it only affects new things and not existing ones? I was beating my head trying to get my existing ones to change.
For USB mics, yes. I actually have a side project to see if I can use a Raspberry Pi Pico as a (small) DSP for some custom speakers. My current hangup with that is exactly what that article describes: sample rate mismatch with digital inputs. (Originally, I was going to sync my sample rate to an incoming USB stream, but the USB library still needs some work that is beyond me, and that stream stops anyway when the host isn’t playing something. Great way to throw off a control loop! Then I looked at I2S from a Pi 4’s GPIO header, and that’s jittery! And it still stops. And it even changes rate!) But anyway, if you understand signal processing theory and do it RIGHT (ahem!), resampling is completely transparent, even in an environment like that!
I’ve had enough college classes to know that, but I don’t remember enough to actually do it. For this side project, it’s looking really attractive to put a D/A/D conversion in there and forget the whole mess…I notice that the pro world does that too, quite often.
USB also includes a way for the host to dictate its timing to an audio device, instead of the device just doing what it wants. That is directly supposed to solve the “multiple clocks” problem…but it’s of course more complicated than just shoving all the samples you have so far into a USB frame and sending them off.
In both cases, the problem can be solved by full understanding and pride in quality…which the cheap stuff probably doesn’t have either one of.
Depending on where I am at the moment, I’ll have either some Behringer wireless mics with USB-only receivers (they look like flash drives), or XLR mics with a Behringer preamp on USB. Both ways “sound okay to me,” for whatever that’s worth.
The “correct” solution is a multichannel audio interface/dedicated A/D converters with N channels handling N analog microphones. I think you likely know this, and haven’t done this for reasons of budget, convenience and gear on hand.
Yes, and…yes.
By the way, you wouldn’t happen to have an answer for this too, would you?:
That makes sense now, having been through it.
It might still be useful though, to have a button to apply the preferred default to all existing. The typical discovery I think, is to build something, and then see that all of them are “wrong” the same way, and then want a quick way to “fix” them all.
That is not a problem I have seen reported before.
The Linux-audio-user mailing list might have someone who can offer advice: Linux audio user mailing list info and sign up page
The author of zita-a2j is a regular contributor there, he may offer some advice.
You could also try direct jackd connection to that device to see what jackd reports.
I do not typically need to specify device 0 with my USB interface. Does your device have more than one subdevice?
This will quickly go off topic, I would suggest a new topic if you want to discuss in the Ardour forums. Of course not strictly Ardour related, but probably acceptable in the “Getting Stuff Done” category.
Thanks for the pointer! I’ll see what’s happening over there.
Since this is Ubuntu Studio, I figured I’d try the built-in tools first. Maybe they’re set up to “just work”, and I could always use that. But I had some trouble with different hardware configurations not auto-configuring correctly (especially the bottom-connector dock) whereas PulseAudio by itself did just fine. So I leave the “official tools” unused and manage it directly from a script instead. The script starts JACK, removes the automatic connections, makes the ones that I actually want, starts everything else, waits for okay to shut down, and then undoes everything. (I really like that level of automation!)
Maybe PipeWire will fix all that, as a consequence of effectively combining PA and JACK into one thing, but it looks like I’ll have to wait for the next LTS to try it, since I’d rather stick to those.
Or did you mean something else?
I might not need to either. I just copypasta’ed what arecord -L gave me.
I just meant use- the Behringer USB interface as the output device for jackd, rather than connecting it as a secondary device with zita-a2j. Presumably some other device is the primary jackd output if you are using the a2j bridge. But as I said, let us take that discussion to a different thread.
