The RPi series is known to be problematic wrt heavy USB I/O, although there are workarounds which can help. The Pi 4 might be better.

Probably a better solution is to use an inexpensive DSP chip for summation of multiple I2S sources with programmable gain. Scale the DSP according to the serial inputs required.

gdjacobs wrote on 2020-07-01, 15:59:

The RPi series is known to be problematic wrt heavy USB I/O, although there are workarounds which can help. The Pi 4 might be better.

Probably a better solution is to use an inexpensive DSP chip for summation of multiple I2S sources with programmable gain. Scale the DSP according to the serial inputs required.

I have no doubts that the DSP approach is better, though beyond my essentially non existent skills in the fields of hardware design and programming (with th exception of some shell scripting).

I do, however, have a spare Pi 4 looking for a purpose . Again, if my programming skills were better, running I2S over the GPIO pins (if fast enough) would be something I would consider (ready made S/PDIF to I2S receivers are easy to source).

The Pi4 + USB S/PDIF approach is, unfortunately, the only one within my reach . Thanks for confirming my worries about USB I/O . If I could find some cheap S/PDIF to USB receivers, I would still likely give it a shot. Even if I fail miserably, the learning experience would be worth it .

You can find cheap USB analog audio dongles on eBay. Even if they don't work for your final product, you'd be able to generate the kind of expected I/O load and prove the concept.

You probably could capture additional channels of I2S directly through the GPIO pins instead of via the two I2S channels, but I'm not sure how far you could scale it. The Pi boards have less efficient I/O than many other embedded SoCs.

gdjacobs wrote on 2020-07-01, 19:24:

You can find cheap USB analog audio dongles on eBay. Even if they don't work for your final product, you'd be able to generate the kind of expected I/O load and prove the concept.

You probably could capture additional channels of I2S directly through the GPIO pins instead of via the two I2S channels, but I'm not sure how far you could scale it. The Pi boards have less efficient I/O than many other embedded SoCs.

I was hoping to actually find some USB S/PDIF input dongles first, because if I can't find those at reasonable prices, the concept really is not feasible to begin with . To reduce USB I/O contention, I could use an HDMI S/PDIF audio extractor for output (I think I have spare one lying around) instead of an additional USB output device .

My goal is 3 or 4 inputs . That seems within reach of even USB 1.1, in theory .

darry wrote on 2020-07-02, 17:33:

My goal is 3 or 4 inputs . That seems within reach of even USB 1.1, in theory .

Assuming you're not restricting sampling rate or bit depth, you'll need 196608 /s sample rate * 24 b sample bit depth * 2 channels per I2S port for a grand total of 9437184 b/s per I2S port. Looking at Aliexpress, it seems 15 USD per stereo channel might be doable.

gdjacobs wrote on 2020-07-02, 19:11:

darry wrote on 2020-07-02, 17:33:

My goal is 3 or 4 inputs . That seems within reach of even USB 1.1, in theory .

Assuming you're not restricting sampling rate or bit depth, you'll need 196608 /s sample rate * 24 b sample bit depth * 2 channels per I2S port for a grand total of 9437184 b/s per I2S port. Looking at Aliexpress, it seems 15 USD per stereo channel might be doable.

I wasn't planning on anything beyond 48KHz at 16bit sample depth, but that's a very good point. If I am not mistaken, S/PDIF zero-pads 16bit to 24bit so I probably need to consider 24-bit as a minimum for bandwidth calculation .

I was considering some of these CM6206-LX based USB "sound cards" https://www.amazon.ca/Optimal-Channel-Externa … r/dp/B00Q4WQ7XW .

The CM6206-LX is USB 2.0 "full speed" (basically USB 1.1 "high speed"), so I was thinking of running them through a multi-transaction translator USB 2.0 hub, if I can find one.
See https://www.tomshardware.com/reviews/usb-tech … logy,677-3.html (this is dated, but I imagine it still applies) .

Pretty sure that's what the ones on Aliexpress are using. Likely your best bet, although I haven't messed with SPDIF input to know how solid that is with those parts. I've got one on hand, so it's maybe something to do tonight...

I ordered a multi TT USB 2.0 hub and two of those USB SPDIF sound cards, for starters. For SPDIF output, I have a UCA202 already . I will begin putzing around with the PI when I get the chance.

If all this amounts to nothing useful, I should still find a use for the hub and only be out a few dollars for the USB sound cards .

Well, I tried to advance this project.

