Go Back   Home > Forums > >
Home Forums Rules Articles diyAudio Store Blogs Gallery Wiki Register Donations FAQ Calendar Search Today's Posts Mark Forums Read

PC Based Computer music servers, crossovers, and equalization

A bash-script-based streaming audio system client controller for gstreamer
A bash-script-based streaming audio system client controller for gstreamer
Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 31st July 2017, 06:35 PM   #61
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
Quote:
Originally Posted by phofman View Post
It works because the gstreamer plugin performs asynchronous reclocking (adding/removing samples
as needed) between the incoming stream timed by the synchronized system clock and the output DAC clock (USB controller clock). Very likely it would work for asynchronous usb dac too (clock by the DAC).
According to a gstreamer reference page on clocks and synchronization that I found:
Quote:
When the pipeline goes to the PLAYING state, it will go over all elements in the pipeline from sink to source and ask each element if they can provide a clock. The last element that can provide a clock will be used as the clock provider in the pipeline. This algorithm prefers a clock from an audio sink in a typical playback pipeline and a clock from source elements in a typical capture pipeline.
I don't typically send data directly to the DAC on systems using multiple clients, but instead route it through a local ALSA loopback. I assume the loopback uses the system clock as its timing reference. I use the loopback to route the audio to ecasound, with which I implement DSP crossover functions. Ecasound send its output directly to the DAC(s). This is typical of systems where left and right speakers are separate gstreamer clients.

I do have a system consisting of one client only where I just send the gstreamer output to a single stereo DAC (that uses USB adaptive mode), but I can't carefully compare its synchrony to other systems and within the system synchrony is a non-issue because there is only one client and one DAC.

Anyway, I would like to know about all of this on a more intimate level, so thanks for bringing up the topic. Let's keep up the discussion.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 23rd December 2017, 02:53 AM   #62
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
Six months down the road from the last post in this thread, and I am working on some more "features" to add to this package.

In the last post, above, I mention that on clients in the system gstreamer is receiving the streaming audio and then passing it to an ALSA loopback so that another program (e.g. ecasound) can use it as input. Ecasound is used to implement a DSP crossover (in software) before passing the audio out via the DAC(s). Ecasound uses LADSPA filter plugins that I wrote to do all the filtering, and provides routing functions for splitting the input audio into the different bands that are then filtered.

What has been a challenge is to get the clock that controls the ALSA loopback to run at the same speed as the source clock. I have been using NTP for this purpose, and even built a stratum 1 (GPS based) time server using a Raspberry Pi 3 that helps to keep all my linux boxes in very tight sync (jitter is under 50usec ). But I recently discovered (thanks Phofman!) that gstreamer can support LADSPA plug-ins. I had known that gstreamer came with a couple very simple ones, but I did not know that any and all LADSPA plugins that are registered to the O/S are available to gstreamer. Gstreamer sort of "repackages" each plugin, giving it a new gstreamer-specific name, and assigning names to each parameter.

After a lot of experimentation, I finally figured out how to create the same crossover functionality under gstreamer that I have been doing with ecasound. This means that I do not need to pass the audio via a loopback, instead I can implement the DSP crossover right within gstreamer itself, and gstreamer can send the audio to the DAC(s) directly. Because timing information will be managed completely within gstreamer, this may eliminate the need for NTP (or at least I hope so).

So far I have tested out a skeleton of a DSP crossover. By "tested out" I mean I have routed and processed the audio using LADSPA plugins and gstreamer seems to work (e.g. not crash). I have not yet been able to implement a real crossover on a loudspeaker and/or do any testing to make sure that the LADSPA filters are working properly, timing is correct between channels, etc. I am nonetheless very encouraged at this stage.

I have been thinking about how the user can describe the crossover system within GSASysCon (the existing program I wrote) without too much additional work. Initially I thought that I could create a crossover meta-language that could be read in as a config file and then translated into the appropriate gstreamer commands. But after thinking about it, the user would probably be just as well served if I gave a good overview on how to write the gstreamer (gst-launch) commands and then let the user write the pipeline themself. Then I can just insert the user's gstreamer pipeline from the config file directly info the pipeline that GSASysCon already builds as part of the streaming audio chain. The complexity of gst-launch will be about the same as whatever meta-stuff I come up with, and I won't need to write an entire interpreter for it!

A side bonus of implementing everything using gstreamer is that all the code and config files can be located on the server, and nothing on the client. This helps to simplify setup, and allows swapping out client hardware without a lot of re-configuration.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 20th January 2018, 11:24 PM   #63
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
A couple weeks later...

I started planning the recoding, and doing some more testing. I have local playback working now (actually, it was always possible).

Next up is extending the input format to an arbitrary number of channels so that it would be capable of handling e.g. surround sound system audio. I have that planned out. Just need to start coding the changes.

