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
UPDATE and "the END":
Once I had everything working, I did a lot of long-term listening. Unfortunately I was not totally satisfied with the performance when Windows is involved. The initial scheme was to use GStreamer under Windows to stream the audio from the VB-Cable loopback to a local port. Another, separate GStreamer instance runs on the WSL2 side, and using GSASysCon I restreamed the audio to the Pi. This works - the audio plays and sounds great, but there are small audible glitches that get more noticeable after a couple of hours. Stopping and re-starting all of the processes did not fix this. I thought this was due to disparate clock domains, so I spent a bunch of time getting NTP running with the Windows Win32time process. I also attempted to install chrony NTP server on WSL2, but it seems there is a rootspace chrony instance that always clobbers it. The rootspace chrony instance always syncs only to the CMOS clock, and it is not clear when its time is updated, or not. I checked a few other potential culprits in the playback chain, but could not fix it. With that effort not totally clearing up the audio glitches I moved next to streaming directly from the Windows GStreamer instance to the Pi, cutting out WSL and GSASysCon completely. But this had the same sorts of problems and I could not even get audio playback to work this morning when Windows was involved.
On the other side of the coin, when I use only Linux OSes to send and receive the audio stream, everything works perfectly and there are never any problems. This shows that the Pi itself is not the cause of the problem(s). I use Linux for all the audio machines in my home and have been doing that for years. When I added the Pi with the HiFiBerry DAC8x hat to my whole-house music system run by GSASysCon everything worked perfectly. So I can only conclude that getting Windows involved is a bad idea all around. I could spend days and days trying to chase down this issue, but due to lack of interest by others I am not going to waste any more time going down that rabbit hole.
There is however one possible solution if you REALLY need to use Windows as your main playback machine: use a Pi running in USB gadget mode as the SENDER and another Pi (with the audio HAT) as the RECEIVER and then you will have a Linux to Linux LAN connection that should work. But I will leave that up to anyone who wants to try it. I'm always willing to help you get set up, but since my own Linux systems work fine it's not something that is on my to-do list.
So that about wraps up this thread. If you want to stream over your LAN to an endpoint such as a Pi or miniPC with an audio device/DAC, my advice is to use only Linux OSes and GSASysCon to do that. It's been working for over 10 years for me.
Once I had everything working, I did a lot of long-term listening. Unfortunately I was not totally satisfied with the performance when Windows is involved. The initial scheme was to use GStreamer under Windows to stream the audio from the VB-Cable loopback to a local port. Another, separate GStreamer instance runs on the WSL2 side, and using GSASysCon I restreamed the audio to the Pi. This works - the audio plays and sounds great, but there are small audible glitches that get more noticeable after a couple of hours. Stopping and re-starting all of the processes did not fix this. I thought this was due to disparate clock domains, so I spent a bunch of time getting NTP running with the Windows Win32time process. I also attempted to install chrony NTP server on WSL2, but it seems there is a rootspace chrony instance that always clobbers it. The rootspace chrony instance always syncs only to the CMOS clock, and it is not clear when its time is updated, or not. I checked a few other potential culprits in the playback chain, but could not fix it. With that effort not totally clearing up the audio glitches I moved next to streaming directly from the Windows GStreamer instance to the Pi, cutting out WSL and GSASysCon completely. But this had the same sorts of problems and I could not even get audio playback to work this morning when Windows was involved.
On the other side of the coin, when I use only Linux OSes to send and receive the audio stream, everything works perfectly and there are never any problems. This shows that the Pi itself is not the cause of the problem(s). I use Linux for all the audio machines in my home and have been doing that for years. When I added the Pi with the HiFiBerry DAC8x hat to my whole-house music system run by GSASysCon everything worked perfectly. So I can only conclude that getting Windows involved is a bad idea all around. I could spend days and days trying to chase down this issue, but due to lack of interest by others I am not going to waste any more time going down that rabbit hole.
There is however one possible solution if you REALLY need to use Windows as your main playback machine: use a Pi running in USB gadget mode as the SENDER and another Pi (with the audio HAT) as the RECEIVER and then you will have a Linux to Linux LAN connection that should work. But I will leave that up to anyone who wants to try it. I'm always willing to help you get set up, but since my own Linux systems work fine it's not something that is on my to-do list.
So that about wraps up this thread. If you want to stream over your LAN to an endpoint such as a Pi or miniPC with an audio device/DAC, my advice is to use only Linux OSes and GSASysCon to do that. It's been working for over 10 years for me.
That is a frustrating development, Charlie; how unfortunate. I haven't totally severed my use of windows yet, partly due to compatibility with internet media services, so that issue would certainly have been a problem in my case.
Thank you for all your work and willingness to post the results. I had hoped to contribute some testing at least, but unfortunately haven't had the time for hobbies of any kind lately. Not a situation that I'm happy with.
Thank you for all your work and willingness to post the results. I had hoped to contribute some testing at least, but unfortunately haven't had the time for hobbies of any kind lately. Not a situation that I'm happy with.
In the end, being able to stream from Windows is not crucial but being able to use at least one of the major bit perfect streaming services (qobuz, deezer, Amazon music, not sure if Tidal is bit perfect these days) from multiple devices onto a DSP unit would be great. Running an instance of the streaming service in a browser is probably not the way to go. At least in Windows, anything streaming from a browser window to a chromecast device is not bit perfect, whereas the same streaming service from an android, iphone, windows app to chromecast is.
If there is no way to cast onto a linux device, maybe using a chromecast audio or Wiim Pro is the way to go?
On a side note, is the Pi Hat 8x obsolete or just temporarily out of stock? What kind of DAC does it use and is the master clock on the hat or in the Pi?
If there is no way to cast onto a linux device, maybe using a chromecast audio or Wiim Pro is the way to go?
On a side note, is the Pi Hat 8x obsolete or just temporarily out of stock? What kind of DAC does it use and is the master clock on the hat or in the Pi?
I'm not necessarily chasing bit-perfect as such, but yes; I too dislike the degradation and (often) limitations of using browsers to access streaming services, but dedicated apps are not often available (natively) for Linux.
There would be options (e.g. Volumio etc) if I just streamed audio but it gets more complicated when one wants compatibility with a variety of audio and video/film sources and services - to be played through the same sytem (and kept in sync with the TV display). So windows clings on as part of my system, and sadly I don't currently have any time to sort out good alternatives (short of just moving to mac).
(I don't have any chromecast devices or the Pi hat, so can't help, though I've heard of people using mkchromecast and VLC to cast).
There would be options (e.g. Volumio etc) if I just streamed audio but it gets more complicated when one wants compatibility with a variety of audio and video/film sources and services - to be played through the same sytem (and kept in sync with the TV display). So windows clings on as part of my system, and sadly I don't currently have any time to sort out good alternatives (short of just moving to mac).
(I don't have any chromecast devices or the Pi hat, so can't help, though I've heard of people using mkchromecast and VLC to cast).
@Kev06 FWIW I believe under at least Ubuntu when I run Qobuz in a browser it uses the native format. Maybe you were referring to some other streaming services. I'm not really sure what you mean by "limitations of using browsers". In my setup with Ubuntu and Firefox, the browser is just sending the audio to the default device. Choose that wisely. Firefox doe snot resample, but your default device may do that. If you are running PulseAudio you need to edit its configuration to enable e.g. F32LE or S32LE format and using e.g soxr-hq for resampling. The default config is definitely less than "audiophile". See, for example:
https://medium.com/@gamunu/enable-high-quality-audio-on-linux-6f16f3fe7e1f
For most any software DSP app, there will be latency added to the audio when it is processed. This is an inevitable consequence of buffering (which is how computers process audio) and the larger the buffer the greater the latency. So if you REALLY need to keep the audio and video very tightly synchronized I would stick with a hardware DSP (or use analog filters!).
https://medium.com/@gamunu/enable-high-quality-audio-on-linux-6f16f3fe7e1f
For most any software DSP app, there will be latency added to the audio when it is processed. This is an inevitable consequence of buffering (which is how computers process audio) and the larger the buffer the greater the latency. So if you REALLY need to keep the audio and video very tightly synchronized I would stick with a hardware DSP (or use analog filters!).
It's probably just out of stock. They just released the companion ADC8x, would makes no sense to discontinue the DAC now.