LADSPA filters for digital crossovers on the BBB

[hopkins]

In your 'squeezelite...' command you can use '-o default'. No need for the 'plug:' prefix.

That is how I have it.

 

[francolargo]

That is how I have it.

 

[hopkins]

Hi again... I have tried using ACDf filters but get a "segmentation fault" error. This seems to be due to problem in compilation of the plugin ? I do not get any errors when making the plugin, however. Any suggestions ?

 

[francolargo]

Greetings! It's unfortunate that you get segmentation fault errors. I use the versions of Debian that are 'approved' for the Beaglebone. When I first tried the ACDf filters with Debian 7.5 I also got seg faults. Only when I upgraded the system to version 8 did the ACDf package run correctly. I do not know which particular component of Debian 7.5 is incompatible.

Good luck!

 

[hopkins]

Greetings! It's unfortunate that you get segmentation fault errors. I use the versions of Debian that are 'approved' for the Beaglebone. When I first tried the ACDf filters with Debian 7.5 I also got seg faults. Only when I upgraded the system to version 8 did the ACDf package run correctly. I do not know which particular component of Debian 7.5 is incompatible.

Good luck!

I will try the last version of voyage linux, which runs debian 8.

 

[hopkins]

I will try the last version of voyage linux, which runs debian 8.

Works with voyage linux

 

[Jerms]

I just subscribed to this topic as it seems I've missed a few posts.

A few commands I have found useful.
aplay -l
aplay -L
amixer controls
amixer scontrol

J.

 

[triodehunter]

i2s-lines delayed

Hello Frank,

thank You for Your kind offer to help me in this thread. Your help is appreciated very much. Just to repeat my question of the Botic-support thread:

"I managed to get my system working. BBB > Botic5 > Hermes > Cronus > DDDac. I am using external clocks (The Well Tempered Master Clock - Building a low phase noise/jitter crystal oscillator). The system works flawless.

As I am using a multichannel all-horn-system, delay lines are essential.

My question is whether I can use three of that four i2s-lines delayed by Botic OS. If that is possible basically, I think the real challenge might be to tell the system the needed delay in msec respectivly fractions of msec valid for all possible sample rates.

I am not interested in digital crossovers whatsoever. So there is no need for that. The signal should not be modified in any way, just delayed."

http://www.diyaudio.com/forums/twisted-pear/258254-support-botic-linux-driver-179.html
Posts #1784, 1785

Your suggestion was to produce the delay in ALSA using LADSPA plug-ins. There are some concerns for me, that need to be cleared. As far as I understand LADSPA plug-ins turn out to be filters, so I am afraid that a delay, generated by the LADSPA plug-ins, might modify the signal. That is what I want to avoid completely. During my setup of Botic I was digging into linux the first time to understand and be able to modify configuration... but not as deep as I would need to answer that question by myself.

Regards,
Hans

 

[francolargo]

Hello Hans,

Yes, we want you to be comfortable that the plug-in used to delay the signal is not changing it in any other way. Most existing LADSPA plugins are from an earlier time when they were used in music production. Here is a brief overview of that: Linux Audio Plug-Ins: A Look Into LADSPA - O'Reilly Media

...and an old list of some of the filters that are 'out there'... https://www.mltframework.org/bin/view/MLT/PluginsFilters


For the BBB, the Computer Music Toolkit has five different variable delays, ranging from 0-10 msec to 0-60 sec. They have a feedback feature, which is optional, and they are simple to use. I suggest starting with these. Computer Music Toolkit is available using apt-get.

To start, open a terminal connection to the BBB and perform step one from this early post [no need to perform later steps]. http://www.diyaudio.com/forums/twis...lters-digital-crossovers-bbb.html#post4400290

Then you need to create an additional configuration file for ALSA. I use /etc/asound.conf. In that file you will specify the plugins to be used and you could include many other manipulations. I suggest you start by looking at and understanding the 6 channel one in this post.

Sound 'flow' is from pcm.default -> pcm.filter -> pcm.delay -> channel alignment via t.table.
Each LADSPA plugin position within pcm.filter and pcm.delay is equivalent - they could use any LADSPA filter for whatever purpose. You can substitute the desired delay plugins into the filter plug, removing numbers 6 and 7, and then slave that directly to the 'speaker' plug (instead of 'delay', which you can delete). Eventually, I suggest also bypassing the t.table because there is no need to keep channels organized into different chains. But we will leave it there for now because it will help discover which channel number is which Cronus output. So here is what we have:

