That is a great analogy! As a teaching professional (post-graduate health sciences) I appreciate the clarity (and compliment your English)! 
I have not realized the distinction between playback and capture in the examples I have been studying.
I will try to tune up the type-file plugin you suggested relative to the 'direction' of information. Thus far, (plugin i/o reversed) I found that ecasound will only launch via ALSA if I execute 'aplay -D [the type-file plugin name] [the music file]'. ...and then, there is no sound. Previously, it has been necessary to have the ecasound engine running before starting music playback via MPD.
I persist with this because of the enjoyment of learning, and your help is contributing much to that! My hope is to derive a solution that is generally applicable among ARM platforms. I suspect that @Miero may have removed some 'normal' ALSA functions or tools from his customized distro. So if I fail in the short-term, I plan to start with a fresh copy of the latest Debian distro and apply some of what I am learning to that. In that approach, I would also update MPD to fall back on sox resampling as you suggest.
Best,
Frank
I have not realized the distinction between playback and capture in the examples I have been studying.I will try to tune up the type-file plugin you suggested relative to the 'direction' of information. Thus far, (plugin i/o reversed) I found that ecasound will only launch via ALSA if I execute 'aplay -D [the type-file plugin name] [the music file]'. ...and then, there is no sound. Previously, it has been necessary to have the ecasound engine running before starting music playback via MPD.
I persist with this because of the enjoyment of learning, and your help is contributing much to that! My hope is to derive a solution that is generally applicable among ARM platforms. I suspect that @Miero may have removed some 'normal' ALSA functions or tools from his customized distro. So if I fail in the short-term, I plan to start with a fresh copy of the latest Debian distro and apply some of what I am learning to that. In that approach, I would also update MPD to fall back on sox resampling as you suggest.
Best,
Frank
@francolargo:
Your tenacity is enviable. I don't think that implementing the LADSPA plugins via ALSA for a crossover application is a great idea. It's possible, but extremely complicated, to use ALSA to set up the routing needed for multi-way loudspeakers that need multiple LADSPA plugins.
I'm watching with some interest to see if you can even get it working.
It's still beyond me why you keep going in this direction when there are simpler solutions available.
Your tenacity is enviable. I don't think that implementing the LADSPA plugins via ALSA for a crossover application is a great idea. It's possible, but extremely complicated, to use ALSA to set up the routing needed for multi-way loudspeakers that need multiple LADSPA plugins.
I'm watching with some interest to see if you can even get it working.
It's still beyond me why you keep going in this direction when there are simpler solutions available.
Thanks Charlie. Actually, the routing options are well defined based on system type (surround40, surround51, etc), and custom routing is the one thing that (so far) I have gotten to work in an alsa plugin! I am by no means dismissing 'simpler' solutions! Rather, following a logical progression in the course of learning. Your thoughts and comments have contributed there as well!
Please post with example code if/when you have gotten that to work. I'm very interested in seeing an example of LADSPA implemented via ALSA.
The popen command is executed when opening the file plugin which gets opened by all the plugins upstream, the first one being opened by aplay at startup.
What is your alsa config?
That is why ecasound would open the soundcard at specific capture samplerate and MPD would have to resample to comply. You need it the other way round - mpd opens a device which in turn starts your chain with parameters controlled by mpd according to the actual played track.
Debian has an ARM port, you should have all the packages needed available from the repo.
You certainly know this alsa.opensrc.org . I have never played with it (but other have e.g. the digital machine ).
Another reason to try to get LADSPA filters working in ALSA is that ecasound now appears too CPU-hungry. At first I didn't notice that it was down-sampling its own internal filter loop for sources with -r: greater than 44.1. The %CPU is at 97% and sound skips when 88.2kHz is enforced on the ecasound filter loop running an input with -f: = 32,2,88200. And this is for a two-way crossover. Interestingly, the '-x' option in ecasound lowers CPU use for 44.1kHz files from 60% to 14% - the number that encouraged me initially. But, '-x' has no noticeable effect on CPU load at 88.2kHz. So it is worth trying to learn what system resources the LADSPA filters themselves require if running within ALSA.
...will keep 'plugging away'...
...will keep 'plugging away'...
I'm learning a lot from this thread. Thank you all! Is anyone still playing around with the pi platform or have you all moved on to other solutions? My usage of the Pi will not include any hi rez files so I haven't given up the thought of using it yet. It will mainly be streaming Web based music in the family room. Looking to see if I can pipe it via shair port or dlna based solution. Last night I had two different streams playing at the same time - one from mpd piped to ecasound to USB dac and the other via shairport to hdmi. I read on the ecasound mailing list that ecasound can output the stream to multiple soundcard at the same time, and perhaps that could work (or it will introduce even more problem keeping it aligned).
Will start experimenting more soon but need to get hold of a multichannel DAC. Any recommendations for an external USB based one? Which hdmi ones did you try?
So for you who have been successful via VLC or mpd, etc., what's your impression of the sound quality so far? How does it compare with other hardware solutions or analog crossover?
Will start experimenting more soon but need to get hold of a multichannel DAC. Any recommendations for an external USB based one? Which hdmi ones did you try?
So for you who have been successful via VLC or mpd, etc., what's your impression of the sound quality so far? How does it compare with other hardware solutions or analog crossover?
Odal, I'm not a strong believer is my ability to hear differences between DACs, so I bought a very inexpensive 7.1 USB device. Pretty generic, no actual name brand. Cost about $25. Works just fine for my crossover and extra channel. I have no complaints, and see no real reason to upgrade it.
In fact, I changed system boxes a couple weeks ago, and could have dropped in one of my "better" internal cards, but that would have meant re-routing wires. Nah, why bother? Works fine...
In fact, I changed system boxes a couple weeks ago, and could have dropped in one of my "better" internal cards, but that would have meant re-routing wires. Nah, why bother? Works fine...
All of us are caught between convenience vs. SQ so there is certainly no correct approach to all of this. My own efforts stem from having very high resolution speakers, amps, and DACs. So tweaking the source for all of them does really matter.
Update before I leave this for the weekend:
As I suspected, the arm-linux-gnueabihf/alsa-lib of libasound2 1.0.27.2 is incomplete. It is missing the object 'libasound_module_pcm_LADSPA.so'. Thus, my plug in the alsa.conf file returns "cannot open shared library..."
I tried compiling a pcm_LADSPA.c version from another 1.0.29 package but it failed because it requires 'local.h'. Looking at local.h, it requires 'mask.h', and looking at mask.h, I see it requires 'mask_inline.h'. The sources I can find for these all come from different ALSA-lib versions, so I think trying to patch my current libasound will be a waste of time. For now, I will look for a Debian armhf distro with the needed pcm_LADSPA.so. If found, I will try to "Boticize" it using Miero's scripts.
As I suspected, the arm-linux-gnueabihf/alsa-lib of libasound2 1.0.27.2 is incomplete. It is missing the object 'libasound_module_pcm_LADSPA.so'. Thus, my plug in the alsa.conf file returns "cannot open shared library..."
I tried compiling a pcm_LADSPA.c version from another 1.0.29 package but it failed because it requires 'local.h'. Looking at local.h, it requires 'mask.h', and looking at mask.h, I see it requires 'mask_inline.h'. The sources I can find for these all come from different ALSA-lib versions, so I think trying to patch my current libasound will be a waste of time. For now, I will look for a Debian armhf distro with the needed pcm_LADSPA.so. If found, I will try to "Boticize" it using Miero's scripts.
Plugin(s) UPDATE:
I've now gotten two plugins working out of the three that I am planning to create to support loudspeaker crossovers. I have definitely learned a lot about the LADSPA architecture and how to go about implementing a plugin during this process! I have to go back and implement some tweaks to the first plugin that I created given what I now know.
I have tested out the filter plugin myself, and had someone else try it out as well. It appears that it is working well. I didn't anticipate some problems with the Makefile - the compilation options can be machine dependent. I need to figure out how to instruct the user to change these to suit their machine, or just provide a generic set of options that should work on most any machine. I'd love input on that (tailoring a Makefile to different platforms) if you happen to have that knowledge.
I'll post additional info and updates when there is something new to report.
-Charlie
I've now gotten two plugins working out of the three that I am planning to create to support loudspeaker crossovers. I have definitely learned a lot about the LADSPA architecture and how to go about implementing a plugin during this process! I have to go back and implement some tweaks to the first plugin that I created given what I now know.
I have tested out the filter plugin myself, and had someone else try it out as well. It appears that it is working well. I didn't anticipate some problems with the Makefile - the compilation options can be machine dependent. I need to figure out how to instruct the user to change these to suit their machine, or just provide a generic set of options that should work on most any machine. I'd love input on that (tailoring a Makefile to different platforms) if you happen to have that knowledge.
I'll post additional info and updates when there is something new to report.
-Charlie
Here's a fun trick you can try at home folks!
Making some progress on plugin #3... it uses a "trick" to allow the user to specify the transfer function (biquad) coefficients in double precision when only single precision numbers can be passed to the plugin.
PROBLEM:
It turns out that most hosts for LADSPA, as well as the default header file that controls LADSPA behavior, specify that parameters passed to the plugin from the host are in single precision "float" data type. Typically one wants to specify the biquad coefficients in double precision because single precision values can result in response errors.
TRICK PLAY:
There is a relatively easy way to get around the "float" limitation using two key facts: (1) There is no limit to the number of parameters that can be passed from host to LADSPA plugin and (2) the size of the double data type is twice as large (8 bytes) as the float type (4 bits). So, instead of passing five doubles we can pass ten floats and combine each successive pair of floats into a double. To get the 10 floats you need to convert the desired value (a double) into its first 4 bytes, and its second 4 bytes, and then convert each of the two 4 byte values into a float. From five doubles we get ten floats that are then supplied to the host, which passes them on to the plugin, which recombines them automagistically into an 8-byte double.
I've managed to get most of this working. Currently I am using some online tools to get the binary representation of a few (three) doubles and convert these to pairs of floats. With some code that I cooked up I convert the floats to binary, combine all the lovely bits, and then produce the double without resorting to either smoke (which has been reserved for amplifier builders) OR mirrors.
Below is some program output from what I coded up tonight. The starting values (doubles) are recovered intact to 14 or 15 decimal places.
Making some progress on plugin #3... it uses a "trick" to allow the user to specify the transfer function (biquad) coefficients in double precision when only single precision numbers can be passed to the plugin.
PROBLEM:
It turns out that most hosts for LADSPA, as well as the default header file that controls LADSPA behavior, specify that parameters passed to the plugin from the host are in single precision "float" data type. Typically one wants to specify the biquad coefficients in double precision because single precision values can result in response errors.
TRICK PLAY:
There is a relatively easy way to get around the "float" limitation using two key facts: (1) There is no limit to the number of parameters that can be passed from host to LADSPA plugin and (2) the size of the double data type is twice as large (8 bytes) as the float type (4 bits). So, instead of passing five doubles we can pass ten floats and combine each successive pair of floats into a double. To get the 10 floats you need to convert the desired value (a double) into its first 4 bytes, and its second 4 bytes, and then convert each of the two 4 byte values into a float. From five doubles we get ten floats that are then supplied to the host, which passes them on to the plugin, which recombines them automagistically into an 8-byte double.
I've managed to get most of this working. Currently I am using some online tools to get the binary representation of a few (three) doubles and convert these to pairs of floats. With some code that I cooked up I convert the floats to binary, combine all the lovely bits, and then produce the double without resorting to either smoke (which has been reserved for amplifier builders) OR mirrors.
Below is some program output from what I coded up tonight. The starting values (doubles) are recovered intact to 14 or 15 decimal places.
Code:
PROGRAM INPUT:
input[0] = 1.904321
input[1] = 70.17572
input[2] = 2.0432098
input[3] = 9.948756E7
input[4] = 1.4969136
input[5] = 1.1859038E-5
BINARY (4 BYTE) REPRESENTATION OF INPUT:
string[0] = 00111111111100111100000011001010
string[1] = 01000010100011000101100111111000
string[2] = 01000000000000101100001111110011
string[3] = 01001100101111011100000111101001
string[4] = 00111111101111111001101011011101
string[5] = 00110111010001101111011000101110
DOUBLES RESULTING FROM COMBINING TWO 4 BYTE VALUES
double[0] = 1.234567890123456
double[1] = 2.345678901234568
double[2] = 0.123456789012345
Last edited:
UPDATE:
I have gotten the direct-biquad-coefficient LADSPA "trick" plugin working. The only thing left to do is a test of the double-to-float-pair converter under Linux.
I tested the plugin using a couple of different sets of filter coefficients that I generated with my ACD spreadsheets and it works great.
This more or less rounds out the plugins that I was planning to write. I will polish up the code a bit and then release the plugins as soon as they are ready.
I have gotten the direct-biquad-coefficient LADSPA "trick" plugin working. The only thing left to do is a test of the double-to-float-pair converter under Linux.
I tested the plugin using a couple of different sets of filter coefficients that I generated with my ACD spreadsheets and it works great.
This more or less rounds out the plugins that I was planning to write. I will polish up the code a bit and then release the plugins as soon as they are ready.
Two items: Using LADSPA filters in SoX and testing processor demands, I find that the R. Taylor "L-R 4 pole" filters (high or lowpass) each consume between 12-15% of the BBB CPU when filtering a stereo 96/32 file. That restores hope that the BBB has the capacity for a two-way system, at least. Second, I found that the 1.0.29 version of ALSA-lib DOES include the LADSPA plugin, though it is fairly new and considered 'unstable'. I'll back up my work to date and then try installing it...
The plugins are now available for download from my web site at:
ACD-plugins
Please read the README file as well as the USAGE NOTES that are included with the download.
Please contact me immediately if you have problems compiling and installing the plugins, cannot download the tar file, etc. Thanks and have fun!
ACD-plugins
Please read the README file as well as the USAGE NOTES that are included with the download.
Please contact me immediately if you have problems compiling and installing the plugins, cannot download the tar file, etc. Thanks and have fun!
I woke up last night and realized that I forgot to remove some lines that produced debugging output from the code. I fixed that this morning. I also assigned major/minor revision numbers to the download.
I didn't include the direct biquad coefficient plugin in the download. I am probably the only person who would want to use that anyway... but if you have a need for it you can contact me.
I didn't include the direct biquad coefficient plugin in the download. I am probably the only person who would want to use that anyway... but if you have a need for it you can contact me.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.