I am thinking about creating a tutorial for a wireless DSP-capable DAC based on a Pi (3/4/5) and a HiFiBerry HAT. I wanted to get some feedback to see how much interest there would be in this kind of project/tutorial.
The idea is to be able to have a DAC that is fully DSP capable but is not directly connected to another computer. Audio is sent from a computer running Linux or WSL2 under Windows 11 over the LAN (wired or wireless) to the Pi, where any DSP is carried out and then the audio is rendered via the HiFiBerry HAT. Audio is streamed as uncompressed PCM in a fixed rate and format of the user's choosing.
I am currently working up this concept with a DAC8x HAT and I wanted to see how much interest there would be in a tutorial. Other audio HATs for the Pi by HiFiBerry can be used, or even USB audio interfaces, etc. using the same approach and only small modifications to the setup. The audio quality is primarily determined by the DAC itself, and the user is able to change that at will.
The idea is to be able to have a DAC that is fully DSP capable but is not directly connected to another computer. Audio is sent from a computer running Linux or WSL2 under Windows 11 over the LAN (wired or wireless) to the Pi, where any DSP is carried out and then the audio is rendered via the HiFiBerry HAT. Audio is streamed as uncompressed PCM in a fixed rate and format of the user's choosing.
I am currently working up this concept with a DAC8x HAT and I wanted to see how much interest there would be in a tutorial. Other audio HATs for the Pi by HiFiBerry can be used, or even USB audio interfaces, etc. using the same approach and only small modifications to the setup. The audio quality is primarily determined by the DAC itself, and the user is able to change that at will.
Here is a bit more about this concept...
The motivation is to make it possible to "cut the cord" between some audio source and the DAC. Maybe because the playback system is not near where your main computer sits, etc. Instead of a cord like a USB cable that carried the audio data to your DAC, we use your existing LAN to send the data to your DAC using GSASysCon.
The idea is to put on your WiFi network some small hardware/computer like a SBC or any old thing that will run Linux. An audio "sink" e.g. DAC or audio interface is attached to it and GSASysCon is used to stream audio over the LAN to this computer. GSASysCon does everything needed at the endpoint so that audio is produced, DSP is done, etc. while the user controls it from the source side.
GSASysCon must be run from within a bash shell, and this typically means Linux OSes only. However, the bash shell is available in the Windows 11 "Windows Subsystem for Linux". You only need one extra step to get audio from the Windows side to WSL2. I do not like PulseAudio for this purpose, so instead I used the following scheme:
I did something like this a few years ago, and described it a bit here:
The main difference was that I was trying to send the audio back to the Windows side and then out to locally connected USB DAC. That's actually more complicated than sending the audio over your LAN to another computer!
This idea has come about (or come up again) as I think about my current project, which is Pi-5 with a HiFiBerry Dac8x HAT running as a USB-gadget audio device. That plugs directly into your computer, and the result is a locally-connected DSP-capable 8-channel DAC. It's like a DIY version of a miniDSP FLEX HT or HTx with the only input being via USB. The next step is to "cut the cord" so that the DSP-DAC can be located remotely.
The motivation is to make it possible to "cut the cord" between some audio source and the DAC. Maybe because the playback system is not near where your main computer sits, etc. Instead of a cord like a USB cable that carried the audio data to your DAC, we use your existing LAN to send the data to your DAC using GSASysCon.
The idea is to put on your WiFi network some small hardware/computer like a SBC or any old thing that will run Linux. An audio "sink" e.g. DAC or audio interface is attached to it and GSASysCon is used to stream audio over the LAN to this computer. GSASysCon does everything needed at the endpoint so that audio is produced, DSP is done, etc. while the user controls it from the source side.
GSASysCon must be run from within a bash shell, and this typically means Linux OSes only. However, the bash shell is available in the Windows 11 "Windows Subsystem for Linux". You only need one extra step to get audio from the Windows side to WSL2. I do not like PulseAudio for this purpose, so instead I used the following scheme:
- I install the VB-Audio VirtualCable loopback and send Windows audio to it
- In a Windows Command Shell I run a simple GStreamer one-liner to take the audio from the VC-loopback output and send it to a local port
- In WSL2 I run GSASysCon. It grabs the audio from the local port and then will re-stream it over your LAN to the computer where the DAC is connected.
I did something like this a few years ago, and described it a bit here:
The main difference was that I was trying to send the audio back to the Windows side and then out to locally connected USB DAC. That's actually more complicated than sending the audio over your LAN to another computer!
This idea has come about (or come up again) as I think about my current project, which is Pi-5 with a HiFiBerry Dac8x HAT running as a USB-gadget audio device. That plugs directly into your computer, and the result is a locally-connected DSP-capable 8-channel DAC. It's like a DIY version of a miniDSP FLEX HT or HTx with the only input being via USB. The next step is to "cut the cord" so that the DSP-DAC can be located remotely.
Charlie, clearly an interesting concept!
I'm not sure though that I understand the advantage.
It's probably my ignorance, and 'cutting the cord' is always attractive, but if you need to add an SBC or equivalent at the other end of the cut cord, what does that give me?
Edit: I have an OKTO DAC8 Pro which is not DSP capable and it would be nice to add a DSP frontend to it. Currently I use a dedicated PC running JRiver with DSP through Acourate.
Jan
I'm not sure though that I understand the advantage.
It's probably my ignorance, and 'cutting the cord' is always attractive, but if you need to add an SBC or equivalent at the other end of the cut cord, what does that give me?
Edit: I have an OKTO DAC8 Pro which is not DSP capable and it would be nice to add a DSP frontend to it. Currently I use a dedicated PC running JRiver with DSP through Acourate.
Jan
Hi Jan!
When you (as you say) "add an SBC" you are:
1. adding an endpoint for the audio stream that is coming from somewhere else in your home over your LAN
2. adding IIR DSP capabilities (FIR is not supported)
So, using your example of the OKTO DAC8 Pro, you would use this in USB input mode. When connected to the SBC the DAC8 would appear as an 8 channel ALSA output device. Stereo audio is sent to the SBC over your LAN, the SBC does routing and DSP and then sends the audio on to the DAC8.
It is sort of the same concept as Dante or Shairport-sync, Airplay, and other streaming audio platforms but with the addition of DSP and meant for DIY amusement. It works well over WiFi, which some (like Dante) do not.
The DSP capabilities are not going to be a substitute for Acourate (an amazing piece of software!), however, there is support for group delay EQ through my reverse-IIR LADSPA plugins, and of course all the "analog like" filters and so on are supported.
You are more than welcome to send me a PM if you want more complete details or to talk about your particular application.
When you (as you say) "add an SBC" you are:
1. adding an endpoint for the audio stream that is coming from somewhere else in your home over your LAN
2. adding IIR DSP capabilities (FIR is not supported)
So, using your example of the OKTO DAC8 Pro, you would use this in USB input mode. When connected to the SBC the DAC8 would appear as an 8 channel ALSA output device. Stereo audio is sent to the SBC over your LAN, the SBC does routing and DSP and then sends the audio on to the DAC8.
It is sort of the same concept as Dante or Shairport-sync, Airplay, and other streaming audio platforms but with the addition of DSP and meant for DIY amusement. It works well over WiFi, which some (like Dante) do not.
The DSP capabilities are not going to be a substitute for Acourate (an amazing piece of software!), however, there is support for group delay EQ through my reverse-IIR LADSPA plugins, and of course all the "analog like" filters and so on are supported.
You are more than welcome to send me a PM if you want more complete details or to talk about your particular application.
@jan.didden Let's say that you did not want to lose the DSP processing capabilities you have already created with Acourate. You could still send its output to a loopback device and then forward it over your LAN to the endpoint as multichannel PCM audio. At the endpoint no DSP is applied and the audio is just sent to the DAC8 Pro. GSASysCon is handling the "transport" of the audio across your LAN, via as many simultaneous channels as you would like. I designed GSASysCon to do DSP processing at the endpoint after transport, to reduce the LAN traffic to a minimum.
PicorePlayer on Pi will do this and CamillaDSP can be included. It's really easy. Add your preferred DAC hat or USB DAC.
//
//
@TNT Picore player has DSP? I did not see that, so I think that is not correct. Only if you also add CDSP somehow.
GSASysCon is a positioned as a simpler-to-use alternative to CamillaDSP, and the streaming part and the DSP part are both included. No need to try an marry multiple software packages...
GSASysCon is a positioned as a simpler-to-use alternative to CamillaDSP, and the streaming part and the DSP part are both included. No need to try an marry multiple software packages...
The marriage ihs already taken place - I use it and it works really good - and CDSP GUI is great. But it's nice with more then one alternative.
I gurgled it and I now see you are the author of the DSP platform - sorry I did not know this and I hadn't suggested CDSP if I knew...
//
I gurgled it and I now see you are the author of the DSP platform - sorry I did not know this and I hadn't suggested CDSP if I knew...
//
@TNT No worries! CDSP is top notch and has more capabilities (like FIR) compared to GSASysCon, but as a result is more complex/complicated.
I am promoting GSASysCon as the "simpler alternative" (in terms of setup and configuration) for e.g. loudspeaker crossovers and multi-endpoint streaming. Since I have only been using it for that purpose myself, I have not kept up with what other sort of software can do that, along with DSP.
I am promoting GSASysCon as the "simpler alternative" (in terms of setup and configuration) for e.g. loudspeaker crossovers and multi-endpoint streaming. Since I have only been using it for that purpose myself, I have not kept up with what other sort of software can do that, along with DSP.
For those who are interested to learn more about how this can be done, please go to the docs folder of my GitHub project page here:
https://github.com/charlielaub/GSASysCon/tree/main/system_control/docs
Open the doc "GSASysCon_Advanced_Topics.txt" and read the section HOW TO USE GSASysCon WITH REMOTE CLIENTS. This describes how the LAN connection is performed.
https://github.com/charlielaub/GSASysCon/tree/main/system_control/docs
Open the doc "GSASysCon_Advanced_Topics.txt" and read the section HOW TO USE GSASysCon WITH REMOTE CLIENTS. This describes how the LAN connection is performed.
Adding on to the last post a bit... You also need to get the audio into the GSASysCon GStreamer pipeline. If you are running GSASysCon under Linux, you can get the audio from Pulse Audio or Pipewire using a GStreamer element like pulsesrc, or you could route audio via the ALSA loopback and then use alsasrc device=(the loopback).
Under Windows, we can use WSL2 in Windows 11 to run GSASysCon, however, we need to get the audio from the Windows side and make it accessible on the WSL2 side. I alluded to this while I wrote post 2 earlier in this thread, however, since that time I discovered that all of that could be automated under WSL2 because it can run Windows programs from within WSL2. As a result, the GStreamer pipeline to send the audio from VB Cable under Windows can be put in a script file and run when the GSASysCon system is launched. This hides a lot of complexity behind the simple GSASysCon user interface, and everything should happen with the push of a single key.
I will be working on and testing this using a Raspberry Pi5 based system. I am currently waiting around for the cabling I need to connect its DAC to my speakers that will allow me to do live testing of the setup. After I have double checked everything I will post more about how to do it.
Under Windows, we can use WSL2 in Windows 11 to run GSASysCon, however, we need to get the audio from the Windows side and make it accessible on the WSL2 side. I alluded to this while I wrote post 2 earlier in this thread, however, since that time I discovered that all of that could be automated under WSL2 because it can run Windows programs from within WSL2. As a result, the GStreamer pipeline to send the audio from VB Cable under Windows can be put in a script file and run when the GSASysCon system is launched. This hides a lot of complexity behind the simple GSASysCon user interface, and everything should happen with the push of a single key.
I will be working on and testing this using a Raspberry Pi5 based system. I am currently waiting around for the cabling I need to connect its DAC to my speakers that will allow me to do live testing of the setup. After I have double checked everything I will post more about how to do it.
UPDATE:
I got a system up and running and have been testing it for several hours. Everything seems to be working well. I am playing audio on my Windows 11 machine, where I installed the VB-Cable Virtual Cable loopback. I set up the player software to send audio to it but you could also just make it the default audio device. The rest of the chain is handled in the Windows Subsystem for Linux (WSL2). There is one process that is getting audio from the Virtual Cable loopback and pushing it out to a local port. I then use a GSASysCon system to get that audio and stream it over my WiFi to a Raspberry Pi 5 and to an audio sink (DAC + headphones) attached to it. I am streaming 44.1k 16 bit audio since that is mostly what I am playing. The rate and format are set by the loopback, which runs at a fixed rate and resamples when necessary. I played some audio tracks that had other rates and formats and everything was seamless, with nothing that would let you know there was a rate change, etc. I will test other rates and formats when I have some time. With the playback chain working, it is a simple matter to add in as much IIR DSP as you want!
I got a system up and running and have been testing it for several hours. Everything seems to be working well. I am playing audio on my Windows 11 machine, where I installed the VB-Cable Virtual Cable loopback. I set up the player software to send audio to it but you could also just make it the default audio device. The rest of the chain is handled in the Windows Subsystem for Linux (WSL2). There is one process that is getting audio from the Virtual Cable loopback and pushing it out to a local port. I then use a GSASysCon system to get that audio and stream it over my WiFi to a Raspberry Pi 5 and to an audio sink (DAC + headphones) attached to it. I am streaming 44.1k 16 bit audio since that is mostly what I am playing. The rate and format are set by the loopback, which runs at a fixed rate and resamples when necessary. I played some audio tracks that had other rates and formats and everything was seamless, with nothing that would let you know there was a rate change, etc. I will test other rates and formats when I have some time. With the playback chain working, it is a simple matter to add in as much IIR DSP as you want!
I have been testing the playback for several days and it's working great! There was a bit of a delay while I figured out how to get Windows time service working properly. With that in the rear view mirror I am hoping to find a volunteer who will set up and test the wireless system, with playback from Windows 11 WSL2 to a system running a Linux OS, so that I can identify any missed steps in my tutorial docs. I think I have covered all of the necessary steps, but I cannot go back to a fresh install for Windows to double check.
If any of the following users want to be the guinea pig, drop me a PM and I will get you going and give you help if anything does not work:
@a007udio @Kev06 @kirks @Stretchie @Dieter Geissel @dptucunduva @m-a
If any of the following users want to be the guinea pig, drop me a PM and I will get you going and give you help if anything does not work:
@a007udio @Kev06 @kirks @Stretchie @Dieter Geissel @dptucunduva @m-a