If your version of ubuntu is at least 18.04 (but 20.04 is better), you can install studio-controls from the repo… for the most up to date version: https://launchpad.net/~ubuntustudio-ppa/+archive/ubuntu/backports
With studio-controls running, plugging in a USB device should get it to just show up in jack. You will want to plug them all in, in the same order every time or boot with them plugged in I think to keep their order the same as they are all the same name.
do I have to plug them in with controls open? I have booted with them plugged in and am not seeing them
No, but you would want to make sure jack was started with studio controls. (not qjackctl or some other program)
don’t see them where? In Ardour? are you using the jack backend? Use something like Carla’s patch tab to see if they are there. Also make sure the studio-controls “Bridge USB Devices When plugged In” check box in “extra devices” tab is selected (should be by default).
In studio controls. will have a poke later
studio controls does not really show devices or connections for hotplug USB but they should show up in the jack graph… maybe try jack_lsp in a terminal. If I run jack_lsp here I get:
system:capture_1
system:capture_2
system:playback_1
system:playback_2
Device,0,0-out:playback_1
Device,0,0-in:capture_1
Device,0,0-out:playback_2
Device_1,0,0-out:playback_1
Device_1,0,0-in:capture_1
Device_1,0,0-out:playback_2
(and some other entries, but these at least you should see) I only have two of these extra USB devices plugged in, you should see a Device_2 set as well.
$ jack_lsp
system:capture_1
system:capture_2
system:playback_1
system:playback_2
system:playback_3
system:playback_4
system:playback_5
system:playback_6
system:playback_7
system:playback_8
pulse_in:front-left
pulse_in:front-right
pulse_out:front-left
pulse_out:front-right
Device,0,0-out:playback_1
Device,0,0-in:capture_1
Device,0,0-out:playback_2
Audio,0,0-out:playback_1
Audio,0,0-out:playback_2
Audio,1,0-out:playback_1
Audio,1,0-out:playback_2
Device_1,0,0-out:playback_1
Device_1,0,0-in:capture_1
Device_1,0,0-out:playback_2
Device_2,0,0-out:playback_1
Device_2,0,0-in:capture_1
Device_2,0,0-out:playback_2
C920C,0,0-in:capture_1
C920C,0,0-in:capture_2
a2j:Midi Through [14] (capture): Midi Through Port-0
a2j:Midi Through [14] (playback): Midi Through Port-0
looks like 
And I just tested in Ardour and it works! Guys, thank you all very much. This is by a fair margin the best piece of support I have ever gotten for a FOSS product!
I’ma gonna plug my Youtube channel now 
www alsa.project.org and look for a compatible multitrack card that will take care of your needs. I found the M-Audio Delta 1010 worked great with Ardour and Harris Mixbus. I’ve move on to Audiosciences pro audio cards which may be too costly for your needs. You can also use some of the Digigram audio cards and I found the Digigram MixArt 8 works well on my basic production machine. I’m using Linux Mint 19.3 with a Quad intel 2.8 with 4 gb of ram 250 GB SSD system drive and 500 GB SSD for audio production. Now I also have calf plugins that I use with Ardour as well. I’m not recommending any setup and just stating what I use and follow those that you have been in touch with. I wish you all the luck.
My whole point is to avoid analog mixing. BTW what do you guys mean by clock? I have no clue about audio TBH. Also I am having issues with digital artifacts in the recordings “robotic voice”. Could that be related?
Thanks!
OK, from simple to more complex:
sound made by people causing the air to vibrate starts out as an analog signal (initially as an acoustic pressure wave). Microphones transduce (think “transform”) this analog signal into a different analog signal (a time-varying electrical voltage). Ergo, if you work with microphones, you are working with analog signals.
if you want to use multiple microphones, you want to use an audio interface with multiple microphine inputs. Each analog signal will be converted to digital by its own converter (i.e. the signals will not be mixed together). The digital data stream will be delivered to the CPU, where it can be captured and recorded (e.g. to disk) or processed (e.g. live FX)
Analog to digital conversion happens by measuring the electrical voltage level periodically. The points at which the measurement takes place are driven by a “sample clock” which is basically an oscillating crystal/circuit which ticks extremely fast. Every 1/48000th of a second (if working at 48kHz), the clock generate a signal that causes the analog->digital converter to measure the current voltage.
The first rule of digital audio is that your system (recording, playback) should have only a single sample clock in it. No two clocks will ever run precisely in sync with each other.
“robotic voice” has nothing to do with sample clocks or mics. It’s typically a software problem, either in an application or in the device driver for the audio interface.
Focussing on “robotic voice” here: I am having this problem with Ardour, both using ASIO under Windows and using Jack under Linux. It strikes me as a potential Ardour problem therefore.
Anyway, my problem is the robotic voice which I would like to troubleshoot. What do ye need?
Can’t really comment on the robotic voice issue.
I went for basic because you said “I have no clue about audio, TBH”.
fair enough and thanks! What is the impact of the out of phase thing and how severe? I have several people talking (clip on mics). I know what reverse polarised speakers sound like, but how bad is it for speaking? And I am glad they can be converted. Can Ardour do that?
It’s a very small effect by comparisons with most things. Typical clock drifting is on the order of maybe a second over several hours. That’s enough that a 10 minute continuous recording will feature what is effectively comb filtering between the mics if they use different clocks.
The thing is: nobody who knows anything about this stuff will ever do this. It’s started to become more of an issue with more and more manufacturers selling the ease/cost of USB mics, and they are preying mostly on the ignorant (as ever, sadly).
OK, cool, thanks. I’ll burn that bridge when I cross it.
Me being one of them Well, for my purposes (youtube) this should actually do fine, The question is whether we can nail that robotoc voice issue. I am thinking what I could do is to record with 1 then 2 then 3 mics and see how much difference that makes.
So how do we get somebody on this who knows?
It isn’t a matter of someone who knows, because it is 99% something particular in your setup. Sadly in your case my first thought would be the wireless, and glancing at the reviews on amazon there are several that mention noise and poor quality audio. Given that these are USB wireless, they do the digital audio conversion internally, there isn’t to much other choice if you are recording the digital voice (As opposed to only hearing it on playback) but to be certain you should try recording with other interfaces and see if it continues.
If it is the wireless there are three things it could be:
Given I can’t even determine if these are analog transmission devices or digital transmission, I would lean towards a combination of 2 and 3. The fix is likely the same though in any case, replace the unit. So again first step is to record using a different interface, and make sure that works fine (My money is on it will). If it does, then you are pointing towards your choices of audio hardware being the issue and the fix is likely to use other audio hardware in your case. Sorry.
SeabladeHmm, it does sound like digital artifacts though. It also seems to corellate to the amount of USB devices connected, but I will verify this.
It also happens randomly, not consistently.
It happens on 2 completely different boxes under 2 different OSs and audio driver architectures. Let me generate some test samples and see what I can get.
This could be an issue of overloading your USB bus then, unplug everything except what you need and see if it continues. Is this USB1.1(I hope not) USB2 or USB3+?
But there will be consistent things that will cause it, even if it happens intermittently. Removing possible triggers one by one is part of troubleshooting.
Again this points to a problem with your hardware. But again another way to confirm this is to replace the hardware, record with something else and see if it happens. Extra points to record with a class compliant interface and confirm if it does or doesn’t happen as that will use literally the same driver.
SeabladeHmm, what I have available is those wireless mics and my webcam. Only Linux available at the mo. I’ll run a few tests.