Last Update to this Page: 25 April 2025.
GSASysCon Release 3.15.1 is now available for download. It includes an automated setup script that should make it easier to get started. You can find the project at GitHub using this link:
https://github.com/charlielaub/GSASysCon
To download the GZIP+TAR compressed file:
Under Linux you can use wget to download the file into the current directory instead of having to use a browser:
To unpack the compressed files: first gunzip the gz archive and then run tar -xvf on the resulting tar file. Follow the instructions in the SetupGuide.txt doc in the directory /system_control/docs.
You can look over the documentation online before downloading, at this link:
https://github.com/charlielaub/GSASysCon/tree/main/system_control/docs
ABOUT GSASysCon:
During the past 10 years I have been using Gstreamer pipelines plus my LADSPA plugins to implement software based IIR DSP processing. I find this approach much easier to configure and use than CamillaDSP so I would like to share this with the rest of the DIY community.
Gstreamer is a powerful multi-media platform that is continually undergoing development and improvement. Because Gstreamer pipelines are difficult to write from scratch, I wrote an application that generates them based on the contents of a user input file that describes the DSP processing. The application consists of a couple of input files and a large bash script (currently about 3000 lines long). The app will also launch and kill the pipelines when directed by you, and basic in-app volume control of local devices is available. Together these can be used to turn your computer into a “preamp” with input switching and volume control plus everything you need to do DSP processing. I use this to run all my own systems.
The app has the name “Gstreamer Streaming Audio System Controller”, or GSASysCon. GSASysCon is completely open source and you are welcome to modify or develop it.
Here is a quick overview of the behavior and features:
• Control of and Interaction with the program is 100% text based via simple input files and a text-based user-interface.
• Substitution and channel duplication capabilities make it easy to describe the DSP processing for complicated, multichannel setups.
• Filtering and routing is easy to configure via an intuitive configuration file structure
• The control interface can turn systems on and off and control playback volume. These features can be controlled remotely over your LAN via SSH.
• Gstreamer provides several source and sink TIME (not rate) based synchronization mechanisms. This makes it possible for synchronized playback of multiple, disparate sinks and adaptive rate playback.
• Can be run under Debian/Ubuntu based OSes (including Rasberry Pi OS) or Windows 11 WSL2 in which the bash shell is available.
• GSASysCon has no external dependencies except Gstreamer, and bash built-in commands.
• Input audio is typically via Pipewire/PulseAudio monitor or ALSA Loopback (use VB-Audio Virtual Cable under Windows)
• The Gstreamer command string for any pipeline can captured and run outside of the app, if desired.
Some differences between GSASysCon and CamillaDSP are:
• GSASysCon can create playback systems made up of multiple remote clients. Audio is sent using RTP over the local network (hardcable or WiFi) to one or more playback endpoints (computer+audio device/DAC). Tight playback synchronization between endpoints can be achieved when their clocks are synchronized using chrony (NTP).
• GSASysCon has no fancy level meters, no GUI, and no flow or filter diagrams except what can be generated manually using Gstreamer
• In GSASysCon, DSP is exclusively IIR filtering via LADSPA as filter-chains. FIR filtering is not currently available.
• GSASysCon was designed for music playback without any particular concerns for latency. Buffer size is fixed at 1024 samples.
• Gstreamer pipelines created with GSASysCon run at a fixed audio rate and bit depth that is chosen by the user. There is a high quality resampler built into Gstreamer that handles SR conversions.
The combination of Gstreamer and LADSPA is a robust and reliable DSP platform for DIY audio processing under Linux, or WSL2 under Windows. I've been using this to implement IIR DSP crossovers for almost 10 years in tandem with my ACDf LADSPA plugin. ACDf implements all the first and second order filter types – it’s all you need for loudspeaker crossovers and PEQ duty.
.
GSASysCon Release 3.15.1 is now available for download. It includes an automated setup script that should make it easier to get started. You can find the project at GitHub using this link:
https://github.com/charlielaub/GSASysCon
To download the GZIP+TAR compressed file:
Under Linux you can use wget to download the file into the current directory instead of having to use a browser:
wget https://github.com/charlielaub/GSASysCon/archive/refs/tags/3.15.1.tar.gzTo unpack the compressed files: first gunzip the gz archive and then run tar -xvf on the resulting tar file. Follow the instructions in the SetupGuide.txt doc in the directory /system_control/docs.
You can look over the documentation online before downloading, at this link:
https://github.com/charlielaub/GSASysCon/tree/main/system_control/docs
ABOUT GSASysCon:
During the past 10 years I have been using Gstreamer pipelines plus my LADSPA plugins to implement software based IIR DSP processing. I find this approach much easier to configure and use than CamillaDSP so I would like to share this with the rest of the DIY community.
Gstreamer is a powerful multi-media platform that is continually undergoing development and improvement. Because Gstreamer pipelines are difficult to write from scratch, I wrote an application that generates them based on the contents of a user input file that describes the DSP processing. The application consists of a couple of input files and a large bash script (currently about 3000 lines long). The app will also launch and kill the pipelines when directed by you, and basic in-app volume control of local devices is available. Together these can be used to turn your computer into a “preamp” with input switching and volume control plus everything you need to do DSP processing. I use this to run all my own systems.
The app has the name “Gstreamer Streaming Audio System Controller”, or GSASysCon. GSASysCon is completely open source and you are welcome to modify or develop it.
Here is a quick overview of the behavior and features:
• Control of and Interaction with the program is 100% text based via simple input files and a text-based user-interface.
• Substitution and channel duplication capabilities make it easy to describe the DSP processing for complicated, multichannel setups.
• Filtering and routing is easy to configure via an intuitive configuration file structure
• The control interface can turn systems on and off and control playback volume. These features can be controlled remotely over your LAN via SSH.
• Gstreamer provides several source and sink TIME (not rate) based synchronization mechanisms. This makes it possible for synchronized playback of multiple, disparate sinks and adaptive rate playback.
• Can be run under Debian/Ubuntu based OSes (including Rasberry Pi OS) or Windows 11 WSL2 in which the bash shell is available.
• GSASysCon has no external dependencies except Gstreamer, and bash built-in commands.
• Input audio is typically via Pipewire/PulseAudio monitor or ALSA Loopback (use VB-Audio Virtual Cable under Windows)
• The Gstreamer command string for any pipeline can captured and run outside of the app, if desired.
Some differences between GSASysCon and CamillaDSP are:
• GSASysCon can create playback systems made up of multiple remote clients. Audio is sent using RTP over the local network (hardcable or WiFi) to one or more playback endpoints (computer+audio device/DAC). Tight playback synchronization between endpoints can be achieved when their clocks are synchronized using chrony (NTP).
• GSASysCon has no fancy level meters, no GUI, and no flow or filter diagrams except what can be generated manually using Gstreamer
• In GSASysCon, DSP is exclusively IIR filtering via LADSPA as filter-chains. FIR filtering is not currently available.
• GSASysCon was designed for music playback without any particular concerns for latency. Buffer size is fixed at 1024 samples.
• Gstreamer pipelines created with GSASysCon run at a fixed audio rate and bit depth that is chosen by the user. There is a high quality resampler built into Gstreamer that handles SR conversions.
The combination of Gstreamer and LADSPA is a robust and reliable DSP platform for DIY audio processing under Linux, or WSL2 under Windows. I've been using this to implement IIR DSP crossovers for almost 10 years in tandem with my ACDf LADSPA plugin. ACDf implements all the first and second order filter types – it’s all you need for loudspeaker crossovers and PEQ duty.
.
Last edited:
How to define/configure a system for GSASysCon:
The system_configuration file is where you define routing (signal flow) and DSP that is applied to it. Let’s look at a couple of examples of how the system input file is structured.
Let's describe a minimalistic system that contains:
• an input, which in this case is the ALSA loopback device
• a “client”, which in this case in the same as the machine the code is running on
• one audio output sink on the client
• two routes that describe how the input audio channels will be routed to the output channels of the client audio sink.
The hash symbol “#” begins a comment.
Each ROUTE maps an input channel to an output channel with the three parameters indicating the input channel number, the output device number, and the output channel number. Channels are numbered starting from zero.
That’s it – it’s easy to understand and read. No crazy YAML formatting, etc.
Now let’s add some DSP. The filter chain is described by a list of DSP filters and/or Gstreamer elements. To apply the chain to a route, the list of statements are simply placed immediately after the route declaration statement.
Above, the indenting of the code is just to improve readability. Note that three new lines have been added just below each ROUTE declaration statement. In this example they are doing some equalization. Gstreamer automatically generates element names from any LADSPA plugins on the system, giving rise to the element named “ladspa-acdf-so-acdf” that invokes my ACDf plugin. The result is that we have applied the three DSP filters to each of the two (stereo) channels of audio that are being processed.
There are two ways to condense the description of the DSP actions. When the system involves more filters (e.g. for a multiway loudspeaker) it can be helpful to be more succinct without losing any info. We can start by defining and using a multiline variable that is given a unique identifier. Where ever this identifier is found in the input file, the contents of the multi-line variable are substituted. Like this:
We defined the variable "some_DEP_EQ" and used it to replace the DSP statements that we previoudly used within the ROUTEs. The result will be identical to when all of the DSP elements were listed out explicitly.
There is another way to simplify the input file – by listing all routes that use the same set of DSP filters “together” on one line. Here is an example of that and the multiline variable used together:
This is useful because for stereo audio the same DSP processing is typically used for both the left and right channels.
Another point to make about the configuration file syntax is that most Gstreamer elements have multiple options or parameters, many of which are optional. You might want to use them or not. For example, in this line:
Everything appearing after “CLIENT_SINK=” is native Gstreamer code consisting of the alsasink element and the associated parameters device, sync and provide-clock. By allowing the user to inline Gstreamer code deirectly, all of Gstreamer’s capabilities can be made available to the user.
These have been relatively simple examples, but it is easy to create more complicated routings that will be used for loudspeaker crossovers including parallel and branching topologies.
A NOTE about the DSP Filtering and EQ within GSASysCon:
Because Gstreamer automatically creates new elements from any LADSPA plugins installed on the system it is convenient to use them for DSP filtering. As an example, the ACDf filter plugin that I wrote takes a filter type and a few associated parameters (e.g. frequency and Q of the filter, etc.). The parameters control the behavior of each filter. Higher order crossovers are formed by listing multiple 1st or 2nd order filters in series, which is called a “filter chain”. This allows you to create many known audio filters such as the Butterworth or Linkwitz-Riley types of any order you wish by specifying their filter parameters. First and second order filters available with ACDf include low-pass, high-pass, all-pass, shelving (first and second order), parametric EQ, notch, and biquadratic (e.g. Linkwitz Transform) types.
The system_configuration file is where you define routing (signal flow) and DSP that is applied to it. Let’s look at a couple of examples of how the system input file is structured.
Let's describe a minimalistic system that contains:
• an input, which in this case is the ALSA loopback device
• a “client”, which in this case in the same as the machine the code is running on
• one audio output sink on the client
• two routes that describe how the input audio channels will be routed to the output channels of the client audio sink.
Code:
SYSTEM_INPUT = alsasrc device='hw:CARD=Loopback,DEV=1'
CLIENT=LOCAL_PLAYBACK
SINK_FORMAT=S32LE
CLIENT_SINK=alsasink device='hw:CARD=USB,DEV=0' sync=false provide-clock=false #this defines output #0 for this client
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 hash symbol “#” begins a comment.
Each ROUTE maps an input channel to an output channel with the three parameters indicating the input channel number, the output device number, and the output channel number. Channels are numbered starting from zero.
That’s it – it’s easy to understand and read. No crazy YAML formatting, etc.
Now let’s add some DSP. The filter chain is described by a list of DSP filters and/or Gstreamer elements. To apply the chain to a route, the list of statements are simply placed immediately after the route declaration statement.
Code:
SYSTEM_INPUT = alsasrc device='hw:CARD=Loopback,DEV=1'
CLIENT=LOCAL_PLAYBACK
SINK_FORMAT=S32LE
CLIENT_SINK=alsasink device='hw:CARD=USB,DEV=0' sync=false provide-clock=false #this defines output #0 for this client
ROUTE=0,0,0 #route input channel 0 to output device 0’s output ch 0
ladspa-acdf-so-acdf type=0 db=6 #add gain overall
ladspa-acdf-so-acdf type=24 db=4 fp=45 qp=1.0 #bass shelf/boost
ladspa-acdf-so-acdf type=26 db=-1.75 fp=800 qp=1.6 #PEQ band
ROUTE=1,0,1 # route input channel 1 to output device 0’s output ch 1
ladspa-acdf-so-acdf type=0 db=6 #add gain overall
ladspa-acdf-so-acdf type=24 db=4 fp=45 qp=1.0 #bass shelf/boost
ladspa-acdf-so-acdf type=26 db=-1.75 fp=800 qp=1.6 #PEQ bandAbove, the indenting of the code is just to improve readability. Note that three new lines have been added just below each ROUTE declaration statement. In this example they are doing some equalization. Gstreamer automatically generates element names from any LADSPA plugins on the system, giving rise to the element named “ladspa-acdf-so-acdf” that invokes my ACDf plugin. The result is that we have applied the three DSP filters to each of the two (stereo) channels of audio that are being processed.
There are two ways to condense the description of the DSP actions. When the system involves more filters (e.g. for a multiway loudspeaker) it can be helpful to be more succinct without losing any info. We can start by defining and using a multiline variable that is given a unique identifier. Where ever this identifier is found in the input file, the contents of the multi-line variable are substituted. Like this:
Code:
DEFINE_MULTILINE_VARIABLE some_DSP_EQ
ladspa-acdf-so-acdf type=0 db=6 #add gain overall
ladspa-acdf-so-acdf type=24 db=4 fp=45 qp=1.0 #bass shelf/boost
ladspa-acdf-so-acdf type=26 db=-1.75 fp=800 qp=1.6 #PEQ band
END_MULTILINE_VARIABLE
SYSTEM_INPUT = alsasrc device='hw:CARD=Loopback,DEV=1'
CLIENT=LOCAL_PLAYBACK
SINK_FORMAT=S32LE
CLIENT_SINK=alsasink device='hw:CARD=USB,DEV=0' sync=false provide-clock=false #this defines output #0 for this client
ROUTE=0,0,0 #route input channel 0 to output device 0’s output ch 0
some_DSP_EQ
ROUTE=1,0,1 # route input channel 1 to output device 0’s output ch 1
some_DSP_EQWe defined the variable "some_DEP_EQ" and used it to replace the DSP statements that we previoudly used within the ROUTEs. The result will be identical to when all of the DSP elements were listed out explicitly.
There is another way to simplify the input file – by listing all routes that use the same set of DSP filters “together” on one line. Here is an example of that and the multiline variable used together:
Code:
DEFINE_MULTILINE_VARIABLE some_DSP_EQ
ladspa-acdf-so-acdf type=0 db=6 #add gain overall
ladspa-acdf-so-acdf type=24 db=4 fp=45 qp=1.0 #bass shelf/boost
ladspa-acdf-so-acdf type=26 db=-1.75 fp=800 qp=1.6 #PEQ band
END_MULTILINE_VARIABLE
SYSTEM_INPUT = alsasrc device='hw:CARD=Loopback,DEV=1'
CLIENT=LOCAL_PLAYBACK
SINK_FORMAT=S32LE
CLIENT_SINK=alsasink device='hw:CARD=USB,DEV=0' sync=false provide-clock=false #this defines output #0 for this client
ROUTE=0,0,0; ROUTE=1,0,1 #both routes are listed on the same line because both use the same DSP processing
some_DSP_EQThis is useful because for stereo audio the same DSP processing is typically used for both the left and right channels.
Another point to make about the configuration file syntax is that most Gstreamer elements have multiple options or parameters, many of which are optional. You might want to use them or not. For example, in this line:
Code:
CLIENT_SINK=alsasink device='hw:CARD=USB,DEV=0' sync=false provide-clock=falseEverything appearing after “CLIENT_SINK=” is native Gstreamer code consisting of the alsasink element and the associated parameters device, sync and provide-clock. By allowing the user to inline Gstreamer code deirectly, all of Gstreamer’s capabilities can be made available to the user.
These have been relatively simple examples, but it is easy to create more complicated routings that will be used for loudspeaker crossovers including parallel and branching topologies.
A NOTE about the DSP Filtering and EQ within GSASysCon:
Because Gstreamer automatically creates new elements from any LADSPA plugins installed on the system it is convenient to use them for DSP filtering. As an example, the ACDf filter plugin that I wrote takes a filter type and a few associated parameters (e.g. frequency and Q of the filter, etc.). The parameters control the behavior of each filter. Higher order crossovers are formed by listing multiple 1st or 2nd order filters in series, which is called a “filter chain”. This allows you to create many known audio filters such as the Butterworth or Linkwitz-Riley types of any order you wish by specifying their filter parameters. First and second order filters available with ACDf include low-pass, high-pass, all-pass, shelving (first and second order), parametric EQ, notch, and biquadratic (e.g. Linkwitz Transform) types.
TEXT BASED CONTROL INTERFACE:
Below are a couple of screen shots of the text-based interface that is used with GSASysCon. These are screen shots I obtained on the setup I am currently using to control various speaker systems in my home.
GSASysCon is operating like a "preamp". To do this, there are two different instances running. One connects potential sources of audio to the ALSA Loopback. The other connects the output of the ALSA Loopback to one or more playback systems. In my home there is one "local" playback system (called stube) and two remote playback systems (kitchen and wohnzimmer) in other rooms. Stereo audio is streamed to each remote client in RTP packets. At the client it is unpacked back into PCM (uncompressed) audio and the DSP is performed for the system on the remote computer before passing thru a DAC to amps and speakers.
In preamp mode, one can use a simple volume control from within GSASysCon using the keyboard. In this case the current level setting of an ALSA control is manipulated. I use this to change the input level of a source, which then changes the playback levels for all enabled systems at the end of the playback chains.
The running time for a system or input is also shown in the text display.
INPUT SELECTION:
USING THE VOUME CONTROL
PLAYBACK SYSTEM SELECTION
Below are a couple of screen shots of the text-based interface that is used with GSASysCon. These are screen shots I obtained on the setup I am currently using to control various speaker systems in my home.
GSASysCon is operating like a "preamp". To do this, there are two different instances running. One connects potential sources of audio to the ALSA Loopback. The other connects the output of the ALSA Loopback to one or more playback systems. In my home there is one "local" playback system (called stube) and two remote playback systems (kitchen and wohnzimmer) in other rooms. Stereo audio is streamed to each remote client in RTP packets. At the client it is unpacked back into PCM (uncompressed) audio and the DSP is performed for the system on the remote computer before passing thru a DAC to amps and speakers.
In preamp mode, one can use a simple volume control from within GSASysCon using the keyboard. In this case the current level setting of an ALSA control is manipulated. I use this to change the input level of a source, which then changes the playback levels for all enabled systems at the end of the playback chains.
The running time for a system or input is also shown in the text display.
INPUT SELECTION:
USING THE VOUME CONTROL
PLAYBACK SYSTEM SELECTION
Here is a more involved example of a GSASysCon configuration file for a system that has the following characteristics:
• A multiway stereo loudspeaker (4-way)
• Audio is streamed to the system over my home WiFi
• Audio output at the client end on a Behringer UMC1820
• SSH access to remote client using pre-shared key
This is a complicated 4-way dipole loudspeaker. Per channel there are 32 different DSP filters being used. The crossover topology is parallel. Playback synchronization is used.
I won the 2022 Parts-Express Speaker Design Competition in the Unlimited category with this speaker system...
• A multiway stereo loudspeaker (4-way)
• Audio is streamed to the system over my home WiFi
• Audio output at the client end on a Behringer UMC1820
• SSH access to remote client using pre-shared key
This is a complicated 4-way dipole loudspeaker. Per channel there are 32 different DSP filters being used. The crossover topology is parallel. Playback synchronization is used.
I won the 2022 Parts-Express Speaker Design Competition in the Unlimited category with this speaker system...
Code:
#living room small speakers (2021F) using UMC1820 on CI329-2 mini PC
#
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.1.237 #one line per client indicating IP and channel
ACCESS=ssh charlie@192.168.1.237
CLIENT_RTBIN_PARAMETERS= ntp-time-source=ntp ntp-sync=true latency=100 buffer-mode=synced
PATH=gstreamer
SINK_FORMAT=S24LE
CLIENT_SINK= alsasink device='hw:CARD=UMC1820,DEV=0'
#muted audio for non-used channels
ROUTE=0,MUTED_INPUT
volume volume=0
#global filters - implement equal-loudness based voicing EQ:
ROUTE=0,LEFT_INPUT; 1,RIGHT_INPUT
ladspa-acdf-so-acdf type=0 db=10
ladspa-acdf-so-acdf type=24 db=-4.75 fp=150 qp=0.6 #dipole/monopole power response correction
ladspa-acdf-so-acdf type=28 db=-5 fp=1275 qp=0.45 fz=1700 qz=0.45 #voicing EQ
ladspa-acdf-so-acdf type=28 fp=65 qp=0.6 fz=150 qz=0.6 #bass boost
#subwoofer output on channels 0 and 1 to allow front panel volume control
ROUTE=LEFT_INPUT,0,-3; RIGHT_INPUT,0,-3
ladspa-acdf-so-acdf type=0 polarity=-1 db=-4
ladspa-acdf-so-acdf type=22 fp=15 qp=0.707 #high-pass LF rumble filter
ladspa-acdf-so-acdf type=28 fp=30 qp=0.6 fz=37 qz=0.9 #LT EQ
ladspa-acdf-so-acdf type=21 fp=150 qp=0.707
ladspa-acdf-so-acdf type=21 fp=150 qp=0.707
#woofer output to channels 2 and 3
ROUTE=LEFT_INPUT,0,-3; RIGHT_INPUT,0,-3
ladspa-acdf-so-acdf type=0 polarity=-1 db=-8.25
ladspa-acdf-so-acdf type=4 db=12 fp=350
ladspa-acdf-so-acdf type=28 fp=150 qp=0.707 fz=23 qz=0.27
ladspa-acdf-so-acdf type=25 db=-8 fp=425 qp=0.9
ladspa-acdf-so-acdf type=21 fp=600 qp=0.707
ladspa-acdf-so-acdf type=21 fp=600 qp=0.707
ladspa-acdf-so-acdf type=22 fp=150 qp=0.707
ladspa-acdf-so-acdf type=23 fp=500 qp=0.5
#midrange output to channels 4 and 5
ROUTE=LEFT_INPUT,0,-3; RIGHT_INPUT,0,-3
ladspa-acdf-so-acdf type=0 db=-3.75
ladspa-acdf-so-acdf type=26 db=-6 fp=1750 qp=4
ladspa-acdf-so-acdf type=28 fp=775 qp=0.7 fz=1050 qz=1.4
ladspa-acdf-so-acdf type=26 db=-5 fp=5300 qp=7
ladspa-acdf-so-acdf type=26 db=-1.25 fp=3650 qp=4
ladspa-acdf-so-acdf type=25 db=-6 fp=2000 qp=0.7
ladspa-acdf-so-acdf type=22 fp=600 qp=0.707
ladspa-acdf-so-acdf type=22 fp=600 qp=0.707
ladspa-acdf-so-acdf type=21 fp=2700 qp=0.707
ladspa-acdf-so-acdf type=21 fp=2700 qp=0.707
ladspa-acdf-so-acdf type=24 db=9 fp=250 qp=0.7
#tweeter output to channels 6 and 7
ROUTE=LEFT_INPUT,0,-3; RIGHT_INPUT,0,-3
ladspa-acdf-so-acdf type=0 polarity=1 db=-6 #gain set to -6 in alsamixer
ladspa-acdf-so-acdf type=22 fp=2700 qp=0.707
ladspa-acdf-so-acdf type=22 fp=2700 qp=0.707
ladspa-acdf-so-acdf type=23 fp=4500 qp=0.55
ROUTE=MUTED_INPUT,0,-3 #muted audio to channel 8
ROUTE=MUTED_INPUT,0,-3 #muted audio to channel 9
ROUTE=MUTED_INPUT,0,-3 #muted audio to channel 10
ROUTE=MUTED_INPUT,0,-3 #muted audio to channel 11I am currently making slow but sure progress on the documentation. I originally wrote some of these docs back in 2016 but the software has been updated many times since then so I have to re-write everything.
I hope to have something ready to go in another few days.
I hope to have something ready to go in another few days.
OK, my fingers are tired but the docs are pretty much written now. I will do some testing as if I am a new user and then I should be able to put it out there.
I would like to work with one or two people who want to give this a try, to get their feedback about and first imprssions. I want to make sure that a new user who is unfamiliar with Gstreamer and GSASysCon can get up and going without too many barriers, etc.
If you would like to give it a try, please PM me now.
Otherwise I will edit the first post with the download link in another day or two.
I would like to work with one or two people who want to give this a try, to get their feedback about and first imprssions. I want to make sure that a new user who is unfamiliar with Gstreamer and GSASysCon can get up and going without too many barriers, etc.
If you would like to give it a try, please PM me now.
Otherwise I will edit the first post with the download link in another day or two.
Gosh, this looks all very useful indeed, Charlie. Thank you for taking the time to make it more accessible for us. I've previously used CamillaDSP as a stereo 3-way crossover and EQ and had intended to do so again in the forthcomming setup. But it looks like your method would also work, with a slightly different set of characteristics. So, it is exciting to have different options to choose between; things like the time synchronisation and network streaming are already suggesting new possibilities that I could consider, though I'm unsure if latency might be an issue for situations when the audio is supposed to be associated with video.
Anyway, I'm currently setting up a new media PC, sadly quite slowly due to lack of spare time. But once it is ready I'd be very pleased to have a go at this method, especially if you are still looking for volunteers by that point. I certainly posess a great deal of unfamiliarity with Gstreamer, GSASysCon and most other things! Although your example code above seems possible to understand, so I might hope to get somewhere with it.
Thanks again,
Kev
Anyway, I'm currently setting up a new media PC, sadly quite slowly due to lack of spare time. But once it is ready I'd be very pleased to have a go at this method, especially if you are still looking for volunteers by that point. I certainly posess a great deal of unfamiliarity with Gstreamer, GSASysCon and most other things! Although your example code above seems possible to understand, so I might hope to get somewhere with it.
Thanks again,
Kev
UPDATE: the download link is now active - see the top of post #1 in this thread. If you encounter any problems please contact me so that I can fix them! Feedback is always appreciated via PM or post in this thread.
Please make sure to read all the help files in the docs directory, but if you get stuck when trying to implement your own DSP procesing with a GSASysCon system I am happy to help.
Please make sure to read all the help files in the docs directory, but if you get stuck when trying to implement your own DSP procesing with a GSASysCon system I am happy to help.
I decided to make a minor change to the setup instructions document. Just uploaded the new version now.
Some thoughts on using GSASysCon to run a DIY audio component:
GSASysCon includes basic volume control functionality that is driven by keyboard keypresses. These simply change the values of an ALSA card or device's control using the amixer command line interface. You could achieve the same thing by issuing amixer commands from the keyboard. What I like about this is that there are other ways to manipulate the volume of a control, such as alsamixer or sofware like PulseAudio, and of course (the way I typically do it) using "multimedia keys" on the keyboard that control the main system volume and muting. When the GSASysCon volume control interface is open, you can adjust the volume via any other means and it is immediately reflected in GSASysCon, since all of these methods are in fact adjusting the same endpoint: the volume control on the card. I just happened to code up GSASysCon to use amixer, since it was versatile and could be peformed within the code of the app.
With that said, there is yet another interesting volume control option (that I have not personally explored yet): External hardware "knob" type interfaces that you grab and turn like a traditional "volume control knob". For example, I know that there are USB based knobs on rotary encoders, and I assume these could be configured to adjust the volume of the system since that is their purpose. Adafruit makes a USB rotary encoder and has some code examples, although that is mainly intended for the Arduino platform. I have also worked with code that can process raw impulses from a rotary controller and then take some action based on this web page:
http://www.buxtronix.net/2011/10/rotary-encoders-done-properly.html
It's written for Arduino but could be adapted to other platforms like the Pi.
In any case, one could combine a small SBC having GPIO such as a Raspberry Pi, the GSASysCon app, and an audio interface in a small case, and then add some external switches and rotary controls connected to GPIO pins to provide tactile user controls. Then you would have an audio device that could function as a preamp, a DSP processor, and so on. Configuration would be done over SSH, and then it could function in a stand-alone mode until further changes were needed or wanted. It would be a cool and flexible computer-driven DIY-DSP project.
GSASysCon includes basic volume control functionality that is driven by keyboard keypresses. These simply change the values of an ALSA card or device's control using the amixer command line interface. You could achieve the same thing by issuing amixer commands from the keyboard. What I like about this is that there are other ways to manipulate the volume of a control, such as alsamixer or sofware like PulseAudio, and of course (the way I typically do it) using "multimedia keys" on the keyboard that control the main system volume and muting. When the GSASysCon volume control interface is open, you can adjust the volume via any other means and it is immediately reflected in GSASysCon, since all of these methods are in fact adjusting the same endpoint: the volume control on the card. I just happened to code up GSASysCon to use amixer, since it was versatile and could be peformed within the code of the app.
With that said, there is yet another interesting volume control option (that I have not personally explored yet): External hardware "knob" type interfaces that you grab and turn like a traditional "volume control knob". For example, I know that there are USB based knobs on rotary encoders, and I assume these could be configured to adjust the volume of the system since that is their purpose. Adafruit makes a USB rotary encoder and has some code examples, although that is mainly intended for the Arduino platform. I have also worked with code that can process raw impulses from a rotary controller and then take some action based on this web page:
http://www.buxtronix.net/2011/10/rotary-encoders-done-properly.html
It's written for Arduino but could be adapted to other platforms like the Pi.
In any case, one could combine a small SBC having GPIO such as a Raspberry Pi, the GSASysCon app, and an audio interface in a small case, and then add some external switches and rotary controls connected to GPIO pins to provide tactile user controls. Then you would have an audio device that could function as a preamp, a DSP processor, and so on. Configuration would be done over SSH, and then it could function in a stand-alone mode until further changes were needed or wanted. It would be a cool and flexible computer-driven DIY-DSP project.
Wow, this is an example of why the internet is really great! After a bit of searching around I found a project in the GitHub repository of Andrew Dupont who has already figured out how to do all of this:
https://gist.github.com/savethecloc...c1#using-a-rotary-encoder-as-a-volume-control
Another effort by JamesGKent:
https://github.com/JamesGKent/rotary_volume
On a related note, I am revising my OnOffDelay LADSPA plugin, that is included with GSASysCon, and that allows the user to use the audio stream as a trigger for GPIO pin state changes. The idea is that the GPIO pin would connect to a relay through a driver circuit, and that relay could switch an amplifier or other external equipment on or off when the audio signal falls below some threshold for a period of time, etc. I developed this a few years back when I was trying to build an audio device based on a Raspberry Pi and I need to make a few changes to the code and help file so that it can work with GSASysCon and Gstreamer. I hope to release the new version soon.
- connect a rotary encoder to the GPIO pins of a Raspberry Pi
- read the encoder using a python script
- use the output (direction knob is turning and how far) to adjust an ALSA volume control via amixer
- run the code as a systemd service
https://gist.github.com/savethecloc...c1#using-a-rotary-encoder-as-a-volume-control
Another effort by JamesGKent:
https://github.com/JamesGKent/rotary_volume
On a related note, I am revising my OnOffDelay LADSPA plugin, that is included with GSASysCon, and that allows the user to use the audio stream as a trigger for GPIO pin state changes. The idea is that the GPIO pin would connect to a relay through a driver circuit, and that relay could switch an amplifier or other external equipment on or off when the audio signal falls below some threshold for a period of time, etc. I developed this a few years back when I was trying to build an audio device based on a Raspberry Pi and I need to make a few changes to the code and help file so that it can work with GSASysCon and Gstreamer. I hope to release the new version soon.
I'm currently working on (the code for) a new feature that should make it easier to describe a crossover within GSASysCon's system_configuration file.
Currently, you have to write out all of the required filters for e.g. a LR4 highpass filter. It's just two ACDf filters, but you have to write:
Wouldn't it be easy if you could instead just write a one-liner like this:
That is definitely easier, simpler, and something that more people would recognize. It's sort of like using a "macro" name as a shortcut.
To do this requires the following:
1. A definition of what the LR4 highpass crossover is, in terms of its ACDf filters must be created. This is done via a multi-line variable, which is an existing feature of GSASysCon
2. Within the definition of the crossover, you use the variable "frequency" in place of the actual crossover frequency like this:
3. Behind the scenes, the code I am creating will both replace frequency with the value that is specified in "LR4-HP frequency=2250"
So far so good. But there is a more powerful way to do this, so that the user never needs to write a multi-line variable himself. GSASysCon has the "INSERT FILE" feature. The contents of the file are inserted into the system_configuration file wherever this directive is located. So the multi-line variable(s) that describe the crossover(s) can be put into another file and then inserted. Let's call this the "crossover definitions file" .
I realized that I could create the crossover definitions file myself, populate it with all of the common crossover types and order e.g. Butterworth, Linkwitz-Riley, Linkwitz-Transform, etc. and include it as part of the GSASysCon package. The user only needs to know the "short name" for these crossover types, and the name of the parameter that is used within them for the crossover frequency. This would really lower the barrier for writing a loudspeaker crossover and would also make the system_configuration file much more readable by eliminating all of that boring "ladspa-acdf-so-acdf" stuff! Of course the user can still write the filters explicitly as an ACDf filter, should they wish to do something different from one of the "standard" crossover filter types.
Currently, you have to write out all of the required filters for e.g. a LR4 highpass filter. It's just two ACDf filters, but you have to write:
Code:
ladspa-acdf-so-acdf type=21 fp=600 qp=0.707
ladspa-acdf-so-acdf type=21 fp=600 qp=0.707
Code:
LR4-HP frequency=2250To do this requires the following:
1. A definition of what the LR4 highpass crossover is, in terms of its ACDf filters must be created. This is done via a multi-line variable, which is an existing feature of GSASysCon
2. Within the definition of the crossover, you use the variable "frequency" in place of the actual crossover frequency like this:
Code:
ladspa-acdf-so-acdf type=21 fp=frequency qp=0.707
ladspa-acdf-so-acdf type=21 fp=frequency qp=0.707So far so good. But there is a more powerful way to do this, so that the user never needs to write a multi-line variable himself. GSASysCon has the "INSERT FILE" feature. The contents of the file are inserted into the system_configuration file wherever this directive is located. So the multi-line variable(s) that describe the crossover(s) can be put into another file and then inserted. Let's call this the "crossover definitions file" .
I realized that I could create the crossover definitions file myself, populate it with all of the common crossover types and order e.g. Butterworth, Linkwitz-Riley, Linkwitz-Transform, etc. and include it as part of the GSASysCon package. The user only needs to know the "short name" for these crossover types, and the name of the parameter that is used within them for the crossover frequency. This would really lower the barrier for writing a loudspeaker crossover and would also make the system_configuration file much more readable by eliminating all of that boring "ladspa-acdf-so-acdf" stuff! Of course the user can still write the filters explicitly as an ACDf filter, should they wish to do something different from one of the "standard" crossover filter types.
For anyone who has given GSASysCon a try, I would really appreciate your feedback.
Feel free to PM me or post here. Thanks!
- Were you able to complete the Setup?
- Were the instructions clear or was anything unclear?
- Did you get stuck trying to write your own system configuration file?
- Any typos or errors in the docs you would like to have corrected?
Feel free to PM me or post here. Thanks!
Below is an example of how the new feature of DSP filter "shortcut names" will work. This is an except from the docs that I just wrote today. I am still working on some parts of the filter defs and some related code, so it will still be a few more days before this is available as part of the next GSASysCon release.
A DSP Loudspeaker Crossover that uses Shortcut Filter Names:
------------------------------------------------------------------------------
In this example we will show a simpler way to describe a crossover using the
"shortcut names" of common loudspeaker crossover filters. These are provided
as part of GSASysCon in files located in the filter_defs directory.
The crossover will use Butterworth and LR4 filters and provides an example of
how a TEE can be used.
The file starts with the INCLUDE_FROM_FILE directive. This is described in more
detail in the "GSASysCon Advanced Topics" doc. In brief, it provides access to
some "macro-like" definitions of crossover filters that are easier for the user
to write than the equivalent ACDf filters. More explanation is provided below.
INSERT_FROM_FILE crossover_filter_defs.txt
SYSTEM_INPUT = alsasrc device='hw:CARD=Loopback,DEV=1' ! \
audio/x-raw, rate=44100, format=S32LE, channels=2
CLIENT=LOCAL_PLAYBACK
SINK_FORMAT=S24LE
CLIENT_SINK= alsasink device=default
#global EQ filters:
ROUTE=0,LEFT_INPUT; 1,RIGHT_INPUT
HIGH_SHELF2 CenterF=300 Qfactor=0.6 Decibels=-5
LOW_SHELF2 CenterF=70 Qfactor=0.6 Decibels=3
PARAMETRIC_EQ CenterF=1200 Qfactor=2.2 Decibels=-2
#woofer output on channels 0 and 1
ROUTE=LEFT_INPUT,0,0; RIGHT_INPUT,0,1
DB_GAIN=4
POLARITY=-1
LR4-LP XoverF=450
#midrange output on channels 2 and 3
ROUTE=LEFT_INPUT,0,2; RIGHT_INPUT,0,3
LR4-HP XoverF=450
BUT3-LP XoverF=2750
#tweeter output on channels 4 and 5
ROUTE=LEFT_INPUT,0,4; RIGHT_INPUT,0,5
DB_GAIN=-3.5
BUT3-HP XoverF=2750
The crossover uses a parallel topology, that is to say the input first
passes through the global filters and is then split into three identical copies.
For the 3-way loudspeaker the filters implement an LR4 crossover at 450 Hz and a
3rd order Butterworth crossover at 2.75k Hz. In addition, there are a couple
of global filters that act on the inputs before any crossover filters are
applied.
The "shorcut names" for the filters make reading and writing the file simpler
and more intuitive than with the ACDf filters, however, they will be resolved
into the ACDf filter that are used to build the crossovers when the system
is launched by GSASysCon and the short names are only for convenience. To see
a complete list of the short names that are available, read the filter
definition files located in the filter_defs directory
The global filters implement a named tee. A tee is simply an element that can
act as a source for multiple other routes. The parallel crossover topology uses
three copies of the audio after the global EQ filters (one for each driver) and
we define named tees to show which input channel is which. In GSASysCon a tee is
defined as part of a ROUTE definition that takes only two parameters: the input
to the ROUTE and the string that is the name of the tee. Any non-reserved
alphanumeric string can be used but the first character of the name must be
non-numeric. The TEE is then used just like any other source channel or element
in subsequent ROUTEs. In the example, the tees are conveniently named
LEFT_INPUT and RIGHT_INPUT.
The other GSASysCon feature used in the system_configuration is the co-listing
of ROUTEs that use the same filters. This is done by listing these ROUTEs on
the same line and separated by a semicolon, e.g.:
ROUTE=LEFT_INPUT,0,0; RIGHT_INPUT,0,1
This not only saves space but also prevents errors that might occur if each
ROUTE were written out separately. See the help file "GSASysCon Advanced Topics"
for more information.
A DSP Loudspeaker Crossover that uses Shortcut Filter Names:
------------------------------------------------------------------------------
In this example we will show a simpler way to describe a crossover using the
"shortcut names" of common loudspeaker crossover filters. These are provided
as part of GSASysCon in files located in the filter_defs directory.
The crossover will use Butterworth and LR4 filters and provides an example of
how a TEE can be used.
The file starts with the INCLUDE_FROM_FILE directive. This is described in more
detail in the "GSASysCon Advanced Topics" doc. In brief, it provides access to
some "macro-like" definitions of crossover filters that are easier for the user
to write than the equivalent ACDf filters. More explanation is provided below.
INSERT_FROM_FILE crossover_filter_defs.txt
SYSTEM_INPUT = alsasrc device='hw:CARD=Loopback,DEV=1' ! \
audio/x-raw, rate=44100, format=S32LE, channels=2
CLIENT=LOCAL_PLAYBACK
SINK_FORMAT=S24LE
CLIENT_SINK= alsasink device=default
#global EQ filters:
ROUTE=0,LEFT_INPUT; 1,RIGHT_INPUT
HIGH_SHELF2 CenterF=300 Qfactor=0.6 Decibels=-5
LOW_SHELF2 CenterF=70 Qfactor=0.6 Decibels=3
PARAMETRIC_EQ CenterF=1200 Qfactor=2.2 Decibels=-2
#woofer output on channels 0 and 1
ROUTE=LEFT_INPUT,0,0; RIGHT_INPUT,0,1
DB_GAIN=4
POLARITY=-1
LR4-LP XoverF=450
#midrange output on channels 2 and 3
ROUTE=LEFT_INPUT,0,2; RIGHT_INPUT,0,3
LR4-HP XoverF=450
BUT3-LP XoverF=2750
#tweeter output on channels 4 and 5
ROUTE=LEFT_INPUT,0,4; RIGHT_INPUT,0,5
DB_GAIN=-3.5
BUT3-HP XoverF=2750
The crossover uses a parallel topology, that is to say the input first
passes through the global filters and is then split into three identical copies.
For the 3-way loudspeaker the filters implement an LR4 crossover at 450 Hz and a
3rd order Butterworth crossover at 2.75k Hz. In addition, there are a couple
of global filters that act on the inputs before any crossover filters are
applied.
The "shorcut names" for the filters make reading and writing the file simpler
and more intuitive than with the ACDf filters, however, they will be resolved
into the ACDf filter that are used to build the crossovers when the system
is launched by GSASysCon and the short names are only for convenience. To see
a complete list of the short names that are available, read the filter
definition files located in the filter_defs directory
The global filters implement a named tee. A tee is simply an element that can
act as a source for multiple other routes. The parallel crossover topology uses
three copies of the audio after the global EQ filters (one for each driver) and
we define named tees to show which input channel is which. In GSASysCon a tee is
defined as part of a ROUTE definition that takes only two parameters: the input
to the ROUTE and the string that is the name of the tee. Any non-reserved
alphanumeric string can be used but the first character of the name must be
non-numeric. The TEE is then used just like any other source channel or element
in subsequent ROUTEs. In the example, the tees are conveniently named
LEFT_INPUT and RIGHT_INPUT.
The other GSASysCon feature used in the system_configuration is the co-listing
of ROUTEs that use the same filters. This is done by listing these ROUTEs on
the same line and separated by a semicolon, e.g.:
ROUTE=LEFT_INPUT,0,0; RIGHT_INPUT,0,1
This not only saves space but also prevents errors that might occur if each
ROUTE were written out separately. See the help file "GSASysCon Advanced Topics"
for more information.
Quick update: Today I finished writing the filter definition files. They are split into three separate files:
The next GSASysCon release will have these, an update to the OnOffDelay LADSPA plugin for triggering GPIO pins based on the audio level, and many additions and updates to the docs. Hopefully the release will be available by the end of the weekend.
- Common Loudspeaker Crossovers (Butterworth and Linkwitz-Riley up to 8th order)
- Equalization Filters (1st and 2nd order Shelf Filters, PEQ, Linkwitz Transform, and a "Constant-Slope" filter
- Derived from Elliptic (DFE) Crossover Filters - steep in the frequency domain, well-behaved in the time domain!
The next GSASysCon release will have these, an update to the OnOffDelay LADSPA plugin for triggering GPIO pins based on the audio level, and many additions and updates to the docs. Hopefully the release will be available by the end of the weekend.
The latest update to GSASysCon has been released. The download link can be found in the first post of this thread.
This release includes many updates to the documentation and the GSASysCon app to version 3.14. There is also a new feature called "filter definition files" that define short-cut names that can be used in GSASysCon system configurations to create loudspeaker crossovers with just one macro-like keyword. The the doc file "GSASysCon Advanced Topics" and the files in the directory "system_control/filter_defs" for more info.
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.
This release includes many updates to the documentation and the GSASysCon app to version 3.14. There is also a new feature called "filter definition files" that define short-cut names that can be used in GSASysCon system configurations to create loudspeaker crossovers with just one macro-like keyword. The the doc file "GSASysCon Advanced Topics" and the files in the directory "system_control/filter_defs" for more info.
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.
Member
Joined 2003
I haven't yet gone though this software to see what it can do, but I intent to at some point in the nearish future. One thing I've struggled with in Linux Audio is impulse response convolution. I couldn't for the life of me get it to work as I expected using EasyEffects and ZitaConvolver.
If your software and plugins can handle impulse response convolution that would make my day. I can provide example impulse response files if you'd like to test, but they are simply exported filter transfer functions from VituixCAD, as 32bit-float WAV files.
If your software and plugins can handle impulse response convolution that would make my day. I can provide example impulse response files if you'd like to test, but they are simply exported filter transfer functions from VituixCAD, as 32bit-float WAV files.
Member
Joined 2003
