A bash-script-based streaming audio system client controller for gstreamer

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Here is a test of ALSAINFO on the Presonus 1818VSL, a pro-audio soundcard. I have removed the Asus Xonar and connected the Presonus, which now is listed as card 2 under ALSA (as shown by running aplay -l).

Starting with the most basic usage we enter:
Code:
./ALSAINFO.sh hw:2,0

The output is:
Code:
testing ALSA device: hw:2,0
using the default sample rate of 44100 Hz
using the default audio format of S16LE


WARNING: the audio format was changed to: S32L
This device will accept 18 channels of S32L audio data
The bitmask for this mode is: 0x0000000000000000
   This device does not use channel assignments.
   All output channels should have their bitmask set to -3 (NONE)

The above message shows that GStreamer automagistically switched the audio format to S32LE (from the requested format of S16LE) and determined that the device can support 18 output channels. There are no channel assignments for the Presonus but instead audio is sent to outputs by order-of-appearance in the set of output channels. All channels should be assigned the "channel number" of -3, meaning "not assigned". This "non assignment" of channels seems common in multichannel pro-audio audio interfaces that I have tested.

Some info on the soundcard (but not the channel assignments!) can be found by looking at files under /proc/asound for the audio card in question. For example by typing:
Code:
cat /proc/asound/card2/stream0
I get the following output:
Code:
Presonus AudioBox 1818 VSL at usb-0000:00:14.0-1.3, high speed : USB Audio

Playback:
  Status: Stop
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 18
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000
    Data packet interval: 125 us
  Interface 1
    Altset 2
    Format: S32_LE
    Channels: 14
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000
    Data packet interval: 125 us

Capture:
  Status: Stop
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 18
    Endpoint: 2 IN (ASYNC)
    Rates: 44100, 48000, 88200, 96000
    Data packet interval: 125 us
  Interface 2
    Altset 2
    Format: S32_LE
    Channels: 14
    Endpoint: 2 IN (ASYNC)
    Rates: 44100, 48000, 88200, 96000
    Data packet interval: 125 us

This provides is another way to find helpful info on the capabilities of your audio device(s). Here we can see for the Presonus that it will only support the S32LE audio format and sample rates of 44100, 48000, 88200, 96000 Hertz.
 
The code is shaping up nicely, and I am almost done with the re-writes. I have done some testing and debugging. I like how the volume control is working. For instance I have been able to fix that ALSA-PulseAudio bug where when you mute a control (e.g. Front audio output) it mutes other controls (like the Master audio output) but when you then unmute "Front" the "Master" remains muted and the sound doesn't come back on. I came up with a solution for this as part of the volume control code.
Documentation is coming along slowly.... in the meantime I have been working on the way the user can declare ALSA controls to manipulate via GSASysCon's volume control interface.

Like I alluded in an earlier comment quoted above, sometimes ALSA does odd things with controls when you mute one of them. This is because some controls are linked. But sometimes there are no controls at all, so you have to create them using softvol. Unfortunately I could not find a way to create a single ALSA softvol control that both changes volume and has muting capability. So I had to make two controls, one for volume and one for muting. Here is my .asoundrc file that creates these two controls for a Behringer FCA610 USB soundcard, for which ALSA did not show any volume or muting controls:
Code:
pcm.FCA610volume {
   type softvol
   slave.pcm "hw:CARD=FCA610,DEV=0"   #send the output of this device to the slave device
   control.name "Master Capture Volume"    #new control name, or name of existing control to override
   control.card "FCA610"    #can use card name or number
   min_dB -60.0    # Minimum dB when slider is at 1% (0% is muted)
   max_dB 10.0     # Maximum DB when slider is at 100%, >0dB is a boost of the signal
                   # These result in the default control value (80%) having a level of 0dB (unchanged)
   # Resolution: number of levels the control is able to take on, including the 0% and 100% endpoints
   resolution 101  #NOTE: resolution=101 ensures that each 1% step will actually result in a volume change
}

pcm.FCA610mute {
   type softvol
   slave.pcm "hw:CARD=FCA610,DEV=0"   #send the output of this device to the slave device
   control.name "Mute"    #new control name, or name of existing control to override
   control.card "FCA610"    #can use card name or number
   # Resolution: number of levels the control is able to take on, including the 0% and 100% endpoints
   resolution 2  #NOTE: resolution=2 creates a muting control with no volume adjustment capability
}