After that I will be implementing the crossover functionality. For now this will be on the client side only (seems to make sense, right?). The user will need to write gstreamer code and implement LADSPA plugins, but I have figured out how to do this and it is not too complicated to explain to others. The user gstreamer elements will just be inserted into the client pipeline directly, which allows for a lot of freedom to do whatever is desired. At the same time I will release a slightly modified version of my LADSPA plugins that has more succinct control names so that instead of having to write filter_pole_frequency-in-hertz=250 you can just write Fp=250. Since you need to specify multiple control values for each LADSPA plugin, keeping the control names short helps to make the code readable.

Finally, just today the issue of INPUT SWITCHING came up. Currently GSASysCon continually monitors ONE input, which is a bit limiting although you could mix multiple inputs at this input. It is certainly possible to have another application feeding the lone GSASysCon input that would perform input switching for GSASysCon by connecting and disconnecting other inputs to the GSASysCon input. This is probably best be written as a separate application that also uses gstreamer, but does not necessarily need to be integrated into the current code. I will be giving the design of this "input switching" code some thought over the next few days and see what I come up with.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins

Last edited by CharlieLaub; 20th January 2018 at 11:27 PM.
  Reply With Quote
Old 21st January 2018, 11:31 PM   #64
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
Working on allowing for an aribtrary number of inputs channels... the motivation is to allow the input to be some kind of multichannel surround sound.

The question then is how to allow the user to specify the formula for mixing audio channels. I think I have a solution to this, which would be to allow operations within the following format:
output_channel = SUM{ scalar*input_ch1, scalar*input_ch2, ..., scalar*input_chN }
where scalar is a float value that can be positive or negative.

Then a downmix of 5 channel audio (Lfront,Rfront,Center,Lrear,Rrear) can be accomplished via an equation like this:
DOWNMIXED_LEFT = L + 0.707*C + 0.5*L_surround
is achieved by writing for the output channel:
input_ch0+0.707*input_ch2+0.5*input_ch3

Using the same formalism, it would be possible to UPMIX. For example given LEFT, RIGHT input channels input_ch0 and input_ch1:
(L-R) would be written as: input_ch0-input_ch1
(L+R) would be written as: input_ch0+input_ch1
(R-L) would be written as: input_ch1-input_ch0
This is one version of Gerzon's "trinaural" reproduction formulas.

This type of user-directed system-specific input mixing permits playback on loudspeaker systems with a range of playback channels no matter how many channels are present in the audio input. The configuration file for each playback system specifies how the N input channels are mixed up/down and sent on to the loudspeaker system connected to the M-channel playback client. In this way a movie in 5.1 surround can be played in the TV room in 5.1 surround, in another room as 2-channel audio thru stereo loudspeakers, and somewhere else in the home in mono from a wall or ceiling speaker.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 24th January 2018, 03:34 AM   #65
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
After some planning I had the chance to code this up today. Works great!

I managed to simplify how the user must declare the output channels, upmixing, and downmixing equations, etc. The user supplies a list of input channels in the order they should appear in the output. Simple expressions for mixing channels are also possible with this formalism.

Given that the channel numbering starts with channel 0, we have:
stereo = "0 1"
left = "0"
mix stereo to mono = "0+1"
downmix 7.1 to stereo = "0+0.7*2+0.5*4 1+0.7*3_0.5*5"
In the above, the equations for mixing are formed by connecting expressions of the form "scalar*channel_id" via a "+" or "-". So "0+0.7*2+0.5*4" means:
output channel#0 should be created by summing input_channel#0, 0.7 times input_channel#2, and 0.5 times input_channel#4.
Rules: The scalar must always appear to the left of the "*". Since the channel list is space delimited, no spaces are allowed within a mixing expression.

I can pretty much handle anything this way! Nice.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 30th January 2018, 07:17 PM   #66
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
After thinking more how this can be a "whole house" streaming solution I realized that I needed to integrate some kind of volume control into the interface.

I turned to experience I gained on a previous project:
Linux USB Preamp project

The idea is to create a new ALSA device that feeds into the loopback that is in turn feeding GSASysCon. Software should send audio to this new device instead of directly to the loopback. I found that something like this in my ASLA config file (~/.asoundrc) worked pretty well:
Code:
pcm.GSASysConInput {
   type   softvol
   slave {
      pcm   "CARD=Loopback,DEV=0"   #send the output of this device to the slave device
   }
   control {
      name   GSASysConVol    #new control name, or name of existing control to override
      card   Loopback        #can use card name or number
   }
   min_dB -40.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
   #   NOTE - for muting use a control with resolution=2 
   resolution 101  #resolution=101 ensures that each 1% step will actually result in a volume change
}
To manipulate this new "volume control" I will add some code in GSASysCon that uses amixer to change the control level. This is the same approach that I used in my Linux USB Preamp project. The general UI will be something like this (below), a "bar graph" rendered using text, e.g.:
Code:
VOL #|||||||||||||||||||||||||                          # [55]
The above is supposed to look like a volume control slider, with the setting (in percent) in square brackets at right. When the user presses v or V the volume control mode is entered and the slider graphic is displayed. By pressing +/- or the keys u/U or d/D the volume can be made to increase or decrease and the slider will be re-rendered to reflect the new level. After some preset time the display will revert back to the usual playback client list. I could also implement muting in this way via m/M keys.