pcm.!default {
     type plug
     slave.pcm filter
     channels 6
}
ctl.!default {
     type hw
     card 0
}
pcm.filter {
     type ladspa
     slave.pcm delay
     path "/usr/local/lib/ladspa"
     channels 6
     plugins
     {
          0 {
               label delay_1s
               policy none
               input.bindings.0 "Input"
               output.bindings.0 "Output"
               input { controls [ 0.0 1 ] } # [delay in seconds, wet/dry (0=all input, 1=all output)]
          }
          1 {
               label delay_1s
               policy none
               input.bindings.1 "Input"
               output.bindings.1 "Output"
               input { controls [ 0.0 1 ] }
          }
        2 {
               label delay_1s
               policy none
               input.bindings.2 "Input"
               output.bindings.2 "Output"
               input { controls [ 0.0 1 ] }
          }
        3 {
               label delay_1s
               policy none
               input.bindings.3 "Input"
               output.bindings.3 "Output"
               input { controls [ 0.0 1 ] }
          }
        4 {
               label delay_1s
               policy none
               input.bindings.4 "Input"
               output.bindings.4 "Output"
               input { controls [ 0.0 1 ] }
          }
        5 {
               label delay_1s
               policy none
               input.bindings.5 "Input"
               output.bindings.5 "Output"
               input { controls [ 0.0 1 ] }
          }
     }
}
pcm.speaker {
    type plug
    slave {
     ppm "t-table"
     channels 6
     rate "unchanged"
    }
}
pcm.t-table  {
    type route
    slave {
     pcm "hw:0,0"
     channels 6
    }
    ttable {
      0.0   1
      1.1   1
      2.2   1
      3.3   1
      4.4   1
      5.5   1
    }
}

pcm.plughw.slave.rate = "unchanged";

Save this as /etc/asound.conf, reboot, execute

export LADSPA_PATH=/usr/local/lib/ladspa:/usr/lib/ladspa

...and see if 'speaker-test -c 2' gives you any sound. We haven't considered your sound program source, it's native number of channels, and how to make sure it uses ALSA's 'default' input. But that should be no problem, and is the next step.

Feel free to ask questions!

Cheers,
Frank

 

[triodehunter]

Hello Frank,

whow, istant reply! Tons of information... You can be sure there will be questions... Will take me some time...

Well, I'll do my best!

Thank You Frank,

Servus,
Hans

 

[francolargo]

Sorry, I noticed an error in the above code - pcm.filter should slave to pcm.speaker (not 'delay').