Even though both of these are "volume" controls they cannot be used in the same way. What is needed is a way to tell GSASysCon to manipulate only the Mute control when the user wants to mute and only the Master control when the user wants to adjust volume.

With some new code I wrote over the weekend, that is now possible. There is a new syntax to the way that volume controls are defined:
Code:
VOLUME_CONTROLS = card>control>action
Card is the card number
Control is the control name
Action consists of a single-character plus one of mute, unmute, muting, or volume. The single character is either "!" (not) or "%" (only).

Here we want to tell GSASysCon to only use the Master control for volume and only use the Mute control for muting (either a mute or unmute). So you write:
Code:
VOLUME_CONTROLS = 1>Master>%volume;1>Mute>%muting
These softvol controls now provide muting and fine volume adjustment for the soundcard. This was necessary because I am using the SPDIF input to the FCA610, so the source will always be at full volume and needs to be attenuated.

This should allow the volume and muting functionality in GSASysCon to be used with soundcards that don't have native ALSA controls.
 
Just a note here to say that GSASysCon supports pulseaudio for source and sink. There is another thread about a "crossover rack" that was developed to implement LADSPA plugins under pulse audio. GSASysCon can do the same thing, and has other features that may be of interest. Well, that is if I ever get around to releasing it. The code is done, but I am just not finding the motivation to write more documentation, and since GSASysCon can do a lot of stuff there is a lot to write. But if anyone wants to try it out, drop me a PM and I will personally walk you through it. That might also help me to understand how a new user feels about the system, getting it set up, etc.
 
This thread has gone a little stale, but I have continued to work on the code now and then behind the scenes. I thought I would pop a little note here that I hope to find some time to work on the documentation that is needed for a new user to get up and running so that I can release the code. It's now up to rev 2.11.

I've made some improvements when using pulse audio as a source, with routing, cloning routes, and with the volume control functionality.

Until recently I advised that audio should come via the ALSA loopback, but now see that pulse audio has a "monitor" function that is similar and system sounds from applications and internet browsers all default to pulse. At the same time I found some info on how to modify pulse to use the Soxr "very high quality" resampler and to set the bit depth and sample rate used. This provides better control of the audio quality through pulse, which I originally thought had to be done by the source application itself.

I have also expanded the capabilities of the volume control functions so that multiple local ALSA controls can be manipulated simultaneously and muting/unmuting works even in strange cases for which unmute typically fails. The GSASysCon interface's volume control is also part of the remote text based control, so you can do all of this from your armchair while listening using any kind of portable device e.g. smartphone, tablet, etc.

At the same time, GSASysCon still works well as a controller for a LAN-wide streaming audio playback system. By this I mean PCM (uncompressed) audio is routed through GSASysCon and then out over your LAN (wireless or wired both work well) to another "client" computer (e.g. Raspberry Pi or other linux box) that implements the crossover and sends audio via its DACs to amps and loudspeakers. There are lots of interesting distributed audio schemes that can be implemented using this approach.

Finally, I want to stress that there is very good integration of DSP via LADSPA into GSASysCon. Even if you only want to implement an IIR DSP crossover under linux, GSASysCon and my ACDf LADSPA plugin will do pretty much everything you need.
 
I will soon be releasing a new version of my LADSPA plugins, "ACDf". Most of the changes will not have any impact on users of the current version. These include changing or creating default values for each parameter and modifying the parameter names (but not their order). If you are using ecasound with ACDf and update to the new version (version 3.0) you should not experience any changes.

These changes have made it easier to use ACDf filters under Gstreamer and my GSASysCon app. In the past I had used some long and descriptive parameter names and these have to be explicitly named under Gstreamer instead of just presenting the values in order like you do under ecasound. Gstreamer is now my preferred LADSPA host because it is much more versatile, and I have built my GSASysCon helper app around it.

At the same time I will be releasing an update of ACD-L, the Active Crossover Designer tools for LADSPA plugins. I discovered that the second order shelving filters were not being modeled correctly in ACD-L. This motivated me to completely re-code how the filters were being calculated. Now the calculations are done exactly as they are in the LADSPA plugin. I have made a few other minor modifications, but ACD-L remains a great tool for loudspeaker crossover design based on measurement data and can model the loudspeaker response on multiple axes simultaneously while the crossover is being developed.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.