LADSPA plugin programming for Linux audio crossovers

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
I've recently become interested in trying to put together a Linux based computer for processing audio into different streams - a PC crossover.

This is a new direction for me, moving away from the DSP hardware solutions that I have been using for the last few years, but I have some experience in C/C++ programming and have found a few examples on the web of what is possible and these are very encouraging. I have an idea for a new way to PC based loudspeaker crossovers using my Active Crossover Designer tools (ACD).

I have discovered the LADSPA plugins that will, for instance, execute one of a number of filter blocks on a stream of digital data, for example a second order Butterworth highpass filter. This is way too specific of a filter implementation. I have been working with IIR DSP for awhile now and I'm quite familiar with IIR biquad coefficients. My crossover software, ACD, calculates the IIR biquad coefficients from more familiar filter descriptors and makes them available to the user. What I am looking to create is a new plugin that takes the biquad coefficients as input directly. The code for the plugins that I have looked just calculates the coefficients from other parameters, like the type of filter (second order high pass Butterworth) and one or more parameters (filter corner frequency and gain). My "generalized biquad" plugin would simply take the five (normalized form) coefficients as parameters and then would use them directly. These are the same five parameters that miniDSP uses, with a few sign changes, so miniDSP biquads could be imported as well.

Once this new plugin has been created, the doors are open to implementing a complete crossover in Linux using an approach like what is done here:
Digital Crossover/EQ with Open-Source Software: HOWTO | Richard's Stuff
Richard Taylor's efforts have paved the way, but his plugin set is very limited. Using the same approach, but with a generalized-biquad plugin that can implement any first or second order filter, would make Linux audio better suited for loudspeaker crossovers.

I'd like to chat privately with someone who has worked with LADSPA before, as well as ecasound, about some practical aspects of my approach. If that's you, please drop me a line.

Otherwise, I will try to post my progress here from time to time. I'd love to hear people's thoughts on all of this as well.
 
Last edited:
Member
Joined 2011
Paid Member
Sounds like a very worthwhile project.

Some things that I would focus on (if I had the skills to attempt such a project):

- Efficiency - If it can run on an RPi, it will be a big hit.

- Documentation - Not everyone is a genius; unless it is really dead simple to install and use, the documentation will be critical to its success.

- Interface - Not everyone can work with or understand biquads. The option of using a GUI at least similar to that of miniDSP would be a huge bonus.

- Multi-device output - The ability of the plugin to be configured to use 2 or more USB DACs as output devices would be absolutely freakin' awesome.

If attention is payed to these factors, I'd be very likely to willingly pay a decent sum of money for such a plugin. I suspect *many* others would feel the same way.
 
Last edited:
Multi-device output - either the interfaces run synchronously, then you can easily use alsa pcm_multi plugin for creating virtual multichannel device. Or the interfaces are asynchronous (separate clocks) and you have to apply adaptive resampling http://lac.linuxaudio.org/2012/download/adaptive-resampling-slides.pdf just like e.g. pulseaudio or jack plugins do.

GUI support - some people like coding the GUI, some people prefer digging deep into the actual internal functionality. IME the two groups are mostly exclusive. Writing a great CLI/library tool with someone else coding the GUI calling the CLI/library functions is a way to go.
 
Sounds like a very worthwhile project.

Some things that I would focus on (if I had the skills to attempt such a project):

- Efficiency - If it can run on an RPi, it will be a big hit.

- Documentation - Not everyone is a genius; unless it is really dead simple to install and use, the documentation will be critical to its success.

- Interface - Not everyone can work with or understand biquads. The option of using a GUI at least similar to that of miniDSP would be a huge bonus.

- Multi-device output - The ability of the plugin to be configured to use 2 or more USB DACs as output devices would be absolutely freakin' awesome.

If attention is payed to these factors, I'd be very likely to willingly pay a decent sum of money for such a plugin. I suspect *many* others would feel the same way.

From what I have read about similar efforts you can implement a crossover on a Raspberry Pi. That is where I plan to experiment, initially at least. With the new Pi 2 out, there should be a little more computing power on tap.

As far as a simple and easy to use GUI - this isn't in my core competencies. If someone wants to work with me to implement a GUI control to set up and change the crossover settings they are welcome to contact me. Anyway I think the R-Pi would not be able to run both the crossover code and the GUI desktop at the same time anyway. My idea was to have text configuration files and run the Pi headless. It would become ready to process audio on boot up.

As far as multi-channel output, I don't think that multiple output devices is advised. These will never be well sync'd. Instead I hope to use the HDMI audio outputs and connect an audio extractor board to the Pi's output.

