Finding hardware inputs

Installation & Configuration Linux
#20

@peder,

I’m not sure what you’re saying. As I mentioned above I am doing:

ARDOUR_ALSA_EXT="hw:1;hw:2"

There is no Focusrite connected to speakers, the only issue I have left is playing the result, through my normal computer output (which I have selected with the Audio/MIDI window.) It seems like using the shell variable to add the other interfaces somehow “disables” what I’ve selected with the GUI. This is why I have to specify both hw:1 and hw:2 with the shell variable rather than selecting one of them with the GUI.

At least that’s what’s happening as far as I can tell. But it’s certainly possible that I’m confused somehow.

Note that a session that does play back has the same setup in the GUI as a session that doesn’t.

#21

OK, so you are in fact using three sound cards: the built-in HDA Intel PCH as “system” and the two Focusrites as “externs”?
When you import the tracks into a new session and they play fine; are you also using the variable to get access to your Focusrites?

It could be that the variable only really works for one extra card. In that case you have to connect your speakers to one of your Focusrites and set one in the Audio/MIDI Setup and the other one in the variable.

If it does indeed work with two extras you should be able to connect the Master bus to the “system” (aka your Intel PCH card) and get audio.

#22

I have to admit it never occurred to me that you might intentionally use the PCH for output when you have two Focusrite interfaces sitting on the desk. I think with that additional information then your inclusion of both hw:1 and hw:2 in the environment variable is the correct approach.

The rest of what I wrote previously still applies, you need to go into the audio connections window and verify that the master bus is connected to the correct system outputs. Usually 1 and 2, but sometimes it could be wired in surprising ways, like 1 and 2 is headphone output, and 3 and 4 are the standard outputs, or reversed. If routing audio to 1 and 2 does not give you the output you expect you may have to try others (assuming that there are additional output channels listed).

2 Likes
#23

Sorry about the confusion. Maybe I should have written more about my … workflow? There are no Focusrites on my desk. They’re in another part of the house connected to the instruments and microphones. I take a laptop in there when we record stuff. I don’t do any playback, editing, or anything else in there. There isn’t even room to sit down.

According to what everybody says, I should be selecting the first device in the startup menu and then the 2nd one with the shell variable. But that simply doesn’t appear to work for me.

This is what I see when I start Ardour normally and select the Solo as input:

Screenshot at 2023-12-16 15-40-26

I see exactly the same thing when I start it with ARDOUR_ALSA_EXT=hw:2 also selecting the Solo in the startup screen.

But when I do: ARDOUR_ALSA_EXT=“hw:1;hw:2” and then select either the Solo or None I see:

Screenshot at 2023-12-16 15-48-25

So it appeared to me that I needed to specify both devices with the EXT variable. But it seems that, according to what everybody is saying, that’s not the right way to do it.

Now, as I was just trying this once again, I noticed something new. When I select the Solo with the startup screen and the 2i2 with the EXT variable, I actually get this error message:

ardour-request-device: Failed to acquire device: ‘Audio2’
Device or resource busy

I didn’t notice this before because it only shows up in the terminal window that I started Ardour from. It doesn’t appear in the Ardour Log window, which was what I was keeping an eye on.

Regarding the outputs … Yes, I did finally get that fixed. I was not “understanding” exactly what needed to be connected the first time I tried it. Once everything is hooked up properly it does play back just fine. I do get a flashing “no align” light, which I assume is because I’m not able to select the devices in the proper way.

So (maybe) my only problem is to figure out why I can’t select one device via the startup and a 2nd one via the EXT variable. I assume that “Failed to acquire audio 2” is related to that.

I’m sorry if I’ve appeared a bit dense. I realize that I’m trying to do “advanced” things with Ardour as a new user. But the only reason I’m attempting to switch to Ardour is so that I can do these things :slight_smile:

#24

Can you post a screenshot with the tabs Hardware selected? Those in your screenshot above are not the physical input and outputs available, but Tracks and Busses: they may or may not correspond to the inputs/outputs available in your session.

I tried starting an empty session with the ALSA_EXT variable, and this is what I see (I have just one USB and the computer internal card):

image

Two inputs from the USB-Card and two from the internal one, same for the outputs.
Maybe you just have to manually connect the channels?

2 Likes
#25

Hi Mike, I’ve been following this topic which, by the way, found very interesting.

This is a short topic about the “no align” blinking led warning. I think is worthwhile reading it and go deeper in case you need.
Have a nice day!

#26

I just wanted to thank everyone who has helped my on this question. Unfortunately I got too busy with work to spend any time on this in the last week or so, and I think I’m probably going to return the two input Focusrite before the return period expires so that I can get the 4 input one.

