gdjacobs wrote on 2021-08-03, 21:42:

I've been using Pipewire for a little while now with good results. It simplifies handling of multiple audio devices and can be managed with JACK routing tools, so it would be particularly useful for this project.

Pipewire would be great, if I did not have issues with it, namely intermodulation distortion . See Re: Not so crazy idea : using a Raspberry Pi 4 with jackd , Zita A2J bridge and jack_mixer to make a software S/PDIF mix

I get that distortion if I link a pw-Jack source on ALSA device A a to a pw-jack sink on ALSA device B . ALSA devices A and B are on different audio hardware and thus have clocks that are not in sync . My understanding is that Pipewire is supposed to handle the required the async sample rate conversion dynamically, but either this is not happening or is happening badly. Admittedly, I may be the one doing something wrong here to cause the observed behavior, but I have no idea what that might be . I even tried setting source, sink and Pipewire master sampling rates to different values in order to guarantee/force resampling was actually taking place, but the observed distortion issue remains .

If operating in non-duplex mode (only recording OR playing back), there are no issues with pw-jack, I get the same results as with ordinary jack or zita .

Since everything works fine with jack and zita, I decided to put aside Pipewire for the moment until it, its docs and session manager options mature a bit more and try again at a later date . I didn't feel like reporting this as a bug/issue at this time .

darry wrote on 2021-08-04, 01:17:

If operating in non-duplex mode (only recording OR playing back), there are no issues with pw-jack, I get the same results as with ordinary jack or zita .

This sounds fishy. Worth trying with different host and/or USB sound hardware?

gdjacobs wrote on 2021-08-04, 14:31:

darry wrote on 2021-08-04, 01:17:

If operating in non-duplex mode (only recording OR playing back), there are no issues with pw-jack, I get the same results as with ordinary jack or zita .

This sounds fishy. Worth trying with different host and/or USB sound hardware?

I got the same results on a Pi 4 and on an x86-64 machine, so the host architecture does not seem to be a variable in this. I could eventually try different audio hardware with Pipewire . I had not thought of the latter as a possible variable in the issue because there are no problems when just recording or playing back, but it's definitely worth a shot .

I will post my results once I have tried that .

darry wrote on 2021-08-04, 17:11:

gdjacobs wrote on 2021-08-04, 14:31:

darry wrote on 2021-08-04, 01:17:

If operating in non-duplex mode (only recording OR playing back), there are no issues with pw-jack, I get the same results as with ordinary jack or zita .

This sounds fishy. Worth trying with different host and/or USB sound hardware?

I got the same results on a Pi 4 and on an x86-64 machine, so the host architecture does not seem to be a variable in this. I could eventually try different audio hardware with Pipewire . I had not thought of the latter as a possible variable in the issue because there are no problems when just recording or playing back, but it's definitely worth a shot .

I will post my results once I have tried that .

I might try CM104 + HDA vs Oxygen + HDA on an x86-64 machine to see if it's a USB specific issue with Pipewire. To be clear, I have primarily been using Pipewire to simplify plumbing my HF rig in. Measuring IMD on your sound device is rather pointless when you're already dealing with SSB and electrical utility/lightning QRM at S8 or S9.

gdjacobs wrote on 2021-08-04, 18:28:

darry wrote on 2021-08-04, 17:11:

gdjacobs wrote on 2021-08-04, 14:31:

This sounds fishy. Worth trying with different host and/or USB sound hardware?

I got the same results on a Pi 4 and on an x86-64 machine, so the host architecture does not seem to be a variable in this. I could eventually try different audio hardware with Pipewire . I had not thought of the latter as a possible variable in the issue because there are no problems when just recording or playing back, but it's definitely worth a shot .

I will post my results once I have tried that .

I might try CM104 + HDA vs Oxygen + HDA on an x86-64 machine to see if it's a USB specific issue with Pipewire. To be clear, I have primarily been using Pipewire to simplify plumbing my HF rig in. Measuring IMD on your sound device is rather pointless when you're already dealing with SSB and electrical utility/lightning QRM at S8 or S9.

Thank you in advance if you do get the chance to try it on your end .

Just putting together a method for this. Using Audacity/Nyquist, I get an unloaded THD of about 1% compared to a 20hz generated tone. This is going through an HDA output and CM104 input. Not sure how valid this is, though.

Maybe the best option is to crib off each other so we're comparing the same measurements. Do you have a recommended setup?

gdjacobs wrote on 2021-08-06, 05:33:

Just putting together a method for this. Using Audacity/Nyquist, I get an unloaded THD of about 1% compared to a 20hz generated tone. This is going through an HDA output and CM104 input. Not sure how valid this is, though.

Maybe the best option is to crib off each other so we're comparing the same measurements. Do you have a recommended setup?

I normally use Rightmark audio Analyzer (RMAA) https://audio.rightmark.org/index_new.shtml (even bought a license to encourage/thank the authors, but the free version is sufficient for this kind of testing) and either