Observations :
a) Even with the latest firmware for the Via VL805 USB 3.0/2.0 hub integrated in the Pi 4 (latest firmware fixes an issue with similar symptoms), I cannot connect even 2 full-speed USB audio interfaces to any two ports on the Pi 4 without getting a crap-ton of these in dmesg

1[Thu Feb 18 17:51:15 2021] usb 1-1.4.6: Not enough bandwidth for new device state.
2[Thu Feb 18 17:51:15 2021] usb 1-1.4.6: Not enough bandwidth for altsetting 3
3[Thu Feb 18 17:51:15 2021] usb 1-1.4.6: 1:3: usb_set_interface failed (-28)

b) The symptom in "a" affects cheap CM106 USB devices (I have 3 of those) and Fiio E10K ones (I have 2 of those) in any combination as long as there are 2 or more connected
c) Connecting 2 or more of the those devices through a Plugable branded multi-TT USB (confirmed in lsusb) gives the same results whether connected to one of the Pi 4's USB 2.0 or USB 3.0 ports
d) Symptom "a" is present in the latest 32-bit build of Raspbian and also in the latest 64-bit build of Ubuntu
e) As a test, connecting 3 of the CM106 USB devices through the multi-TT USB hub into a USB 3.0 port on a Gigabyte B450 I AORUS PRO WIFI running Buster shows no issues .

Tentative conclusion so far : the USB subsystem of the Pi 4 does not seem to shine when using "high bandwidth" USB 1.1 devices . Whether this is a software, firmware (VL805) or hardware (VL805), I do not know, but I guess I will try reporting it and hope for the best . I am disappointed, to say the least . On an unrelated note, but also frustrating note, I was unable to get h.264 video acceleration to work satisfactorily on Youtube using Chromium or Firefox (says it's enabled and in-use, but CPU usage is through the roof and video skips/stutters), though it does work fine with the custom build of VLC included with Raspbian (with specific patches not in mainline VLC). I am glad that I am not trying to build a streaming media player .

Plan B :
The Raspberry PI 4 Broadcom SOC has an integrated USB 2.0 host controller that is not enabled by default, but can be set to host mode, and is physically exposed through the Pi's USB-C power input connector . I ordered a USB-C hub which supports USB power delivery and the required PSU and am going to hope that I can
a) get that USB controller to work
b) successfully attach at least one USB audio devices to that host controller, ideally 2 or 3 (using my multi-TT USB hub in between, if necessary/useful)
c) If I can only get a total of 2 USB audio devices working, get an an HDMI audio to S/PDIF de-embedder and try to use that as an output .

Plan C:
Chuck the Raspberry Pi 4 as far as I can throw it and use SFF x86/x64 PC instead .

Thanks for reading my cathartic rant . 😉

In the amateur radio VHF/UHF repeater community, the Pi 4 is known to have issues with multiple C-Media dongles connected via USB. Pi 3 has no such problems beyond previously known raw performance limits.

gdjacobs wrote on 2021-02-19, 08:22:

In the amateur radio VHF/UHF repeater community, the Pi 4 is known to have issues with multiple C-Media dongles connected via USB. Pi 3 has no such problems beyond previously known raw performance limits.

It seems to work!!! I only had time for a quick test so far, butI have 3 CM106 like devices on a multi TT UB 2.0 hub plugged into my new USB-C 3.0 hub with USB PD. The USB-C 3.0 hub with USB PD is powering the Pi 4 over its USB-C connector and is exposing 3 USB ports connected to Broadcom SOC integrated USB 2.0 controller . No more bandwidth errors!!!

On the Via VL805 managed USB 2.0 and USB 3.0 ports, I can't even have a keyboard and mouse plugged it at the same time as Fiio E10K or only 2 Fiio E10Ks or only two CM106s without getting bandwidth errors .

At least on my Raspberry PI 4, there is something very off about USB 1.1 support, even when used through a multi TT hub .

I will run more tests, but if my approach is successful, it could also be a workaround for the VHF/UHF repeater community .

Another day, another "interesting" bug .

First the good news. Using the setup described in my previous post does indeed seem to work fine in terms of USB bandwidth. The ultimate test will come when I actually have 3 incoming streams and one outgoing one simultaneously over USB, but that will be for another day .

The other snippet of good news is that ALSA and jackd seem to work fine with 16-bit word length at both 441.KHz and 48KHz in Raspbian on my Pi 4

