Unable to select input/output channels

[sesse]

Hi,

I'm using git version c9313505 on Linux (Debian unstable). I'm using a sound card with 18 inputs (Scarlett 18i20 Gen 2), but I only need a few of the channels, so I'd like to remove them. However, when I click the check box next to “channel 3” or any other channel, be it under Audio Input Channels or Audio Output Channels, absolutely nothing happens. I can scroll up and down just fine, and 11-18 are not enabled for whatever reason, but I can't enable or disable anything. I have exactly the same problem with my laptop with its regular two channels; I can't disable or enable them. Is this a bug, or is there some trick I'm missing?

[essej]

Sounds like a bug... are you using the ALSA driver or JACK? Both have issues, but I have plans to redo how JACK is presented because it doesn't make sense. (The cross-platform JUCE toolkit I'm using made some "interesting" decisions when it came to their JACK support, that I will re-work)

[sesse]

I'm using the ALSA driver. AIUI, there's no point in using JACK unless I want to route between programs, right?

[sesse]

I assumed this was an UI issue, but the click is definitely registered, and it builds a new AudioDeviceSetup, and sends it on. But for whatever reason, it's not applied.

[essej]

Checking it out now, I have a 1st gen 18i20..

[essej]

I'm seeing the same thing, obviously this isn't very useful!

[essej]

Try it with JACK and things might become more usable... in the meantime

[sesse]

IIRC, ALSA doesn't have any way of asking for N specific channels, so perhaps the ALSA backend just always hardcodes “use all channels”, ignoring the input setting.

[essej]

The JACK driver does work better, just not in the usual JACK way... you can do the connections manually outside SonoBus, or if you use the checkboxes in the SB audio options it will do connections from system for you, and it acts as expected (allowing up to 2 inputs at once and 2 outputs). I want to fix the JACK support so that the multi-output support works so you can route individual connected people to different places if you want.

You will need to start JACK with qjackctl (or whatever tool you like) first.

[sesse]

But going through JACK will essentially add extra latency, right, since it's just a middle layer to ALSA? Hopefully not a lot, though…

[essej]

It is designed so that it won't... if you use the optional -S (--sync) option to the jackd (assuming it is the jackdmp version) it will not add any extra latency.

[essej]

I'll see what I can do about the ALSA setup too... because all those I/O options that show up are ridiculous and confusing too, aside from the broken channel handling.

[sesse]

OK, thanks. Meanwhile, I guess my suspicion was correct: getDeviceNumChannels() in juce_linux_ALSA.cpp reports minimum 10 channels, so I seemingly can't go below that? And if I try to enable channel 11, it crashes (as in just chooses no sound card), presumably because only 10 and 18 are valid values for the hardware.

[sesse]

TBH my main worry is that I'm getting garbled sound, so I had hoped I could reduce the processing power needed a bit to help :-) This is with a i5-8400 (so should be ample!), realtime priority on SonoBus, governor set to performance. For whatever reason, having a number of samples that divides 48 evenly (with 48 kHz) helps, but I have no idea why; maybe something that kicks off on a 1 ms timer. Larger does not seem to be better.

I'll try JACK and see if it helps.

[sesse]

JACK drew a complete blank. It doesn't seem to recognize my sound card—only its MIDI port. I get some “system” card that does nothing.

[essej]

Using qjackctl to start it? Look for hw:USB in the Interface dropdown in qjackctl. "system" is how whichever device you started jackd with will show up in the connections, since only one device at a time is used.

[sesse]

Yes, started JACK with qjackctl. In “Interface”, I can choose hw:PCH (HDA Intel PCH), hw:PCH,0, or (default). I suppose both are the motherboard's onboard audio header. No mention of the Scarlett.

[essej]

Mine sees it, but I'm actually having problems getting output to it... although input works. Sigh.

[sesse]

Huh, I restarted some things and now it found the card, both inputting and outputting. We'll see if it's stable or not…

[sesse]

Yeah, tested a fair bit, and JACK is rock solid here at 64 sample buffers.

A curious issue is that to one specific user, I will suddenly get 100ms+ upload latency (↑) for no good reason. (He's measuring roughly the same, although obviously in the ↓ direction.) 15 ms or so the other way, and that was what it was before it suddenly started acting up. There should be ~30 Mbit/sec between us, ping is 20 ms, and the lines are pretty much idle…

It's not that easy to find enough users to test with, but the other user I tested with, had no such issues :-)

[sesse]

JACK is running in realtime mode. I'm only using two channels.

I wonder if what's happening is that I have packet loss—not packet delay/jitter, but real packet loss for whatever reason. And the default jitter algorithm reacts to that by increasing the jitter buffer, and never really decreasing it again (because increasing the buffer doesn't reduce the loss). If so, the only real fix would be to add FEC of some sort; I don't know if Opus' FEC code is suitable for music, or if it's low-bitrate voice only. And distinguish between the two cases (late vs. lost) in the jitter estimation code.

[essej]

Yes, keeping an eye on the jitter buffer is always important. Also you can use the Initial Auto mode which just does an auto at the beginning and then goes to effectively manual and the jitter buffer won't change on drops.

[essej]

In my experience true network packet loss doesn't often happen, but instead there is an under-run in the jitter buffer because of too much jitter, and that's when SB reports losses, and if it happens to often in Auto mode will increase the jitter buffer size.

[sesse]

It depends a lot on the exact circumstances of the network. For instance, I've had situations where there are faulty cables or bad transceivers; they are rare, but they do happen. And if there's congestion with no FQ, there will be packet drops. It's a bad situation to be in, but increasing the buffer doesn't help. So it would seem a better metric than lost packets is late-received packets, if you can get that out of AOO.

For video, which has similar issues (jitter, clock drift, long running times), I've gone a radically different way in the past: Record arrival time (and thus jitter) of every packet within a given time frame, look at the 99-percentile, and double or triple that to get jitter buffer. It's not exactly robust control theory, but it seems to work well.