One motivation behind this functionality is so that I (or the user) can use a CD player connected as a source via a SPDIF-->USB dongle, for which there is no volume control. This would skip D-to-A and A-to-D conversion (e.g. if the analog output of the CD player was used instead). Any source that lacks a volume control is a good candidate for this control.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 30th January 2018, 08:17 PM   #67
cacao ambiance is offline cacao ambiance  United Kingdom
diyAudio Member
 
Join Date: Oct 2015
reading your prev linux usb preamp project, i was wondering if you would be ever interested in making a hard ware product for gnu/linux DSP?

I could imagine such a hardware product being achieved, more cheaply, easily using this free software & hardware projects computer card spec:
website wiki, lots of info, try the site map: Rhombus-Tech
tons of info in updates and a intro: Earth-friendly EOMA68 Computing Devices | Crowd Supply
mailing list, tons of info: arm-netbook Info Page

the brains are in a standard factor. so for a gear maker this would mean, no MOQ for socs, software support, not designing ones product around a SBC which change all the time and go obsolete/unspotted quickly.
Instead the gear maker gets to focus on the functions of there gear.

so DAC, Power supply, arduino like chip for lots of diff control options, screen and designing a box to fit it all in. they can make a more simple PCB as less layers = cheaper pcb cus the pcb cpu, ram layers is done in the computer card.

in one of the existing housings aka devices being made, the laptop. A arduinio like chip is already used to do lots of things.

when the soc of a computer card is EOL,etc. The maker can still make the same DSP product and just provided a different, newer computer card with it.

options of more powerful cpu for more fancy filters or cheaper less powerful cpu card for basic dsp at less cost for the user.

Yea im keen about this eoma68 project . I would fancy pledging money for a ready made free software DSP using eoma68

sorry, i guess your just interested in developing the software music servers, crossovers, and equalization etc. Which is great , I just can’t help my self at the excitement of thought of a free software DSP.
  Reply With Quote
Old 30th January 2018, 09:40 PM   #68
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
Quote:
Originally Posted by cacao ambiance View Post
reading your prev linux usb preamp project, i was wondering if you would be ever interested in making a hard ware product for gnu/linux DSP?
As you have guessed I am more of a software person. I find all the hardware capabilities that I could ever need in inexpensive single board computers and the like. I don't think that there is a need for dedicated hardware per se. You can buy a decent DAC for not much money. It just plugs in a does its job. The fun for me is in developing software to do new things when I cannot buy and customize something to my satisfaction.

If you look around this web site you will find there are other people who have developed or are developing projects along the line of what you are (likely) envisioning.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 4th February 2018, 01:40 AM   #69
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
Reporting on some progress:

The server-side channel routing/mixing is working. I am experiencing some issues with gstreamer, and am trying to get more info on that, but it is looking like it will more or less work as advertised.

The client-side ladspa for filtering/crossover/DSP is currently not working. It has been coded up, but I need to find out why the pipeline isn't playing correctly. I plan to test this out in more detail tomorrow. I had tested a couple of pipelines that included ladspa filters a few weeks back but evidently not with a sufficiently detailed amount of debug information. At the time it looked like there were no errors and everything was working. Now I can see that the pipeline sets up without errors but then goes into a PAUSE mode, so it doesn't produce any audio. Not very useful!

The volume control is working, but I am still deciding how to implement the control functionality itself in GSASysCon. I might start out having only a numerical readout and no "bar graph" to keep it simple.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 5th February 2018, 03:12 AM   #70
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
UPDATE:

After a long day of trial and error I seem to have figured out how to get the LADSPA plugins working. This really great news, because this allows GSASysCon to be a DSP crossover platform that can replace ecasound. It should prove to be an improvement over ecasound in several ways.

I will continue to experiment with gstreamer pipelines and ladspa plugins over the next few days to make sure I have all of this figured out and coded up properly within GSASysCon.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote

Reply


A bash-script-based streaming audio system client controller for gstreamerHide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
New BeagleBone based Audio System dogrocket Vendor's Bazaar 3 1st April 2016 04:02 AM
XMOS audio streaming controller GB interest heartwinter Group Buys 12 13th July 2015 04:30 PM
USB streaming controller arjunm009 Digital Line Level 2 12th May 2015 04:38 AM
First audio project, Wall controller for room audio system, looking for guidance, Chrisdvip Construction Tips 2 10th June 2013 05:47 AM
Audio System Controller happyboy Analog Line Level 9 12th September 2012 09:12 AM


New To Site? Need Help?

All times are GMT. The time now is 04:52 PM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2018 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 15.00%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2018 DragonByte Technologies Ltd.
Copyright ©1999-2018 diyAudio
Wiki