However, if I try outputting anything at 24-bit/44.1KHz , I get static with some barely audible music in the background . If I choose any other sample rate (32KHz, 48KHz, 96KHz) at 24 bits, everything works fine . If I force 16-bit mode in jackd , 44.1KHz works fine too . So it is only the 24-bit/44.1KHz combination that does not work properly . I have reproduced this with 2 different USB sound cards (Fiio E10K and Roland UA4FX). My initial testing was with VLC using the jack plugin and with resampling disabled . Format is S24_3LE in all 24-bit modes, if anyone is interested . EDIT : I used audio files with appropriate word length an sample rate for all tests .

I then moved on testing with aplay and was able to reproduce the issue immediately , so it is not a jack issue, but an ALSA related one . Finally, I decided to try the E10K with aplay on a current Debian x64 machine running the same version of ALSA as the Pi 4 and it worked fine on the first try ! EDIT: at 24-bit and 44.1KHz .

Next step is to try it on Ubuntu running on the Pi 4 . If that does not work, I will have to stick to 48KHz at 24 bits for output .

The reason I want 24-bit output is the avoid clipping on the off chance the 3 S/PDIF inputs were to peak at the same time . If my math is correct, 3 16-bit sources at peak, added together, would require a bit less than 18 bits in order to avoid clipping .

If anyone is curious, I plan to get around the fact that the input clocks and the output will not be in sync and not necessarily have the same sample rate by using zita-ajbridge between a jackd output device and ALSA hardware inputs . The plan is then to use a software mixer like jackmix (or something similar) .

EDIT : Same problem in Ubuntu 64-bit on Pi 4 . Using ALSA, S24_3LE at 44.1KHz is broken, but S24_3LE at 96 KHz, for example, works fine . Again, S16_LE works fine at 44.1KHz .

EDIT2 : Corrected typos, I meant S24_3LE not S24_LE

EDIT3 : The USB bandwidth issue and workaround (using the integrated USB 2.0 controller) are described here https://github.com/raspberrypi/linux/issues/3962

IT WORKED!!!

I was able to mix two S/PDIF sources at two different sample rates (44.1KHz and 48KHz) without a common word clock using the resampling functionality in zita-ajbridge and using jackd on my Fiio E10K for output. The sound quality was subjectively transparent to me and there were no glitches or dropouts during preliminary testing (i used music from Doom and and a 1 KHz test tone, first alternatingly and then simultaneously) . I did not even use jackmix, I just connected both my sources to to the output using qjackctl . If this also works for three sources, I may not even bother with jackmix . I did not notice any added latency .

TODO :

- Add a third USB S/PDIF input device to the mix and see if I hit USB bandwidth or CPU limitations (I should have checked CPU load while it was running).
- Reproduce what I do in qjackctl using the CLI . EDIT: Done
- Add jackmix (optionally and if actually useful, might come in handy to control relative volume of sources centrally) EDIT : I tried jack_mixer, and it works fine . It is tempting to get an touchscreen too . EDIT: Touchscreen is on the way as it was way cheaper than a MIDI control surface . EDIT : Touchscreen is installed and working fine as a screen but sucks on the touch aspect. A cordless mouse and USB keypad will do the trick .
- Find a way to do some quality tests (essentially running some subjective tests, testing with udial.wav and possibly running some easy to do tests if someone can suggest some).
- Assuming everything works as expected, document how to do this in greater detail, for my own notes and in case somebody else is interested

Well, it's pretty much finished .
I tested with udial.wav and I can't hear the effect of any "bad" sample rate conversion .
For now, I only tested with 2 actual inputs active at the same time and everything seems to work fine . I will certainly test with 3 once I have integrated this thing into my setup, but to be honest, I don't see practical scenario where I would need to simultaneously mix 3 sources in my use cases . CPU usage is quite reasonable with 2 inputs and 1 output active, adding an additional stream likely won't break anything :

Aesthetically, the Pi 4 looks fine, IMHO, and is easy to control with a mouse and numeric keypad .