I guess I’d better try to verify first, with Focusrite, that all four of these inputs really are on one clock, since I see there are two separate monitor outputs and monitor volume knobs. Hopefully it’s not just two individual “devices” in one box.

In any event, I’ve learned a lot from this thread and I now feel motivated to try to build Ardour from source so that, in the future, I’ll have more options to figure what’s going on under the hood.

I really appreciate all the time everyone has taken to help me on this!

3 Likes
#27

That isn’t a problem, Focusrite multichannel devices are used frequently, I don’t think I have ever heard of any problems with them. Seem to be a good choice.

#28

Hi
Im also finding this topic very interesting.
I have got my two interfaces (Lexicon Alpha and Roland UA22) set up and working, with no error messages and no No Align light.
When I test record myself singing into two adjacent microphones, one plugged into each device, they both record nicely,but the there is a small offset between the recorded tracks which causes phasing.
Can you tell me, would this be because of different latencies of the two interfaces?
image
Is that what this message in the terminal indicates:
tart clocking
Setting time domain
locate to 0 took 2411 usecs for 6 tracks = 402 per track
start clocking
locate to 0 took 6425 usecs for 6 tracks = 1071 per track
locate to 0 took 5851 usecs for 6 tracks = 975 per track
locate to 1234800 took 4432 usecs for 6 tracks = 739 per track
locate to 1223775 took 5008 usecs for 6 tracks = 835 per track
locate to 0 took 4969 usecs for 6 tracks = 828 per track
removed /home/mel/Music/Audio/Untitled-2023-12-31-13-50-13/Untitled-2023-12-31-13-50-13.pending
Graph::drop_threads() sema-counts: 0, 0, 1
PluginWindow deleted for 0x564639427ec0
AlsaSeqMidiOut: MIDI OUT THREAD STOPPED
Slave Process: Playback Buffer Underflow, have 50 want 4096
ALSA SLAVE-device latency play=4112 capt=16 changed:1
AlsaSeqMidiIn: MIDI IN THREAD STOPPED
Slave Process: Playback Buffer Underflow, have 50 want 4096
ALSA SLAVE-device latency play=6160 capt=16 changed:1

If so, would it be likely that using two of the same interfaces would reduce/remove this issue?
Many thanks

#29

Hi,
Though I am no good when it comes to numbers, the thing is, if you use two different AD convertors, they will have slightly different clocks so you need to set one as master and the other one as slave, or maybe insert an external master clock ( maybe a little bit « oversized » for your setup).
And maybe, even though, you might have a small offset you will have to adjust, but at least, audio will remain locked instead of moving away when it runs ahead.
Anyway,
Happy New Year to Ardour users.

#30

Probably not.

Cheers,

Keith

#31

Thanks Oliv
I followed @Robin s instructions and you will see that that terminal output above showed that a master and slave had been setup.
I guess using devices without a word clock, it’s probably not going to get much better

#32

Thanks Keith
For interest, I’m going to do the same test with my two interfaces on a friend’s mac, using the built in audio i/o aggregator utility and see if that’s any more in time.
I will post the results here.

#33

That should be better. From what I understand, the audio i/o aggregator on the Mac uses sample rate conversion (src) to create a synchronised output. This uses more CPU, it’s not “sample accurate” (if that matters to you), and it introduces latency.

How much latency? I don’t know, and some research seems to suggest “it depends”, with some saying it works with hardly any noticeable latency to others saying it’s unusable for live use. I suspect it’s down to the individual devices you use.

Cheers,

Keith

#34

Even with a word clock there will be delay between two devices using separate USB interfaces, and potentially not the same delay every time the device is opened for use. The latest linux kernels have improved the handling of USB audio to reduce the startup latency variation, but for a long time the ALSA USB driver had variable latency every time the device was opened.

#35

Thanks for this info Chris
I’m using kernel 6.0.0-10.1-liquorix.
Do you know if that has the improved usb audio handling?

#36

I will try it out Wednesday evening and report the results.

#37

That should have the latest driver improvements. I believe the changes to lower USB latency were in 5.16.

#38

Are you getting xrun notifications in the status bar? I’m not sure what direction the message indicates, whether that means the interface did not provide samples in time, or whether the software did not calculate samples in time to send to the interface.

Although the message right before that:
PluginWindow deleted for 0x564639427ec0
AlsaSeqMidiOut: MIDI OUT THREAD STOPPED

could indicate a graph change because you deleted a synthesizer plugin, in which case a short time of under-run as the processing graph is recalculated isn’t a big deal.

#39

Hi,
I don’t know anything about ALSA , but I think if you can set the master and slave states directly from the control panel of your device ( hardware side), it might be more efficient than putting your system on the way of the hardware.
Just a guess.