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

Twisted Pear Superior quality electronic kits

Reply
 
Thread Tools Search this Thread
Old 31st July 2015, 06:49 AM   #61
stijn001 is offline stijn001  Netherlands
diyAudio Member
 
stijn001's Avatar
 
Join Date: Dec 2011
Hi Francolargo, I'm very intrigued by your results. Does this mean you have the LADSPA filter working with MPD? Can you do a quick howto, and include some of the settings you used?
  Reply With Quote
Old 31st July 2015, 01:17 PM   #62
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Hi @stijn001, I'm just starting my action-list. Fingers crossed there will be no issues! More info coming as soon as possible.
  Reply With Quote
Old 31st July 2015, 09:54 PM   #63
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Greetings,

Most of the discussion between page 1 and here related to difficulties using LADSPA filter plugins in alsa with MPD. It didn't work right with all players at first. I'm happy to report that the problem seems fixed. Extra special thanks to @phofman and @miero for their help! In the end, there was a configuration issue in the asound.conf file and correcting it solved all of the problems that we were up against. As always, please speak up if you find errors or omissions. Again, the important LADSPA filters are from here, where you can read more about their implementation. The simple delay is from Computer Music Toolkit (whose online documentation appears hacked at the moment - http://www.ladspa.org/cmt/ ). Unlike the R.Taylor setup, we are running them within ALSA, which avoids the sample rate conversions needed with other filter clients.

Below is an updated configuration for a 'generic' two way crossover using the Richard Taylor 4-pole Linkwitz-Riley high- and low-pass LADSPA filters. I have tested it to the best of my ability with my current basic setup, but more rigorous testing with decent instrumentation must wait. For now, it seems to run fine and sound fine. The good thing is that no special player configuration is needed - neither for MPD nor for squeezelite. The players' default configurations are very close to optimal. Just use the setup instructions on page 1 of this thread but copy/paste the following text to the /etc/asound.conf file, reboot, double check that the file was read using 'aplay -L' (plugins are listed at the top), and begin experimenting.



Code:
pcm.!default {
     type plug
     slave.pcm filter
}
ctl.!default {
     type hw
     card 0
}
pcm.filter {
     type ladspa
     slave.pcm eq
     path "/usr/lib/ladspa"
     channels 4
     plugins
     {
          0 {
               label RTlr4lowpass
               policy none
               input.bindings.0 "Input"
               output.bindings.2 "Output"
               input { controls [ 440 ] }   # low left [ frequency in Hz (-6dB XO point)]
          }
          1 {
               label RTlr4hipass
               policy none
               input.bindings.0 "Input"
               output.bindings.0 "Output"
               input { controls [ 440 ] }   # high left
          }
        2 {
               label RTlr4lowpass
               policy none
               input.bindings.1 "Input"
               output.bindings.3 "Output"
               input { controls [ 440 ] }   # low right
          }
        3 {
               label RTlr4hipass
               policy none
               input.bindings.1 "Input"
               output.bindings.1 "Output"
               input { controls [ 440 ] }   # high right
          }
     }
}
pcm.eq {
     type ladspa
     slave.pcm  delay
     path "/usr/lib/ladspa"
     channels 4
     plugins
     {
        0 {
               label RTparaeq
               policy none
               input.bindings.0 "Input"
               output.bindings.0 "Output"
               input { controls [ 0 4800 2.0 ] }   # high left [ delta dB, frequency, Q ]
          }
        1 {
               label RTparaeq
               policy none
               input.bindings.1 "Input"
               output.bindings.1 "Output"
               input { controls [ 0 4800 2.0 ] }   # high right
          }
        2 {
               label RTparaeq
               policy none
               input.bindings.2 "Input"
               output.bindings.2 "Output"
               input { controls [ 3 30 0.7 ] }   # low left
          }
        3 {
               label RTparaeq
               policy none
               input.bindings.3 "Input"
               output.bindings.3 "Output"
               input { controls [ 3 30 0.7 ] }   # low right
          }
            }
}

pcm.delay {
     type ladspa
     slave.pcm  speaker
     path "/usr/lib/ladspa"
     channels 4
     plugins
     {
        0 {
               label delay_5s
               policy none
               input.bindings.0 "Input"
               output.bindings.0 "Output"
               input { controls [ 0.0 0 ] }    # high left [delay in seconds, wet/dry (0=all input, 1=all output)]
          }
        1 {
               label delay_5s
               policy none
               input.bindings.1 "Input"
               output.bindings.1 "Output"
               input { controls [ 0.0 0 ] }   # high right - 0.001 sec. = ~ 33 cm of sound travel
          }
        2 {
               label delay_5s
               policy none
               input.bindings.2 "Input"
               output.bindings.2 "Output"
               input { controls [ 0.0 0 ] }   # high left
          }
        3 {
               label delay_5s
               policy none
               input.bindings.3 "Input"
               output.bindings.3 "Output"
               input { controls [ 0.0 0 ] }   # high right
          }
     }
}

 pcm.speaker {
    type plug
    slave {
     pcm "t-table"
     channels 4
     rate "unchanged"
    }
}
pcm.t-table  {
    type route
    slave {
     pcm "hw:0,0"
     channels 4
    }
    ttable {
      0.0   1
      1.2   1
      2.1   1
      3.3   1
    }
}
Let me comment about each of the individual plugs in the chain. Conceptually, the 'signal' runs from top to bottom of the file. If you don't need a particular function, definitely delete its plug and correct the internal links between plugs, as described.

pcm.!default - do not edit

ctl.!default - do not edit

pcm.filter - insert your desired XO point frequency in the 'controls' box. It is set at 440Hz, which is easy to hear. I will be using mine somewhere between 120-150 Hz.

pcm.eq - many systems could use a bit of boost with low bass or perhaps the room has reflective nodes. An eq filter can address that kind of situation. [Hint: use sparingly above ~200Hz.] If you don't need them, delete the whole cpm.eq plug, and edit the slave.pcm output above in pcm.filter to connect to the next plug in line. That is, within the plug cpm.filter, the line "slave.pcm eq" might go to "slave.pcm delay" (without quotes).

pcm.delay - if your speaker or driver alignments are not optimal, you can delay the signal to any driver that, relative to the others, is located too close to the listener. In my case, my woofers will be about 33 cm in front of the midrange+tweeters. So, I will use a 0.001 second delay on the woofers, and no delay on the high frequencies. I don't know exactly how the delay filters are programmed so I will leave the two "inactive" high frequency delay filters in the chain for now. That will keep the processing more symmetrical. Later when I can set up with an oscilloscope we will see if the inactive delay filters are helping with time-keeping. Again, if you delete cpm.delay, you must link the above plug to the next in line (pcm.speaker) by editing the above slave.pcm line to "slave.pcm speaker" (no quotes).

pcm.speaker - do not edit or remove

pcm.ttable - do not remove This plug straightens out a channel alignment quirk of the BBB/Botic distro in which stereo pairs are not maintained in the channel alignments. Channels 1 (right high) and 2 (left low) are basically swapped. In each line of the table, the first number is the input channel, the second number is the output channel. [The third number is signal strength - not active here]. If you are adapting this configuration to a different system or setup, edit the ttable to correctly route the channels.


CPU draw - perfectly adequate

Using mpc/mpd, I played stereo files from 44.1 to 192kHz through the default system above. Here are the CPU numbers reported by top.

Code:
Freq.    PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND        
44.1    1027 mpd       20   0 84364  78m  26m S  13.9 15.9   1:37.01 mpd                  
48      1027 mpd       20   0 84380  78m  26m S  14.9 15.9   1:46.28 mpd                  
88.2    1027 mpd       20   0 88460  82m  26m S  27.5 16.7   1:58.75 mpd                  
96      1027 mpd       20   0 88460  82m  26m S  30.0 16.7   2:14.69 mpd                  
176.4   1027 mpd       20   0 96676  90m  26m S  55.0 18.3   2:50.14 mpd                  
192     1027 mpd       20   0 96668  90m  26m S  59.6 18.3   3:25.37 mpd
Thus, I'm optimistic that a basic three-way crossover can also be achieved with the BBB. For now, experiment - report back - enjoy!

Last edited by francolargo; 31st July 2015 at 10:16 PM.
  Reply With Quote
Old 31st July 2015, 10:41 PM   #64
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Mini-erratum: In the asound.conf text, the bottom two filters within the delay plugin are the low frequency channels (2 and 3), not high frequency as stated in the comment
  Reply With Quote
Old 2nd August 2015, 04:49 PM   #65
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Default Extending BBB/Botic function

Question for Miero:

What would it take to pipe an outside I2S source into Botic's alsa interface? Are there 3-4 pins on BBB p8 that could input into the system?

If we agree that the crossover described above is worthwhile, then it would be nice to share that filtering with other sources (than the output of music player software). Also, diverse LADSPA plugins could be used for many other functions than speaker crossovers. I assume external I2S would be easier to handle than encoded S/PDIF.

For example, with the TPA Wolfson S/PDIF transceiver, BBB could have ready access to a wide range of other audio appliances. Also, ADC has been discussed in relation to BBB, so adding an external I2S input could make Botic/BBB a great multi-function integrator for diverse audio sources. Would adding external I2S input be difficult or simple? To me, those pins on the p8 header are just begging to be used!

Last edited by francolargo; 2nd August 2015 at 05:08 PM.
  Reply With Quote
Old 2nd August 2015, 05:58 PM   #66
miero is offline miero  Czech Republic
diyAudio Member
 
Join Date: Jun 2011
Location: Prague
The hardware should work as I2S receiver; I've tested it using ADC from Juli@ soundcard -- http://www.diyaudio.com/forums/twist...ml#post4094282

There is only one 4 channel sound controller usable on the BBB (the CPU has two), so it would require to have matched rate/format to be able record & play at once.

And this will not work well if incomming I2S can change rate/format on the fly.

But it could be used quite well for ADC controlled by BBB, and this setup could be used as DSP processor for analog signal.
__________________
BeagleBone Black with I2S, DSD and SPDIF interface (Linux driver)
http://bbb.ieero.com/
  Reply With Quote
Old 2nd August 2015, 06:31 PM   #67
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Thanks, that sounds encouraging. For my personal system, I would like to be able to filter the audio portion of video feeds. Critical fidelity is not the first concern. In fact, I believe all my video hardware is fixed at 48k, so setting that rate as default would make sense. I will check your comments on the other thread, give more thought, and take it from there. Thanks Miero!
  Reply With Quote
Old 3rd August 2015, 01:08 PM   #68
stijn001 is offline stijn001  Netherlands
diyAudio Member
 
stijn001's Avatar
 
Join Date: Dec 2011
Thanks, for the explanation. For the time being I'm only intrested in the filter function. Now I need to find the time to do some tinkering.
  Reply With Quote
Old 3rd August 2015, 01:18 PM   #69
miero is offline miero  Czech Republic
diyAudio Member
 
Join Date: Jun 2011
Location: Prague
francolargo: notice, delay introduced by audio processing on BBB might be issue if you want use in real-time it for video.
__________________
BeagleBone Black with I2S, DSD and SPDIF interface (Linux driver)
http://bbb.ieero.com/
  Reply With Quote
Old 3rd August 2015, 09:04 PM   #70
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Quote:
Originally Posted by miero View Post
francolargo: notice, delay introduced by audio processing on BBB might be issue if you want use in real-time it for video.
Yes, there is that possibility. If the delay isn't too bad, there may be delay workarounds on the video side.

However, I am unsure of my ability to get I2S into the McASP. I am now looking into pin setup but in Botic I see no xxx.dts to edit and I need to understand more about tree overlays and what activates them. And then, how to make the configured pins input correctly to McASP? I see the davinci driver is there, but I haven't looked into that yet. It's a lot for a beginner to bite off!

Last edited by francolargo; 3rd August 2015 at 09:10 PM.
  Reply With Quote

Reply


LADSPA filters for digital crossovers on the BBBHide 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
LADSPA plugin programming for Linux audio crossovers CharlieLaub PC Based 476 14th June 2018 08:38 AM
filters/crossovers a little understanding needed charlie2 Multi-Way 3 19th February 2015 02:33 PM
Any new digital filters ? percy Digital Source 17 20th July 2008 01:39 AM
1st order filters/crossovers with proper drivers compared to full range? tech.knockout Multi-Way 8 15th May 2006 07:52 AM
Active crossovers and notch filters Saurav Multi-Way 15 26th February 2004 10:25 PM


New To Site? Need Help?

All times are GMT. The time now is 04:44 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