As for a howto, I can provide one if there is some interest from anybody, but essentially, it goes like this :
- Assemble required hardware setup (see previous posts)
- Install Raspbian (32-bit, but 64-bit would probably work as well)
- uninstall PulseAudio packages and the LX panel pulse volume control
- Make sure jackd, jack_mixer and the zita a2j bridge are installed
- adapt/rewrite (for your hardware and USB config) and run the really ugly script that I have written (I call it in the pi user's .bashrc and and automatically spawn an xterm using /home/pi/.config/lxpanel/LXDE-pi/panels/panel /etc/xdg/lxsession/LXDE-pi/autostart, which starts it at boot ) . I worked around some timing issues at startup with some sleeps and a few validations and it seems to work reliably for me so far . The device renaming is optional and probably better done through a udev script anyway

- Content of my jm_conf (jack_mixer config file)

There are probably better ways to do this, but this seems to work for me so far .

EDIT : 2021-03-08 Updated script yet again to be a bit more robust and to have some optional debugging stats/info (and to correct some of my idiotic mistakes) . Also posted my jack_mixer configuration file . There are some Jack Xruns during initiization/startup , but none during actual use once initialization is finished . This is probably due, in part at least,to the fact that most or sometimes all of the S/PDIF inputs are not receiving any signal (no S/PDIF cables connected) during initialization (starting the script while the system is still busy starting up does not help, in all likelyhood). Once the system is up and running, it handles S/PDIF inputs becoming active or inactive (plugging/unplugging S/PDIF cable) dynamically without apparent issue . There is no way to change input frequencies of each input device dynamically (they are set as variables at the beginning of the script), but that is not really an issue for me as I won't be changing those often . Someone who does might want to set those variables as a command line arguments instead . I also added timestamps to events in logs facilitate tracking of potential issues when debugging . Oh, and everything is logged to /tmp to conserve flash write cycles . I used to run with a MicroSD card, but switched to an M.2 SATA SSD in a USB enclosure as I aim for long-term durability and reliability .

EDIT : 2021-03-30 Added latency optimized script and also modified it for Douk U2 output instead of Fiio E10K .

For anybody curious about the capabilities of the cheap CM6206 based devices used for S/PDIF input in this project, I ran some tests using RMAA under Windows 10 .

First test is using a Roland UA4FX looped into a CM6206 based USB device using S/PDIF at 44.1KHz
Second test is using a CM6206 looped into itself at 48KHz .

At least under Windows, all the CM6206 drivers that I have found only allow 48KHz output through S/PDIF . The default Windows 10 class-compliant USB audio drivers do not enable S/PDIF out on the CM6206, but do allow S/PDIF in . S/PDIF input is possible at either 44.1KHz or 48KHz under both Linux and Windows . I have not tested S/PDIF output under Linux .

Next, I will probably try to test audio loopback through the actual S/PDIF mixer chain .

EDIT : ASIO by way of ASIO4ALL was used for all tests . I did run some tests using MME, but ASIO gave better results . I would guess that using MME incurs some processing/resampling in Windows 10 that ASIO4ALL's use of Kernel Steaming avoids .

I've been busy this weekend .

I've acquired a new in box Cakewalk SPS-25 (looks like a rebranded Roland UA-25 with a slightly different USB device ID) in order to more easily run more tests. Official drivers for this require a a Cakewalk account and Cakewalk is no longer letting people create one . I found a copy of the latest Windows 8.1 x64 driver, but Windows 10 x64 refuses to install it without modifying the inf , but then the signature no longer matches and you need to disable driver signing and it installs but chokes on the next reboot...

Anyway, long story short, forcing the installation of the Roland UA-25 Vista x64 driver in Windows 10 x64 works fine (the Windows 8 one does not) , so problem solved on that front .

I have also ordered an XMOS XU208 based USB interface ( https://www.amazon.ca/Douk-Audio-Converter-In … z/dp/B085XPRSGM )to replace the E10K . Having both optical and coaxial S/PDIF output, it makes my life easier and also brings the BOM down by 40$, assuming t works (it has not arrived yet) .
EDIT: The device arrived, but is likely defective. It is only detected, and intermittently at that, when connected through a powered USB hub . This holds through true for connection to my Dell M4800 laptop's USB ports or those of my Raspberry Pi 4 . Additionally, even when detected, there is a DFU (device firmware update ?) device detected in addition to the audio device itself and neither of those devices matches the device ID of the provided driver . So, back it goes . Since I believe I got a defective one, I have another one on order .

In the meantime, I have run some tests. First, some analogue loopback tests, unrelated to the S/PDIF mixer, because why not .
EDIT : Added some analogue loopback of Fiio E10K into my new MOTU M2
EDIT : Added an analogue loopback test (unbalanced out to balanced in) of the MOTU M2 . That is impressive .

And now, what you've all been waiting for, the S/PDIF mixer loopback tests :

a) All tests were run using ASIO4ALL with the following equipment chain : SPS-25 ---> S/PDIF mixer ---> UA4FX
b) The first test was run while sending a 44.1KHz signal into the mixer and receiving it back converted to 48KHz (sample rate conversion is handled by Zita A2J bridge)
c) The second test was run while sending a 48KHz signal into the mixer and receiving it back as 48KHz
d) The round time trip loopback latency test was run while sending 44.1KHz into the mixer and receiving 48KHz, to try to simulate worst case scenario .
e) The parameters have been tweaked a bit to lower latency compared to the posted script, I will update that soon to reflect that (essentially lowering -p 256 to -p 64)
f) Not illustrated, but plugging the SPS-25 directly into the UA4FX gives about 23ms or latency using default ASIO4ALL buffer sizes (EDIT : with both input and input output operating at 48KHz, in this case), so with current settings the S/PDIF mixer has about 30ms worth of latency .
g) More optimization/tweaking of mixer latency is likely possible, but 30ms worth of latency is probably good enough .

