I'm considering using a small machine (such as a thin client or SBC) to make a digital crossover with EQ. My source is a bigger desktop PC, providing sound from several different applications. Both machines would have USB connectors (and preferably be running Linux, if that matters). From my initial searching, it seems that most people would use audio interfaces/converters (e.g. toslink) to make the link; plugged into the USB ports at each machine.
Is there no easy way to stay with native USB for the link, or if not would the conversion to toslink (or similar) and back again make little/no audible difference?
Thanks,
Kev
Is there no easy way to stay with native USB for the link, or if not would the conversion to toslink (or similar) and back again make little/no audible difference?
Thanks,
Kev
This is more or less what you're looking for I think: https://www.diyaudio.com/community/threads/linux-usb-audio-gadget-rpi4-otg.342070/
JLSounds has it all for pizza money.
The owner is very responsive and will configure for you before shipping.
http://www.jlsounds.com/
Jan
The owner is very responsive and will configure for you before shipping.
http://www.jlsounds.com/
Jan
Yes, no reason to convert to toslink.
If you can afford linux DSP latency, most ARM SBCs (and a number of Intel Atom miniPCs) offer USB OTG-capable hardware which can run as a USB gadget in linux. Most SBCs offer I2S output for direct connection to DACs, all devices offer USB outputs for connection to USB DACs.
RPi is a good choice if only 2ch I2S is enough, or if the output can be through USB.
For direct multichannel output, most ARM SBCs feature multichannel I2S output. For running DSP (camilladsp) any linux distribution will do. For running the audio gadget you need an SBC with reasonably new kernel, no outdated android kernel 4.10/5.10.
You will need less linux skills for RPi, considerably more for non-RPi.
If you can afford linux DSP latency, most ARM SBCs (and a number of Intel Atom miniPCs) offer USB OTG-capable hardware which can run as a USB gadget in linux. Most SBCs offer I2S output for direct connection to DACs, all devices offer USB outputs for connection to USB DACs.
RPi is a good choice if only 2ch I2S is enough, or if the output can be through USB.
For direct multichannel output, most ARM SBCs feature multichannel I2S output. For running DSP (camilladsp) any linux distribution will do. For running the audio gadget you need an SBC with reasonably new kernel, no outdated android kernel 4.10/5.10.
You will need less linux skills for RPi, considerably more for non-RPi.
Thank you, that is (yet again) very helpful.
It is a little complicated for someone of my mediocre skills, but looks achievable and is certainly a tempting option. I shall look into it in more detail, to see what limitations there are. There usually seems to be something that I wasn't expecting, such as not handling different sample rates, or recently that weakness with loop-backs running in VMs.
Thanks again,
Kev
It is a little complicated for someone of my mediocre skills, but looks achievable and is certainly a tempting option. I shall look into it in more detail, to see what limitations there are. There usually seems to be something that I wasn't expecting, such as not handling different sample rates, or recently that weakness with loop-backs running in VMs.
Thanks again,
Kev
Thanks, yes I shall certainly be trying direct USB input to a Pi4. If successful, it would ideally then run the sample-rate-switcher you linked to, camilladsp, and finally use USB output to a multi-way DAC.
I don't yet know if I will be able to get this working, but it seems at least possible thanks to the great work that you have put into it. I have read the "Linux USB-Audio Gadget (RPi4 OTG)" thread that fb linked to above, and it is clear that you have donated a great deal of advanced knowledge and time towards making the USB-Audio Gadget much more workable for everyone downstream. Possibly even me.
Similarly for other parts of the chain that I will perhaps be trying to implement; HenrikEnquist, mevang and CharlieLaub have brought things into reach that would be impossible for me otherwise (without resorting to less good alternatives and methods). Such skill, knowledge and generosity from people; thank you.
Well I found my Pi4, but can't locate a couple of accessories so they've been ordered. It looks like the Pi5 is expected soon, but from what I can tell the Pi4 is already sufficient for crossover plus frequency-response equalisation, and is also much more proven for gadget mode (amongst other things). It looks like they've changed the USB setup on the Pi5, for instance. So I'll just use the Pi4 that I already have.
I was going to put Debian12 on it, as the Raspberry Pi OS is a version behind. But they say the Pi OS is more optimised for Pi hardware (and is due for an update to v12 in a matter of weeks) so seems easiest to just use that.
Past Rpi projects have been fun but I've not bothered to make them as user-friendly as wished. So here I intend to use a small UPS or some super-capacitors to allow the power to simply be cut and yet have the Pi safely shut down upon power loss. I'll also take the time to set up a screen and keyboard whilst fiddling about with things, not necessary but I much prefer it (it'll still run headless once in action).
I was going to put Debian12 on it, as the Raspberry Pi OS is a version behind. But they say the Pi OS is more optimised for Pi hardware (and is due for an update to v12 in a matter of weeks) so seems easiest to just use that.
Past Rpi projects have been fun but I've not bothered to make them as user-friendly as wished. So here I intend to use a small UPS or some super-capacitors to allow the power to simply be cut and yet have the Pi safely shut down upon power loss. I'll also take the time to set up a screen and keyboard whilst fiddling about with things, not necessary but I much prefer it (it'll still run headless once in action).
Just as an aside, for extra flexibility I've been looking at adding a toslink or spdif input to the Pi, and find that it is more difficult and/or costly to do well than I had expected. Especially as I want to handle different sample rates etc. So the USB gadget approach is even more valuable than I'd realised.
Obviously there are other ways of streaming, but still a bit more complicated than I particularly want or need. So, if I don't get along with the USB approach for some reason, I'd likely just abandon the separate Pi and put everything on a single source+crossover+dsp machine instead. The Pi could become that machine, but I'm not really a fan of them, so would instead get a celeron laptop or similar.
Obviously there are other ways of streaming, but still a bit more complicated than I particularly want or need. So, if I don't get along with the USB approach for some reason, I'd likely just abandon the separate Pi and put everything on a single source+crossover+dsp machine instead. The Pi could become that machine, but I'm not really a fan of them, so would instead get a celeron laptop or similar.
Normally gadget mode expects to take power from the host, but I don't want to do that (and my host couldn't necessarily supply enough for a Pi anyway). So I need a way to use a second power supply without endangering the host machine or the Pi. It has been suggested (on other forums) that using a supply for the Pi could in some circumstances try to back-power the Host's USB port (e.g. if the host was powered off), and that this could be bad.
An obvious way to avoid that is to connect only ground and signal from the host (below picture as an example). However.. there is criticism of this as if the Pi is powered down the host can supply signals that would then be higher than the Pi's (powered off) positive rail. The theory is that this is bad for the Pi.
So another suggestion i've seen is to connect +ve from the host via a diode so that it cannot be back-powered. The voltage drop across the diode is unimportant because it is only used in the event that the Pi's supply is turned off before the host.
Not sure I want a low power host potentially trying to power the Pi though, if the Pi's power supply gets turned off first, for example. I would prefer to endanger the Pi rather than the host. So I suspect it could be better to (instead or also) use a relay that disconnects the host USB cable if the Pi's power goes down.
But.. I'm not sure how much of this is unjustified internet FUD, or whether there is a better way. Does anyone know?
Thanks
Kev
An obvious way to avoid that is to connect only ground and signal from the host (below picture as an example). However.. there is criticism of this as if the Pi is powered down the host can supply signals that would then be higher than the Pi's (powered off) positive rail. The theory is that this is bad for the Pi.
So another suggestion i've seen is to connect +ve from the host via a diode so that it cannot be back-powered. The voltage drop across the diode is unimportant because it is only used in the event that the Pi's supply is turned off before the host.
Not sure I want a low power host potentially trying to power the Pi though, if the Pi's power supply gets turned off first, for example. I would prefer to endanger the Pi rather than the host. So I suspect it could be better to (instead or also) use a relay that disconnects the host USB cable if the Pi's power goes down.
But.. I'm not sure how much of this is unjustified internet FUD, or whether there is a better way. Does anyone know?
Thanks
Kev
I do not think there is any problem with feeding USB data signals to powered-down RPi. Many USB devices have external PSU and are kept connected to the host when powered down.
It's true that using standard cable the RPi4 is kept powered on through the USB host 5V, with the chances of low-power if more is needed by RPi.
Why not using standard cable with the 5V wire cut and power the RPi through 5V GPIOs directly? What's the advantage of using the USB-C connector for power?
It's true that using standard cable the RPi4 is kept powered on through the USB host 5V, with the chances of low-power if more is needed by RPi.
Why not using standard cable with the 5V wire cut and power the RPi through 5V GPIOs directly? What's the advantage of using the USB-C connector for power?
Thank you (as ever).
It is hard to tell which pieces of information are based on fact and real knowledge, and which on paranoia or misplaced logic. But I too have not found any issue leaving powered-down USB devices connected, so cutting the 5V line seems easier. I might use a small extension to a rear panel-mount USB socket, and omit/cut the wire in that extension; then standard USB leads can be used externally.
Yes, I may well power through the GPIO. I believe it is electrically the same as using the USB-C connector on the Pi4, so just whichever seems most convenient at the time.
Thanks again,
Kev
It is hard to tell which pieces of information are based on fact and real knowledge, and which on paranoia or misplaced logic. But I too have not found any issue leaving powered-down USB devices connected, so cutting the 5V line seems easier. I might use a small extension to a rear panel-mount USB socket, and omit/cut the wire in that extension; then standard USB leads can be used externally.
Yes, I may well power through the GPIO. I believe it is electrically the same as using the USB-C connector on the Pi4, so just whichever seems most convenient at the time.
Thanks again,
Kev
Gosh, well that went much better than anticipated.
I sorted out a separate power supply for the Pi4, and made sure the incoming +ve wire in the USB lead from the host wasn't connected (just connected ground and both USB-2 signals). On the Pi, I then:
This is not at all due to my skill, but rather to the efforts of phofman having made it all work in recent kernels on the Pi. Though I see that yesterday a new version of the Pi OS was released, so it'll be interesting to see if they've broken any of his work. Next steps though will be getting the mini-UPS configured for automatic safe shutdown of the Pi, and then starting to look at setting up CamillaDSP.
I sorted out a separate power supply for the Pi4, and made sure the incoming +ve wire in the USB lead from the host wasn't connected (just connected ground and both USB-2 signals). On the Pi, I then:
- Enabled the DWC2 USB OTG driver: echo "dtoverlay=dwc2" | sudo tee -a /boot/config.txt
- Enabled the DWC2 driver module at boot: echo "dwc2" | sudo tee -a /etc/modules
- Enabled the g_audio module at boot: echo "g_audio" | sudo tee -a /etc/modules
This is not at all due to my skill, but rather to the efforts of phofman having made it all work in recent kernels on the Pi. Though I see that yesterday a new version of the Pi OS was released, so it'll be interesting to see if they've broken any of his work. Next steps though will be getting the mini-UPS configured for automatic safe shutdown of the Pi, and then starting to look at setting up CamillaDSP.
@Kev06 : kudos to your effort. I appreciate your kind words but my work was just a very small part of the overall effort put into the gadget and uac2 support by many developers.
Look at g_audio module params for further refinement, or preferrably at compositefs gadget configuration which offers more options (renaming your device etc.)
Look at g_audio module params for further refinement, or preferrably at compositefs gadget configuration which offers more options (renaming your device etc.)
Using "arecord -D hw:UAC2Gadget --dump-hw-params" shows that my UAC2Gadget is using S16LE (16-bit PCM) which is okay as very few of my music files are above CD quality. But it uses a rate of 64000, which isn't necessarily ideal (partly because my output DAC doesn't support it), so I would need to resample.
I suspect that this is where the above g_audio parameters or composite gadget config may be helpful, but I'm struggling to find anything (down at my level) on even how to change them. It also seems that camilladsp's enable_resampling parameter (present in a number of example configs I found) is not accepted any longer. Though I have still to try scripple's IO plugin.
Could someone posibly give me a few pointers on how to start fiddling with the g_audio parameters?
Thanks!
I suspect that this is where the above g_audio parameters or composite gadget config may be helpful, but I'm struggling to find anything (down at my level) on even how to change them. It also seems that camilladsp's enable_resampling parameter (present in a number of example configs I found) is not accepted any longer. Though I have still to try scripple's IO plugin.
Could someone posibly give me a few pointers on how to start fiddling with the g_audio parameters?
Thanks!
Aha, and of course having given up and asked for help, I then found a helpful little section on hackster.io so will try that.