pcm.filter {
     type ladspa
     slave.pcm speaker

 

[francolargo]

More LADSPA plugins with delays. Installing these is more complex than simply using those in CMT.
Steve Harris' LADSPA Plugin Docs
Note that each LADSPA filter can be inserted in a chain to achieve different effects based on other DSP before or after. Your application is very simple, of course. No need for feedback, echo, etc. I understand that ALSA offers up to 32 bit precision, so there should be no truncation artifacts from delaying anything that our DACs can handle.

 

[hopkins]

I am little confused about how to implement slopes in filters with ACDf: which filters can I use to have a highpass or lowpass with 12db slope, for example ? What about a 24db slope ?

If I want to add a highself and lowshelf filter after, can I just add a plugin in sequence in my crossover plug definition ?

Thanks

 

[francolargo]

Greetings @hopkins,

The essential information is in the file labeled 'ACDf_usage_notes.txt'. That should be in the same folder as ACDf.so.

First order filters have a 6dB/octave slope, second order are 12dB/octave. With ACDf you create serial filter strings using either first or second order plugins. A fourth order slope (24 dB/octave) is obtained by passing the signal sequentially through two identical 2nd order filters. Of course you can combine a shelf with a high or low-pass filter, and the slopes can add or not, depending on the chosen filter corner frequencies.

Here is some background with terms: https://en.wikipedia.org/wiki/Audio_crossover

Cheers,

Frank

 

[hopkins]

Greetings @hopkins,

The essential information is in the file labeled 'ACDf_usage_notes.txt'. That should be in the same folder as ACDf.so.

First order filters have a 6dB/octave slope, second order are 12dB/octave. With ACDf you create serial filter strings using either first or second order plugins. A fourth order slope (24 dB/octave) is obtained by passing the signal sequentially through two identical 2nd order filters. Of course you can combine a shelf with a high or low-pass filter, and the slopes can add or not, depending on the chosen filter corner frequencies.

Here is some background with terms: https://en.wikipedia.org/wiki/Audio_crossover

Cheers,

Frank

Thanks. How do you create serial filter strings? Could you give me an exemple of the syntax to use ? Should I follow your example here: http://www.diyaudio.com/forums/twis...ers-digital-crossovers-bbb-7.html#post4407676
Or is there a simpler syntax ?

EDIT: Think I found the answer in your post here: "Also, an experience to share... I found on the BBB that if I serially modified a signal too much, or too asymmetrically (or something, I'm not quite sure) then the channel numbers would randomly flip around during the filtration. Tweeters could get highs for a while, then bass, then anything else, and not necessarily from the same side. So that is why my 3-way stereo crossover uses 8 channels. It distributed the work in a way that eliminated that very undesirable behavior. So just a mini-heads up there... If something wonky starts happening, I would start by dividing serial chains among more plugs - fewer filters per channel per plug. That said, it is quite possible that ALSA in the RPi has different behaviors than ALSA in the BBB."

I had similar problems, and will try putting the filters in different plugs.

 

[hopkins]

Also, has anyone been able to use these plugins with Shairport-sync?

 

[francolargo]

EDIT: Think I found the answer in your post here: "Also, an experience to share...
...
I had similar problems, and will try putting the filters in different plugs.

Yes, that is an issue we all want to avoid! But each platform has a different 'tolerance' for multiple filters in series. For example, Raspbian (sp?) for the RPi appears a little more tolerant than the Debian I use on the BBB.

You can see what is currently working fine for me - a 3-way with LR 4th order filters: https://github.com/francolargo/BBB-audio/blob/master/asound.conf.ACDf.3-way

Each 2nd order filter must be run twice, so I use two different plugs (filter1 and filter2) in which lows and highs are modified once and mids are modified twice. This distributes the load/buffers/time periods/whatever adequately.

Good luck!

Frank

 

[hopkins]

Yes, that is an issue we all want to avoid! But each platform has a different 'tolerance' for multiple filters in series. For example, Raspbian (sp?) for the RPi appears a little more tolerant than the Debian I use on the BBB.

You can see what is currently working fine for me - a 3-way with LR 4th order filters: https://github.com/francolargo/BBB-audio/blob/master/asound.conf.ACDf.3-way

Each 2nd order filter must be run twice, so I use two different plugs (filter1 and filter2) in which lows and highs are modified once and mids are modified twice. This distributes the load/buffers/time periods/whatever adequately.

Good luck!

Frank

Thanks - making progress...

 

[hugligan]

Hi! Im facing a very annoying problem trying to setup 2-way filter in LADSPA on Ubuntu 16.04 on an Asrock E350m1 motherboard with Realtek ALC892. Ive been at it all day today..!

My first problem was that no matter what config i chose in /etc/asound.conf there would be no change what so ever to the sound. This was resolved however by uninstalling pulseaudio. Now it seems to work almost exactly how i want it. When i play

aplay -D default chan_labels_4.wav

(wav file from rtaylor) the output is correct, low R/L and high R/L. However when i play spotify or for that matter another WAV file with aplay, there is only sound in the woofers. I for the life of me cant figure out why this is. If anyone has an idea, itd be most appreciated.

My config is as follows (tried to simple it down as much as possible, also my default is on card 1, not 0 as seen commonly here):

pcm.!default {
     type plug
     slave.pcm filter
}
ctl.!default {
     type hw
     card 1
}
pcm.filter {
     type ladspa
     slave.pcm speaker
     path "/usr/lib/ladspa"
     channels 4
     plugins
     {
          0 {
               label RTlr4lowpass
               policy none
               input.bindings.0 "Input"
               output.bindings.0 "Output"
               input { controls [ 400 ] }   # low left [ frequency in Hz (-6dB XO point)]
          }
          1 {
               label RTlr4hipass
               policy none
               input.bindings.2 "Input"
               output.bindings.2 "Output"
               input { controls [ 400 ] }   # high left
          }
        2 {
               label RTlr4lowpass
               policy none
               input.bindings.1 "Input"
               output.bindings.1 "Output"
               input { controls [ 400 ] }   # low right
          }
        3 {
               label RTlr4hipass
               policy none
               input.bindings.3 "Input"
               output.bindings.3 "Output"
               input { controls [ 400 ] }   # high right
          }
     }
}


 pcm.speaker {
    type plug
    slave.pcm "hw:1,0" 
}

 

[francolargo]

Now it seems to work almost exactly how i want it. When i play

aplay -D default chan_labels_4.wav

(wav file from rtaylor) the output is correct, low R/L and high R/L. However when i play spotify or for that matter another WAV file with aplay, there is only sound in the woofers. I for the life of me cant figure out why this is. If anyone has an idea, itd be most appreciated.

Yes, as written your system requires 4 channel input. For stereo input you must process channels 0 and 1 for both lows and highs. This is done using input bindings different from output bindings. So channel 0 can output to 0 in one filter, and to channel 2 in a different one. There are many examples in this thread, like post #232. Make that adjustment and it seems you will have no other issues. Good luck!

Frank