EDIT : Corrected reference
EDIT2 : Quick note, the CM6206 based cards that are used as input devices will choke on SCMS tagged S/PDIF streams . This is a hardware "feature" of these devices . This is not an issue for my use case (old sound cards and synths which have no reason to set any copy protection bits), but may be a concern to people with different use cases . Short of using an SCMS stripper (which would be illegal in at least some jurisdictions), the only workaround to this would be to try to find USB (or maybe I2s) interfaces that do not care about SCMS (may not be legal to own/use either). If the S/PDIF stream to be mixed is obtained through the use of an HDMI to S/PDIF de-embedder, I have no idea about what SMCS bits will be set by the de-embedder (nor do I know if embedding an SCMS protected S/PDIF stream into an HDMI signal works with most embedders ) . As always, if in doubt, please seek legal counsel .

Another little update .
- I received a working Douk U2 which took the place of the E10K as an output device . As this is a USB 2.0 high speed device, I connected it directly to one of the Pi 4's VL805 managed USB 2.0 ports with no issues .
- A bonus of using the the XU208 based Douk U2 is the fact that it supports S32_LE sample format which apparently work fines at 44.1KHz on the Pi 4 (S24_3LE does not)
- I switched to 64-bit Raspbian (technically beta) in the hope of better performance and, with identical settings, Qjackctl indicates slightly lower DSP load, AFAICT (and recall)
- I also patched and compiled a real-time kernel (5.4 based), thanks to info found here http://robskelly.com/2020/10/14/raspberry-pi- … and-preempt_rt/ .
- I disabled apt-daily-upgrade.timer (once this works, no need for updates or even an Ethernet connection, not to mention the CPU load during the updates can generate x-runs)
- I applied the tweaks mentioned here https://madskjeldgaard.dk/posts/raspi4-notes/ … ning-the-system (for some reason the CPU governor switches back to on-demand at every reboot, so I switch it back to performance in the S/PDIF script) .
- I decided to overclock the Raspberry Pi 4 to 2.0 GHz . I have heatsinks + active cooling, and temps went up by approximately 3 degrees
- I lowered jackd period size to 32 and set priority to 90 (had to use chrt -f 90 as just passing -P 90 as a parameter to jackd did not seem to work)
- I re-tested latency and ran several multiple hour-long playback sessions with 2 input sources and insure no x-runs during use (x-runs only happen for about 10 seconds if script is started at boot, which I consider a non issue).

Now, some latency results -->

a) 44.1KHz loopback to test baseline latency of measurement tools :

b )44.1KHz loopback using setup in a), but running through S/PDIF mixer which outputs 44.1KHz

c) 44.1KHz loopback using setup in a), but running through S/PDIF mixer which outputs 48KHz (Zita-A2J doing SRC)

If we substract RTT duration a) from that in b) , we get 11.976 milliseconds pass-through latency for the S/PDIF mixer . It may be possible, though not necessarily reliable, to lower jack period length even lower and get 10 milliseconds and/or tweak the Zita-A2J period size (CM6206 absolute minimum is 45 and current value is 64), but I think that we are close to what a PI 4 can hope to achieve (at least with my current audio hardware that I am using and my current skillset).

Todo :
- Keep disabling unnecessary services
- Add a fourth CM6206 device and re-test/teak
- Try to find cheap replacement for CM6206 based units with lower hardware latency (good luck). Latency is unchanged if I bypass Jack-mixer and loop input to output using jack, so most of the currently measured latency seems to to due to the input device device used .

EDIT :