As you can tell, I am planning to try this on the Pi. But this should all work on hardware running Linux that is at least as, or more, powerful than the Pi (which is most everything else!). Like a small mini-PC running Linux. IF you are only running a crossover, that would be overkill.
 
I have now done some coding based on Richard Taylor's work, adding routines to implement an IIR digital filter of first or second order when the transfer function coefficients are supplied by the user directly. This is the kind of low-level filter programming that miniDSP offers with its "advanced biquad programming" feature. Although such a filter would only work for digital audio in the sample rate for which the coefficients were calculated, the filter response is more flexible. For instance I can implement a filter with "optimized coefficients" like I discuss here:
http://www.diyaudio.com/forums/digital-line-level/257313-biquad-optimizer-iir-digital-filters.html

Richard Taylor already coded a few filters that he used to implement the particular crossover he was working with. These include:
  • 2nd order highpass
  • 2nd order lowpass
  • 2nd order allpass
  • 1st order allpass
  • 2nd order high shelf
  • 2nd order low shelf
  • parametric EQ

This is a nice start, but you can't implement (for instance) a 3rd order crossover or a Cauer/Elliptical filter with only these filters.

To make the set of filters more complete for crossover work, I will add the following:
  • 1st order highpass
  • 1st order lowpass
  • 1st order shelf
  • biquadratic filter (e.g. for Linkwitz Transform)
  • 2nd order notch filter (including HP-notch and LP-notch forms)

With those filters added to the mix, it's essentially the same filters that are used in my Active Crossover Designer tools. The user could design the crossover using ACD and then implement is using the LADSPA plugins in software on a computer.
 
Anyway I think the R-Pi would not be able to run both the crossover code and the GUI desktop at the same time anyway. My idea was to have text configuration files and run the Pi headless. It would become ready to process audio on boot up.

I think in better to think the GUI as a web service, as almost all linux audio distributions use it for direct remote control or maybe a client library is the way to go as it leaves GUI developers to choose whatever they prefer (native X, web, MS/OSX or even mobile apps apple or android). Look how mpd cilent is used to control the server.

How do you see input and output?

Like mpd and sox/brutefir? player -> pipe -> crossover -> alsa or as a module for jack or alsa?
 
I have been following the R Taylor's apprach as well which lead me down to read a lot about Linux audio and some of the good technical info provided by phofman and others. I havent fully got it to work because I have been searching for a global solution regardless of software program used (not just the mpd piping) - in other words, how to intersect all streams going via alsa (stdin?) and apply the ladspa filters via ecasound or other solutions. Interested to follow your progress.
 

Huh?

I still have not seen anything that comprises all the filters that you could possibly use for a loudspeaker crossover. That is why I am developing my own plugin. Usage will be LADSPA_plugin >> ecasound filter chain >> ALSA interface. ALSA will interface with the player/streaming client on the local machine.

Most of this is pretty well spelled out in Richard Taylors web pages.
 
I have been following the R Taylor's apprach as well which lead me down to read a lot about Linux audio and some of the good technical info provided by phofman and others. I havent fully got it to work because I have been searching for a global solution regardless of software program used (not just the mpd piping) - in other words, how to intersect all streams going via alsa (stdin?) and apply the ladspa filters via ecasound or other solutions. Interested to follow your progress.

Have you looked into JACK? This seems to be that kind of tool. See:
JACK Audio Connection Kit|Home
 
I spent some time coding today and things are coming into focus. I have decided on a slightly different approach: instead of adding on to Richard Taylor's existing filters I am implementing my own complete set of first and second order filters using the math from my ACD tools. All the filters are implemented via a single plugin. An input parameter called "filter_type" indicates the desired filter and, combined with the other parameters of the filter that are supplied to the plugin, the code implements the IIR filter transfer function. This really makes coding much easier for me. Documentation will describe usage.
 
I have all the filter calculations coded up now and I am currently testing them against known values. So far so good! See attached example.
 

Attachments

  • LADSPA_filters_testing.PNG
    LADSPA_filters_testing.PNG
    10.4 KB · Views: 664
After about 6 hours of testing and debugging I now have working code that calculates the IIR transfer function coefficients for the following filters:
  • gain block
  • 1st order lowpass
  • 1st order highpass
  • 1st order all-pass
  • 1st low shelf
  • 1st high shelf
  • 2nd order low-pass
  • 2nd order high-pass
  • 2nd order all-pass
  • 2nd order notch, highpass notch, lowpass notch
  • biquadratic filter
  • parametric EQ, digital form
  • parametric EQ, analog form
  • 2nd order low shelf
  • 2nd order high shelf
