Yes, I did indeed but since I have not used it recently I need to pull it out and dust it off before making any advertisements. That might be the next thing I work on.
OK back now after a brief trip into the files where I read over my code and notes about the FIR LADSPA plugin I created. Although I do not have any FIR kernels around to test it with, last I checked it is working fine. I had it posted for a couple of years on the LADSPA plugin page of my web site but AFAIK no one ever used it, so I removed it. Because it does FIR processing under LADSPA it can be run from GSASysCon.
There are a couple of steps to setting it up and using it. If you @DcibeL (or anyone else) are interested in giving it a try I suggest that you read the file attached info/instructions. If that doesn't scare you off, drop me a line and I will share it with you personally, and help you get up and running under GSASysCon.
The way it works is IMO kind of interesting. The LADSPA plugin is just a conduit to send data off to another program. LADSPA plugins must be computationally light and return quickly to the host after they are called, so there is no way you could directly code up an FFT routine inside one. Instead the plugin creates pipes in the OS and then runs an OS program (C++ code, compiled) that I wrote that receives the audio data on the other end of a pipe, runs it through FFTW, and then sends it back through another pipe to the LADSPA plugin. Once everything is up and running this goes like clockwork. The tricky bit comes at startup where some setup takes place and info (text and parameter data) has to be sent over the pipe from the LADSPA plugin in order for the FFTW to be configured correctly. In the meantime the LADSPA plugin waits for a "ready" signal from the external program and just returns zero data for a couple of cycles until finally the processed audio data starts flowing back to it. I had to get creative to set up all of these things, all the while making sure that the LADSPA plugin was not blocking or taking too long to return back to the LADSPA host (e.g. Gstreamer). That was definitely some "fun" programming...
There are a couple of steps to setting it up and using it. If you @DcibeL (or anyone else) are interested in giving it a try I suggest that you read the file attached info/instructions. If that doesn't scare you off, drop me a line and I will share it with you personally, and help you get up and running under GSASysCon.
The way it works is IMO kind of interesting. The LADSPA plugin is just a conduit to send data off to another program. LADSPA plugins must be computationally light and return quickly to the host after they are called, so there is no way you could directly code up an FFT routine inside one. Instead the plugin creates pipes in the OS and then runs an OS program (C++ code, compiled) that I wrote that receives the audio data on the other end of a pipe, runs it through FFTW, and then sends it back through another pipe to the LADSPA plugin. Once everything is up and running this goes like clockwork. The tricky bit comes at startup where some setup takes place and info (text and parameter data) has to be sent over the pipe from the LADSPA plugin in order for the FFTW to be configured correctly. In the meantime the LADSPA plugin waits for a "ready" signal from the external program and just returns zero data for a couple of cycles until finally the processed audio data starts flowing back to it. I had to get creative to set up all of these things, all the while making sure that the LADSPA plugin was not blocking or taking too long to return back to the LADSPA host (e.g. Gstreamer). That was definitely some "fun" programming...
GSASysCon Example - stream from browser to an existing PCM defined in asound.conf
Objective: to stream from a browser to active speakers.
Background: the system uses a RPi4 to run Charlie's ACDf routines for crossover and eq.
The RPi4 has two stereo amps attached via USB, one for each of the 2-way speakers.
The Pi4 system also: streams TV sound to the speakers using HiFiBerry Digi IO and plays music stored on the Pi using Audacious.
Problem to be solved: browsers will only stream sound to the default hardware device, via pulseaudio; I have not been able to direct that stream to an ALSA PCM defined in asound.conf; despite trying several approaches.
Solution: turns out to be simple because Charlie has done the hard work!
Read the comprehensive documentation (several times if you an ordinary human like me).
Ensure gstreamer is installed, it was not fully installed on my RPis.
Ensure the ALSA Loopback device is installed, see Advanced Topics.
Add the Volume plugin to taskbar, select Loopback device, set the Profile to Analogue Stereo Output - the only profile that worked for me.
Crib the Example system_configuration File provided in Basic Topics and amend as required. Here is mine:
sysdefault is the pcm name in my asound.conf.
rate and format are set to reflect the most common ones of the website (https://streaming.prestomusic.com)
Useful addition: new file:
/home/username/.config/pipewire/pipewire.conf.d/10-rates.conf
# Adds more common rates
context.properties = {
default.clock.allowed-rates = [ 44100 48000 88200 96000 ]
}
REBOOT, or restart pipewire.
Now to progress to streaming over my local network.
Objective: to stream from a browser to active speakers.
Background: the system uses a RPi4 to run Charlie's ACDf routines for crossover and eq.
The RPi4 has two stereo amps attached via USB, one for each of the 2-way speakers.
The Pi4 system also: streams TV sound to the speakers using HiFiBerry Digi IO and plays music stored on the Pi using Audacious.
Problem to be solved: browsers will only stream sound to the default hardware device, via pulseaudio; I have not been able to direct that stream to an ALSA PCM defined in asound.conf; despite trying several approaches.
Solution: turns out to be simple because Charlie has done the hard work!
Read the comprehensive documentation (several times if you an ordinary human like me).
Ensure gstreamer is installed, it was not fully installed on my RPis.
Ensure the ALSA Loopback device is installed, see Advanced Topics.
Add the Volume plugin to taskbar, select Loopback device, set the Profile to Analogue Stereo Output - the only profile that worked for me.
Crib the Example system_configuration File provided in Basic Topics and amend as required. Here is mine:
Code:
SYSTEM_INPUT = alsasrc device='hw:CARD=Loopback,DEV=1' ! audio/x-raw,rate=96000,format=S24LE,channels=2
CLIENT=LOCAL_PLAYBACK
SINK_FORMAT=S24LE
CLIENT_SINK=alsasink device=sysdefault sync=false provide-clock=false
ROUTE=0,0,0 #route input channel 0 to output device 0's output ch 0
ROUTE=1,0,1 # route input channel 1 to output device 0's output ch 1sysdefault is the pcm name in my asound.conf.
rate and format are set to reflect the most common ones of the website (https://streaming.prestomusic.com)
Useful addition: new file:
/home/username/.config/pipewire/pipewire.conf.d/10-rates.conf
# Adds more common rates
context.properties = {
default.clock.allowed-rates = [ 44100 48000 88200 96000 ]
}
REBOOT, or restart pipewire.
Now to progress to streaming over my local network.
GSASysCon Example - stream from browser on one computer to an existing PCM defined in asound.conf on a different computer
See the previous post for background.
Charlie's Advanced Topics document has an explanation of how to set up the software on both machines.
My system_configuration file looks like:
The line "CLIENT=LOCAL_PLAYBACK" is replaced by the lines telling GStreamer where to send the stream.
See the previous post for background.
Charlie's Advanced Topics document has an explanation of how to set up the software on both machines.
My system_configuration file looks like:
Code:
# Steam from Desktop RPi5 to RPi4 (hostname soundz)
SYSTEM_INPUT = alsasrc device='hw:CARD=Loopback,DEV=1' ! audio/x-raw,rate=96000,format=S24LE,channels=2
STREAM_BITS=24 #sets bit depth of stream and playback
STREAM_RATE=96000 #sets sample rate of stream and playback
SERVER_RTBIN_PARAMETERS = ntp-time-source=ntp ntp-sync=true do-retransmission=true #rtp-profile=avpf
CLIENT=192.168.178.30 #one line per client indicating IP and channel
ACCESS=sshpass -p ******** ssh soundz@192.168.178.30
CLIENT_RTBIN_PARAMETERS= ntp-time-source=ntp ntp-sync=true latency=100 buffer-mode=synced
SINK_FORMAT=S24LE
CLIENT_SINK=alsasink device=sysdefault
ROUTE=0,0,0 # route input channel 0 to output device 0’s output ch 0
ROUTE=1,0,1 # route input channel 1 to output device 0’s output ch 1The line "CLIENT=LOCAL_PLAYBACK" is replaced by the lines telling GStreamer where to send the stream.
I have been getting some useful feedback from @RAndyB about the documentation.👍 At the same time I discovered that I had mistakenly taken out about 5 lines of code that have to do with ROUTE TEEs that are causing a small problem. I will be addressing both of these, with updated documentation and the next revision of GSASysCon, by this weekend at the latest.
Any and all feedback and especially problem reports are very useful to me. Please feel free to PM me if you have anything to report, or are stuck and need help.
Any and all feedback and especially problem reports are very useful to me. Please feel free to PM me if you have anything to report, or are stuck and need help.
A new release is available. Please see the first post of this thread to upgrade to the 21 March 2025 version.
As always I would love your feedback. If you find errors or encounter problems or difficulties, please contact me via PM or post in this thread.
As always I would love your feedback. If you find errors or encounter problems or difficulties, please contact me via PM or post in this thread.
When I said I had been using GSASysCon for over 10 years I wasn't kidding. I just found an old thread about GSASysCon that I started in 2016 and had totally forgotten about! 😆
The threads runs through 2019 but really not much was posted there since 2018 and the thread is now closed by the mods. Many improvements and updates have been added since that time and now the docs are mature as well. I hope that this time around it will attract more users. For me this is a perfect balance of ease of use, features, and performance. I haven' bought a hardware DSP in years because of this program, and now there are only audio interfaces and mini PCs are on my wish list.
The threads runs through 2019 but really not much was posted there since 2018 and the thread is now closed by the mods. Many improvements and updates have been added since that time and now the docs are mature as well. I hope that this time around it will attract more users. For me this is a perfect balance of ease of use, features, and performance. I haven' bought a hardware DSP in years because of this program, and now there are only audio interfaces and mini PCs are on my wish list.
I am all for it! The problem is that, although I have cloned a couple of repositories in the past, I have never maintained a project there, etc. so I am a bit in the dark about how to go about it. If you think that would be useful and you or someone could help get me up and running I would love to do it.
Last edited:
IMO it's very simple https://docs.github.com/en/migratio...rce-code/adding-locally-hosted-code-to-github . Just create a new repo in your github account and push your local git repo there. If your project is not tracked with git locally yet, it's the best to do anyway. Both alternatives are described in that github doc link.
@phofman I don't have a GitHub account, never had a repository of my own work, and have not been part of a collaborative effort there. Is the FREE account sufficient for this type of project?
I guess I have to ask: Who wants to collaborate on this? If no one, why would I put it up on GitHub? The script that you download and run IS the code, so everything is already visible to anyone who wants to see it and use parts of it. On the other hand, if someone wants to join in on the project and improve it or take it in new directions I would be all for that. IMHO because it only uses the "testing" command line version of GStreamer and is not RUST or C++ code, the development potential is probably limited in terms of a "real" application, etc. But, hey, I am all ears.
I guess I have to ask: Who wants to collaborate on this? If no one, why would I put it up on GitHub? The script that you download and run IS the code, so everything is already visible to anyone who wants to see it and use parts of it. On the other hand, if someone wants to join in on the project and improve it or take it in new directions I would be all for that. IMHO because it only uses the "testing" command line version of GStreamer and is not RUST or C++ code, the development potential is probably limited in terms of a "real" application, etc. But, hey, I am all ears.
Charlie, it's really up to you, however you decide. Using git for tracking changes is extremely useful even for local development, no server is required, everything is in local directories. But being able to see what was changed from the last commit is indispensible. Every good programming editor gives the constant overview of what was changed, directly when viewing the file contents. I cannot imagine how I would write and maintain a larger code base without tracking the changes (originally CVS, then subversion, git has been by far the best for over a decade).
Pushing an existing repo to github is an optional step which can be done at any time. Yes, a free github account is sufficient, in fact vast majority of accounts there are free. You can keep repositories private and make them public at will (then hiding them again will not work reliably though). Apart of github (MS owned, IMO even private repos are used for training their copilot AI) there are other well-known repository servers, such as gitlab.com.
IMO if you want to attract new potential developers, moving from a zip to an online repo (almost always based on git nowadays) is almost necessary.
Pushing an existing repo to github is an optional step which can be done at any time. Yes, a free github account is sufficient, in fact vast majority of accounts there are free. You can keep repositories private and make them public at will (then hiding them again will not work reliably though). Apart of github (MS owned, IMO even private repos are used for training their copilot AI) there are other well-known repository servers, such as gitlab.com.
IMO if you want to attract new potential developers, moving from a zip to an online repo (almost always based on git nowadays) is almost necessary.
There definitely is a learning curve to GitHub but the GitHub Desktop app makes day to day routine tasks pretty easy. I'm so accustomed to it now that I may not recall all the steps to get up and going but I'll give it a shot. I'm using a Mac btw.
Create an account on GitHub, its completely free
Install GitHub Desktop app on your PC or Mac
This app is essential for avoiding Git command line interaction, unless you do something really bad and need an expert for a bail out.
1. In GitDesktop settings, install the Git command line tools
2 In GitDesktop settings, login to your GitHub account
3. Once GitDesktop is connected to your remote GitHub account you can create a new (local) practice repository
Choose a code editor
1. Install either Atom or VS Code (I think most use VS code but I happen to use Atom)
2. In GitHub Desktop > Settings > Integrations, choose the editor
With your local file manager copy your source files into the new repository that was created in step 3 above.
GitHub Desktop should show these newly added files in its left pane.
1. Check mark all of them
2. Type in a short summary
3. Click the "Commit to main" button
This commits the files to the local repository
4. In the right pane click the "Push origin" button
This syncs the local commits to the remote Git repo
So the basic work flow is add/change/delete to local repo files then push to remote Git repo.
Other parts of GitHub work flow require more learning for example maintaining separate main and dev branches, Pull Requests from other devs etc.
Feel free to email me for questions
Thanks to @phofman and especially @TimCurtis this project is now on GitHub! You can find the release here:
https://github.com/charlielaub/GSASysCon/releases/tag/3.15.0
https://github.com/charlielaub/GSASysCon/releases/tag/3.15.0
NEWS:
Coming soon...
I am currently working on a script that will automate the installation of GSASysCon, and making more improvements to the documentation. Both of these are an effort to make it easier for people to get started with GSASysCon.
Next Up: A project for the HiFiBerry DAC8x:
Once those changes have been rolled out to GitHub I will be creating an example project for the Raspberry Pi 5 and the HiFiBerry DAC8x and STUDIO DAC8x HATs, with the Pi configured as a USB-gadget. IMO this is a very interesting application for the Pi that turns it into a USB DAC that has heaps of DSP functionality. To keep the implementation simple it will run at a fixed sample rate and bit depth, which will probably be 96k/32bit. I plan to create a skeleton system configuration file for the Pi+HAT system that the user can then populate with their own crossover and EQ filters. I will make this available in GSASysCon's system_control/examples folder.
Coming soon...
I am currently working on a script that will automate the installation of GSASysCon, and making more improvements to the documentation. Both of these are an effort to make it easier for people to get started with GSASysCon.
Next Up: A project for the HiFiBerry DAC8x:
Once those changes have been rolled out to GitHub I will be creating an example project for the Raspberry Pi 5 and the HiFiBerry DAC8x and STUDIO DAC8x HATs, with the Pi configured as a USB-gadget. IMO this is a very interesting application for the Pi that turns it into a USB DAC that has heaps of DSP functionality. To keep the implementation simple it will run at a fixed sample rate and bit depth, which will probably be 96k/32bit. I plan to create a skeleton system configuration file for the Pi+HAT system that the user can then populate with their own crossover and EQ filters. I will make this available in GSASysCon's system_control/examples folder.
This looks pretty good -- thank you for all the hard work!
One question I have is regarding the compatibility with various linux flavors and platforms. I'm not all that interested in a system that can act as a household audio streamer, but as a standalone for one audio system. In that context, a linux SBC like a Raspberry Pi (x?) where "x?" would indicate "3", "4" or "5"; or its equivalent like a HardKernel C4 or N+ would be most desirable, cost-wise
I'm hoping that if the install OS supports gstreamer and includes Alsa, it's all good -- but that could be a rash assumption. The use of GPIO pins to support things like system on/off/mute and external volume controls clearly favors something other than a PC, but there are a number of linux SBCs out there that are not in the RPi ecosphere.
A document on your github site which has this kind of information might be useful, in terms of helping folks decide what components will work for them. I understand that this kind of information comes from the user base so will start out pretty sparse but will grow over time.
Mark
One question I have is regarding the compatibility with various linux flavors and platforms. I'm not all that interested in a system that can act as a household audio streamer, but as a standalone for one audio system. In that context, a linux SBC like a Raspberry Pi (x?) where "x?" would indicate "3", "4" or "5"; or its equivalent like a HardKernel C4 or N+ would be most desirable, cost-wise
I'm hoping that if the install OS supports gstreamer and includes Alsa, it's all good -- but that could be a rash assumption. The use of GPIO pins to support things like system on/off/mute and external volume controls clearly favors something other than a PC, but there are a number of linux SBCs out there that are not in the RPi ecosphere.
A document on your github site which has this kind of information might be useful, in terms of helping folks decide what components will work for them. I understand that this kind of information comes from the user base so will start out pretty sparse but will grow over time.
Mark
Hi Mark. Here are some answers to your questions:
The Pi platform is perfectly suited for GSASysCon. There is really no hardware restriction, so the other ARM boards should all work where ever the bash shell is available and GStreamer, and ACDf LADSPA can be installed. I have been using GSASysCon for years on various Raspberry Pi boards and currently have a headless Pi 3B+ and Pi 5 running it now in my household. Any Intel or AMD based computer (laptop, desktop, etc.) will also work great and I have used GSASysCon on many of these.
GSASysCon runs in the bash shell environment and requires GStreamer to run. The bash shell is available on most Linux OSes, if not all of them. GStreamer is also widely available under Linux and Windows. For DSP you need to install LADSPA and the ACDf plugin, which is available for all Linuxes and the Win11 WSL2 Linux environment, but not under native Windows.
As far as the Linux OS flavor, I have written the installation instructions for Debian based OSes. These are OSes such as Ubuntu and Raspberry OS, of which there are MANY:
https://en.wikipedia.org/wiki/Category:Debian-based_distributions
including Kali Linux and Mint. These use apt or apt-get for package management (installation of programs and features). OSes based on Fedora use a completely different package manager, and packages may have different names, so it is best to stick with one of the Debian variants.
ALSA is the audio subsystem for all Linuxes. If GStreamer is not installed by default it should be a simple matter to install it using the package manager as explained in the installation instructions. In the next revision this will be fully automated so you do not need to have any real Linux expertise to get going. Raspberry Pi is just the most widely recognized SBC, and GSASysCon will work just fine on other SBCs.
I do this now for the loudspeakers connected to my main computer system. I have also used a laptop set up with GSASysCon to run DIY loudspeaker projects that I take to shows or events. Works great.
If you have more questions about how it works for controlling playback (local playback) of an audio system, feel free to ask.
The Pi platform is perfectly suited for GSASysCon. There is really no hardware restriction, so the other ARM boards should all work where ever the bash shell is available and GStreamer, and ACDf LADSPA can be installed. I have been using GSASysCon for years on various Raspberry Pi boards and currently have a headless Pi 3B+ and Pi 5 running it now in my household. Any Intel or AMD based computer (laptop, desktop, etc.) will also work great and I have used GSASysCon on many of these.
GSASysCon runs in the bash shell environment and requires GStreamer to run. The bash shell is available on most Linux OSes, if not all of them. GStreamer is also widely available under Linux and Windows. For DSP you need to install LADSPA and the ACDf plugin, which is available for all Linuxes and the Win11 WSL2 Linux environment, but not under native Windows.
As far as the Linux OS flavor, I have written the installation instructions for Debian based OSes. These are OSes such as Ubuntu and Raspberry OS, of which there are MANY:
https://en.wikipedia.org/wiki/Category:Debian-based_distributions
including Kali Linux and Mint. These use apt or apt-get for package management (installation of programs and features). OSes based on Fedora use a completely different package manager, and packages may have different names, so it is best to stick with one of the Debian variants.
ALSA is the audio subsystem for all Linuxes. If GStreamer is not installed by default it should be a simple matter to install it using the package manager as explained in the installation instructions. In the next revision this will be fully automated so you do not need to have any real Linux expertise to get going. Raspberry Pi is just the most widely recognized SBC, and GSASysCon will work just fine on other SBCs.
I do this now for the loudspeakers connected to my main computer system. I have also used a laptop set up with GSASysCon to run DIY loudspeaker projects that I take to shows or events. Works great.
If you have more questions about how it works for controlling playback (local playback) of an audio system, feel free to ask.
It doesn't matter at all in terms of the operation of the program, so either is fine. Most OSes have moved to 64 bit kernels so if you have the choice, choose that one (e.g. Raspberry OS - the 32 bit OS is mostly for older boards or the Zero).