If anyone's curious, this is what a period of 8 for output and 45 for input (minimum if 44.1KHz) and 48 (minimum if 48KHz) produces in terms of RTT :

It does seem to run without x-runs, at least during summary tests . I would hazard to guess that this is about as low as the hardware goes, or about 7.5 milliseconds of RTT latency, in other words . My guess is that it would be unstable in the long run . EDIT : Yup, it is unstable . I get intermittently high intermodulation distortion numbers even without x-runs . My guess is silent (as in unreported or /dev/nulled) Zita-A2J issues .

EDIT :
As mentioned here Re: Bought this (Modern) hardware today , the CM6206 based units that I own have atrocious built quality and what seems to be significant hardware latency, so I am trying some old-ish ADS Tech Instant Music devices instead . These look better build use a TI/Burr Brown USB controller/DAC/USB/SPDIF input/SPDIF output chip . I hope they will work at least as well as the CM6206 based units .

EDIT : I tried using the Cakewalk SPS-25 as an input device under instead of a CM106 . The RTT latency was almost the same at about above 11 millisecond (or maybe a millisecond or so less than a CM106, unless I made some measurement mistake (it's almost 4AM where I am), so nothing to write home about). If semi-pro gear does not give me better latency than that (and that was the device's "advanced mode" activated), I doubt the ADS Tech stuff will be any better on that front . Oh well .

EDIT : I am thinking of trying PipeWire as a unified solution . This is all both fun and educational !

I tried using Pipewire 0.3.24 bundled with Ubuntu Budgie 64-bit 21.04 beta and a self-compiled build of Pipewire 0.3.24 on the latest build on Raspbian 64-bit (wit 5.4 RT patched kernel).

In both case, I can get it to "work" (though for some reason ALSA devices are not available by default under Pipewire's Jack emulation on Ubuntu, which I don't really mind as I prefer defining custom sources and a sink manually in the pipewire.conf file).

However, in both cases, I get intermodulation distortion that is around 4% (you can even see things jump around in the RMAA review window graph of a test tone) . I did not run any actual listening tests yet . Is this is just the Pipewire resamplers reacting badly to RMAA test tones ?

I did try set ting resamplers to max quality and a master refresh rate that matched the in and out (44.1KHz) and then one that did not, but nothing changed . I am nothing getting any errors or x-runs .

Next test will likely be to run a test tone fine manually through a Pipewire sink and see if distortion is still present. After that, I could try recording a test tone file through a Pipewire source to again test for distortion .

If I am still motivated after that, I might open a bug report with the Pipewire folks . TBH, maybe I am doing something obviously wrong. I wish the docs were more complete/detailed, because this this is complicated under the hood, IMHO . In comparison jackd and ZIta are trivially easy to understand and setup and work really well, IMHO .

EDIT: Specified which Ubuntu flavor .

I ran a Pipewire vs JACK/ZITA comparison . The results are interesting, IMHO.

Referring only to quality/transparency :

- All sink and source devices in Pipewire were set to 44.1KHz as was Pipewire's master sample rate
- Resampler quality was set to 9 in Pipewire
- No errors or x-runs observed during tests
- Using a CM106 to record with, I get essentially the same results through Pipewire-jack , ZITA or JACK
- Using a U2 to playback with, I get essentially the same results through Pipewire-jack or JACK
- loopback with a CM106 and the U2 using Jack and ZITA works fine
- loopback with a CM106 and the U2 using Pipewire gives strangely high intermodulation results and frequency response anomalies. These are not always consistent from run to run, but intermodulation distortion is always quite high .

EDIT : I am getting better results when I loop through a CM106/U2 combo than I am getting with straight recording using a CM106 . This is strange to me . Mixer settings are the same in both test scenarios .

EDIT2 : Either the Pipewire results point to
a) a bug
b) a misconfiguration
c) the possibility that I am doing/expecting something fundamentally wrong/impossible and do not realize it .
d) that my sanity has reached the end of its road
e) some or all of the above 😉

EDIT3 : I tried using Wireplumber instead of the session manager bundled with Pipewire, and I got the same results . I am going to give up on Pipewire (for now). I have just received a few of my InstantMusic devices and will get started on testing them . The next step will likely be to get everything working with Jack/Zita and a 5.11 RT patched kernel on Debian Budgie . Fun times ahead .

EDIT4: I tend to use CM106 and CM6206 interchangeably as Linux sees as them CM106, but they are supposed to be CM6206 variants . I did not actually bother checking the chip markings .