The format for these is based on the filter table used in my Active Crossover Designer tools.

Next steps: integrate the calcs into the plugin framework.
 
I am also interested in the answer to this question since the Pi is an affordable computing platform. There seems to be good evidence that the Pi 2 would work for 6 or 8 mono channels. It would probably depend on what else the PI is doing (e.g. resampling the audio? running the desktop GUI? serving as a stream player? etc.) and how many filters are needed for the crossover.
 
Just wanted to share some thoughts on the Raspberry Pi...

I have previously had only limited exposure to Linux systems, under both command line and desktop GUI interfaces. No prior experience with the R-Pi, but after some reading up on it I recently decided that this was the way for my to implement a software crossover, or at least an inexpensive platform that I can use to experiment with Linux audio tools like LADSPA.

Today I finally decided to fire up an R-Pi (the 2 version). I bought it with an 8GB NOOBS card for around $40. I plugged in the card, connected USB keyboard and mouse, HDMI monitor, wired ethernet, and a 5V power supply that I already had around. The Pi booted up to the command line in about 20 seconds, after which I could start the desktop. A browser came along wiht the OS, and I could immediately pull up websites. My next step was to install the excellent VLC player. I had to update the OS first, but that took all of 30 seconds. I proceeded to install VLC. Again it was painless. Currently I am listening to a 320k audio stream while I type this. The CPU usage is hovering at around 5-6%. So all of this would seem to be encouraging signs that audio processing will be possible using LADSPA.

By the way, I noticed that JACK is now bundled with the OS. When I chose HDMI as the output device I could set the number of output channels to 8 (actually more). With all the HDMI audio problems that have been reported, I will believe that I can output on more than 2 channels when I actually get it working. I have an audio extractor on order, so I may be able to test this out in the next couple of weeks.
 
Just wanted to share some thoughts on the Raspberry Pi...

I have previously had only limited exposure to Linux systems, under both command line and desktop GUI interfaces. No prior experience with the R-Pi, but after some reading up on it I recently decided that this was the way for my to implement a software crossover, or at least an inexpensive platform that I can use to experiment with Linux audio tools like LADSPA.

{snip!}

By the way, I noticed that JACK is now bundled with the OS. When I chose HDMI as the output device I could set the number of output channels to 8 (actually more). With all the HDMI audio problems that have been reported, I will believe that I can output on more than 2 channels when I actually get it working. I have an audio extractor on order, so I may be able to test this out in the next couple of weeks.

Charlie -

Watching your work with great interest - have used the Pi boards as S/PDIF music sources for some time now, with the HiFiBerry Digi and Digi+ adapters from Switzerland:

https://www.hifiberry.com/digiplus/

which have worked surprisingly well as headless music streamers feeding a MiniDSP NanoDIGI which provides the 2.1 crossover for our primary system

I was quite stoked to see the Pi quad-core boards released at an affordable price, grabbed one from Newark's first batch, and have had very good results from it ever since.

I've an argument with using HDMI output that isn't functional (HDMI on the Pi does appear to be less glitchy than either its USB or PWM/analog outputs), but is more a conceptual irritation - it just bites me to spend a fair amount of time & effort to massage a digital data stream to have exactly the shape and content that suits me, only to feed it to a consumer-grade DAC in a HDMI=> Analog Box of Unknown Origin.

Yeah, this <could> work well, but there's just not the same richness of back-end choices as there are with more conventional DACs.

Heck, the blessed Pi is such an inherently cheap platform, that I wonder if a distributed system using a Pi/DAC combination at each speaker fed from 100Mb ethernet might not be both cost effective and very listenable.

Obviously, synchronization between the 2 ...N channels will be a non-trivial issue, but it looks like there are aleady several approaches to managing this problem:

A rather brute-force low-level approach with the clock signalling inserted into the ethernet packet headers:
Synchronous Ethernet - Wikipedia, the free encyclopedia

And a bunch of protocols developed for the Pro Sound world here:
Audio over Ethernet - Wikipedia, the free encyclopedia

But [SIGH!] it looks like the bandwidth of AOE (Audio Over Ethernet) is shockingly high because of the topologies requirements for maximum redundancy and 'hardening' for use in commercial venues.

Still, it would be interesting to have multiple Raspberry Pi's sharing a common audio network (perhaps running the AES/EBU protocol layer on a cheap S/PDIF hardware layer?) - there's something very appealing in the idea of $100 computer+DAC+crossover device sitting behind powered speakers for all the channels of a home theater.

"But I digress" ... (I Leonardo - Ralph Steadman )

Cheers

Jim
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.