a) use a Windows PC with two USB card with SPDIF input and output to feed the Linux host with the linked audio interfaces and monitor/analyze it's output in real time using the said RMAA application
b) Playback a previously generated (by RMAA app) set of test tones into the Linux host with the linked audio interfaces, record the output and then run the resulting file through the RMAA for analysis

Essentially I am "abusing" the RMAA app's sound card loopback test functionality to test an external device (the Linux host with an audio input and an audio output) .

The test tones can be generated for each needed sampling rate/word size combination using the RMAA application (including the free version).
I have included a FLAC compressed 44.1KHz 16-bit test file and a 48.1KHz 16-bit one from RIAA 6.4.5 (in case you don't have access to a suitably equipped Windows machine).

Since the Pipewire issue I see manifests itself even with input and output being at the same frequency (I have tried both 44.1KHz and 48KHz), but on different hardware devices, I believe those parameters should be a good starting point .

I have a few days off coming up soon and should be able to put together a fresh test setup and provide you with the details of how it is setup and fresh comparisons between jack/zita and Pipewire .

EDIT : TBH, I probably don't really know what I'm doing and I am not certain what exactly "Intermodulation + noise, %" actually means/measures, so feel free to use the virtual clue-by-four on me to educate me if I am doing or expecting something dumb .

In IMD, component audio tones of your signal heterodyne in the audio device producing unrelated audio tones that really stand out from the input. You really need more than one input sinusoidal tone to generate IMD interference.

gdjacobs wrote on 2021-08-08, 00:00:

In IMD, component audio tones of your signal heterodyne in the audio device producing unrelated audio tones that really stand out from the input. You really need more than one input sinusoidal tone to generate IMD interference.

Thank you . What you said fits in with my very basic understanding of IMD (I have been doing some reading). I have also read that poor quality resampling algorithms most often showed their shortcomings in the form of IMD .

Here is a direct comparison between reference, Zita+Jack and Pipewire on the same hardware (whatever it was I was testing with at the time) .

Reference (direct analysis of generated test tone) :

Zita + Jack loopback :

Pipewire loopback (Jack API) :

Full results :

I just got on of these for a really good price : https://www.presonus.com/products/firestudio-project and a PCI Express firewire card .

This should/might allow me to

a) add analogue input to my setup
b) no longer need an external mixer
c) get rid of my USB 2.0 S/PDIF output device as I can use the S/PDIF out on the Firestudio Project
d) have all analogue input clocks in sync with output clock (no resampling, async or otherwise, for analogue sources)
e) experience all that firewire under Linux (with either ALSA's native DICE driver or FFADO) has to offer (the glutton for punishment in me has just awakened 😀 )
EDIT : f) eventually run some loopback tests with Pipewire without using any USB devices

First, I will be running some sanity tests under Windows on my laptop to make sure that the hardware is in proper working order . I knew that 10$-ish Expresscard firewire card from Deal Extreme I bought 10-ish years ago would come in handy some day . So far, playback through headphone jack works fine .

darry wrote on 2021-02-19, 22:00:

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 int […]
Show full quote

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 .

May I ask you which USB-C 3.0 hub with PD are you using? And what is your Pi 4 version? You can see it with:

1cat /proc/cpuinfo

)
The raspberry has a USB-C flaw regarding power https://hackaday.com/2019/07/16/exploring-the … issue-in-depth/. Mine is from the version which has the problem and I'd like to power the Pi 4 with a USB-C hub with PD to use the Broadcom SOC integrated USB 2.0 controller.

tmedicci wrote on 2021-10-16, 16:38:

May I ask you which USB-C 3.0 hub with PD are you using? And what is your Pi 4 version? You can see it with: […]
Show full quote

darry wrote on 2021-02-19, 22:00:

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 int […]
Show full quote

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 .

May I ask you which USB-C 3.0 hub with PD are you using? And what is your Pi 4 version? You can see it with:

Copy code to clipboard

1cat /proc/cpuinfo

)
The raspberry has a USB-C flaw regarding power https://hackaday.com/2019/07/16/exploring-the … issue-in-depth/. Mine is from the version which has the problem and I'd like to power the Pi 4 with a USB-C hub with PD to use the Broadcom SOC integrated USB 2.0 controller.

I can't run any tests on my Pi 4B currently as that setup is in pieces currently . However, I can confirm, from my notes, that it is a rev 1.2 which, AFAIK has the USB PD issue fixed .

The list of parts I was using with my Pi 4B at the time :

PSU : RAVPower RP-PC144
USB 3.1 hub with USB PD : Ankmax P531H
USB 2.0 multi-TT hub : Plugable USB2-HUB-AG7
USB-C cable between Pi 4 and USB 3.1 hub : Ugreen cable rated for 5V/3A, 9V/3A,12V/3A, 15V/3A, Max. 20V/3A(60W)

Source : https://github.com/raspberrypi/linux/issues/3 … mment-783720873