RASPBERRY PI 2 MULTICHANNEL AUDIO SUCCESS!
I thought I would report that I have had some success with audio on a Raspberry Pi 2 and it looks like I will be able to try implementing a crossover soon.
I recently decided to try a very cheap outboard USB 7.1 audio box. I received it today and after I installed LADSPA-SDK and ecasound I have been able to get multichannel audio out of the thing via ALSA. I currently have a a 4-channel amp connected to the Pi's USB soundcard, powering a pair of 2-way speakers. I need to go find the LADSPA+ecasound crossover configuration that I developed on the other system and then I will try that out. Also need to download some music files to try...
The USB soundcard was totally plug and play. The key to that seems to be getting a soundcard that adheres to the USB AUDIO 1.0 standard.
So, it's now looking up for multichannel audio out of my Raspberry Pi 2, something I thought I would never achieve!
I thought I would report that I have had some success with audio on a Raspberry Pi 2 and it looks like I will be able to try implementing a crossover soon.
I recently decided to try a very cheap outboard USB 7.1 audio box. I received it today and after I installed LADSPA-SDK and ecasound I have been able to get multichannel audio out of the thing via ALSA. I currently have a a 4-channel amp connected to the Pi's USB soundcard, powering a pair of 2-way speakers. I need to go find the LADSPA+ecasound crossover configuration that I developed on the other system and then I will try that out. Also need to download some music files to try...
The USB soundcard was totally plug and play. The key to that seems to be getting a soundcard that adheres to the USB AUDIO 1.0 standard.
So, it's now looking up for multichannel audio out of my Raspberry Pi 2, something I thought I would never achieve!
Great news!! Still havent had a chance to get a multichannel USB dac, but I got ecasound with filters working using one of the pre-configured players such as Volumio or Moode. If you haven't tried one of them, it's worth checking out since you get a lot of good stuff preconfigured plus it sounds really nice out of the box too. Since the configuration can be done via a Web interface, it opens up some options to add an easy user interface to input your crossover filter files. We just need to convince the programmers...
To get it to work at the moment requires to update the mpd with a pre compiled version with the pipe output plugin plus some of the missing ladspa files.
To get it to work at the moment requires to update the mpd with a pre compiled version with the pipe output plugin plus some of the missing ladspa files.
One more thing, Moode just implemented a solution to play files directly from the sd card which may help some of you that play high rez files.
A Raspberry Pi crossover is born
Success!!!
I downloaded my ACD plugins to the Raspberry Pi. I found that I had to modify the Makefile. The version of gcc included with Raspbian either doesn't include the -march=native compilation flag or it has been disabled or doesn't' work. I simply removed that from the CFLAGS string. Once I did that, the plugins were installed fine. I also had to set the LADSPA PATH environmental variable so that ecasound could find the plugins.
Finally, I invoked an ecasound command string that I had worked up on another machine for these speakers. Voila! A Raspberry Pi crossover is born.
EDIT: the Pi's system monitor is showing about 2-3% CPU usage by ecasound. This means that the audio processing overhead for the crossover is very minimal, even on the Pi.
@Odal3 - I have avoided Volumio and players like Moode. I find I can get all of that and more with the VLC player.
Success!!!
I downloaded my ACD plugins to the Raspberry Pi. I found that I had to modify the Makefile. The version of gcc included with Raspbian either doesn't include the -march=native compilation flag or it has been disabled or doesn't' work. I simply removed that from the CFLAGS string. Once I did that, the plugins were installed fine. I also had to set the LADSPA PATH environmental variable so that ecasound could find the plugins.
Finally, I invoked an ecasound command string that I had worked up on another machine for these speakers. Voila! A Raspberry Pi crossover is born.
EDIT: the Pi's system monitor is showing about 2-3% CPU usage by ecasound. This means that the audio processing overhead for the crossover is very minimal, even on the Pi.
@Odal3 - I have avoided Volumio and players like Moode. I find I can get all of that and more with the VLC player.
Last edited:
Making more progress... I created an ALSA loopback device by issuing the command:
This creates a Loopback device until you shutdown. You can put this command in your .profile or other startup batch file so that it runs each time to create the Loopback at startup.
I then select the Loopback as my playback device in VLC. To connect ecasound to the Loopback, I use the command:
The syntax for the above is -i[:]alsahw,card_number,device_number,subdevice_number (do not include spaces). You can get the values for card_number, device_number, and subdevice_number by issuing the command "aplay -lL" and looking through the output for the Loopback device.
IMHO, VLC is a nice way to control the audio. I can stream or play files, transcode or not, control it remotely, etc. I will have to play around to see if I can play or stream HD audio, although the current el cheapo USB soundcard will only handle up to 48kHz. With a better USB soundcard solution, this may be a high quality crossover solution using the Pi.
Code:
sudo modprobe snd-aloopI then select the Loopback as my playback device in VLC. To connect ecasound to the Loopback, I use the command:
Code:
-i:alsahw,2,1,0IMHO, VLC is a nice way to control the audio. I can stream or play files, transcode or not, control it remotely, etc. I will have to play around to see if I can play or stream HD audio, although the current el cheapo USB soundcard will only handle up to 48kHz. With a better USB soundcard solution, this may be a high quality crossover solution using the Pi.
Last edited:
Thanks for the filters. I'm going to play with them soon. Meanwhile it's a good thing you figured out your build issue above - since I'm on the PI. Thanks.
Where I am now-- I just got the filters working, I think. I started with the lr4 just because it's easy to test (abrupt and one argument). What I'm looking for is something that will work with all stuff, so I decided to edit my .asoundrc file. Here are the current contents, working as a simple lr4 test. Pretty cool, actually.
I set default to my 'woofer' and it runs a 4th order for the default alsa device.
pcm.!default {
type plug
slave.pcm "woofer"
}
ctl.!default {
type hw
card 0
}
pcm.speaker {
type plug
slave {
pcm "hw:0,0"
channels 2
}
}
pcm.woofer {
type ladspa
slave.pcm "speaker";
path "/usr/local/lib/ladspa";
plugins [{
label RTlr4hipass
input {
controls [ 1500 ]
}
}]
}
Where I am now-- I just got the filters working, I think. I started with the lr4 just because it's easy to test (abrupt and one argument). What I'm looking for is something that will work with all stuff, so I decided to edit my .asoundrc file. Here are the current contents, working as a simple lr4 test. Pretty cool, actually.
I set default to my 'woofer' and it runs a 4th order for the default alsa device.
pcm.!default {
type plug
slave.pcm "woofer"
}
ctl.!default {
type hw
card 0
}
pcm.speaker {
type plug
slave {
pcm "hw:0,0"
channels 2
}
}
pcm.woofer {
type ladspa
slave.pcm "speaker";
path "/usr/local/lib/ladspa";
plugins [{
label RTlr4hipass
input {
controls [ 1500 ]
}
}]
}
I DO NOT recommend that you use ALSA directly to implement LADSPA filters. Download ecasound and use that on the Pi. Enter:
Code:
sudo apt-get install ecasoundEcasound is much better suited, and much easier to work with, vis a vis crossovers and LADSPA.
What specifically are the differences/advantages, please? Is there a way to implement the same into the ladspa alsa plugin, to improve it to the same level? Using the loopback and ecasound just to circumvent a LADSPA plugin defficiency is clunky IMO. In the end it is all about passing memory region parameters and reading/writing to them, just the aloop/ecasound path is longer.
I see great complexity in the ALSA structures that are required just to implement a SINGLE FILTER! A crossover will be much more complex and my feeling is that the challenge of writing the ALSA structure to implement even a modestly complex 2-way crossover is way beyond most people. It is in theory possible with ALSA, but why go through all that hassle? What about a crossover for a 4-way loudspeaker that uses 20+ filters and EQ? Good luck. If you want to step up to the plate and give us some examples, I encourage you to do so.
From my vantage point ecasound provides all the functionality and the crossover can be described in a pretty simple manner. Also, with ecasound it is very easy to change a parameter and kill and restart ecasound to implement the change, on the fly so to speak. This allows the user to A/B changes in the crossover. Can you do that with ALSA without restarting ALSA completely?
I think that you are correct in your assertion that both ALSA and ecasound are doing about the same thing (pushing memory around). I don't believe that there is any kind of technical advantage (e.g. better performance) from one or the other. So it comes down to implementation and ease of use, and from that standpoint ecasound has an ALSA beat hands down.
The more I look at Alsa the more I think implementing this via .asoundrc (or sound.conf) is the way to go. This integrates it entirely within the lower level sound system and all applications work the same way.
I'm not that excited about Ecasound. I tried it but much of my music is flac, which it doesn't obviously support, and I'm just looking for a simple endpoint of a working crossover without the requirement for a custom player or pipe.
You can edit .asoundrc and without restarting anything -- next calls to Alsa stuff use the new settings. So, I was able to test just by keeping .asoundrc open in an editor and make change/save/run mplayer. The real negative is that the Alsa config doc has (as we say) a lot of room for improvement.
I think the Ecasound interface is way simpler and it's easier to prototype with. I don't think it's my endpoint.
I'm not that excited about Ecasound. I tried it but much of my music is flac, which it doesn't obviously support, and I'm just looking for a simple endpoint of a working crossover without the requirement for a custom player or pipe.
You can edit .asoundrc and without restarting anything -- next calls to Alsa stuff use the new settings. So, I was able to test just by keeping .asoundrc open in an editor and make change/save/run mplayer. The real negative is that the Alsa config doc has (as we say) a lot of room for improvement.
I think the Ecasound interface is way simpler and it's easier to prototype with. I don't think it's my endpoint.
Last edited:
OK, you are certainly welcome to try. If and when you actually implement a true crossover (not just one or two plugins) in ALSA, please post your ALSA configuration as an example. I would be very interested in seeing someone have success in that endeavor.
Just to clarify, ecasound should not be used as a player just like ALSA is not a media player. You need some other software to play your flac file, then you can simply route the output of that through ecasound using ALSA (loopback). The only caveat is that ecasound needs to be told what the sample rate when you invoke it. I get around this by transcoding everything I play in VLC to a fixed rate before outputting to ecasound. Your own goals seem to be a little different than my own, but I think this approach could still work for your case.
Last edited:
For anyone who is interested in putting together a budget multiway crossover using the Raspberry Pi 2, here is one option for an external USB soundcard that is so cheap that it is almost free:
USB Channel 5 1 7 1 External Optical Audio Sound Card Laptop Notebook PC | eBay
For $8 including shipping you get 7.1 audio, mic and line in, and spdif in/out. It's mind boggling. But it must be a POS and sound like garbage, right?
It just so happens that I recently bought one of these (not from this seller, I paid more) so that I could test whether this kind of solution (a USB soundcard) could work with the Pi. Since I have one, I took some measurements. These are attached.
Keep in mind that there are some real limitations to USB audio that are imposed by the bus throughput for some systems, unless you happen to have a high-speed port and dongle. This generally means that, for multichannel audio, you are limited to 48kHz (or lower) sampling rates and 16-bit depth. For me this is not a concern - I think that 48kHz is just fine if you know what you are doing and its been demonstrated that 16 bit audio is essentially indistinguishable from 24 or more bits (sorry 24/192 fans!).
The real question for me was what kind of distortion performance could be expected for something that is so ridiculously cheap. I was not expecting much, but I was pleasantly surprised that this interface is actually OK in terms of frequency response and distortion. Distortion (THD) falls from around 0.1% at 20Hz to 0.03% at 1kHz, and keeps falling as frequency increases to below 0.01% THD. It's not going to win any awards, but it is totally acceptable because the distortion levels are significantly lower than what you would expect from the loudspeaker drivers themselves, unless you happen to use the very best (and most expensive) ones. It's a great mainstream level performance for mainstream level loudspeakers.
If you want better performance from USB you can get it. I have on order a couple of inexpensive USB stereo audio DACs that are spec'd for up to 96kHz, although I have to see if the Pi hardware, and the software I am using on the Pi, are capable of providing that. Assuming they are, then if you limit yourself to 2-channel audio you can likely pair an inexpensive 96kHz USB audio dongle with the inexpensive Pi to get a bargain priced embedded DSP active crossover (for one 2-way speaker). You would need another Pi+USB dongle for the other speaker in the stereo pair.
USB Channel 5 1 7 1 External Optical Audio Sound Card Laptop Notebook PC | eBay
For $8 including shipping you get 7.1 audio, mic and line in, and spdif in/out. It's mind boggling. But it must be a POS and sound like garbage, right?
It just so happens that I recently bought one of these (not from this seller, I paid more) so that I could test whether this kind of solution (a USB soundcard) could work with the Pi. Since I have one, I took some measurements. These are attached.
Keep in mind that there are some real limitations to USB audio that are imposed by the bus throughput for some systems, unless you happen to have a high-speed port and dongle. This generally means that, for multichannel audio, you are limited to 48kHz (or lower) sampling rates and 16-bit depth. For me this is not a concern - I think that 48kHz is just fine if you know what you are doing and its been demonstrated that 16 bit audio is essentially indistinguishable from 24 or more bits (sorry 24/192 fans!).
The real question for me was what kind of distortion performance could be expected for something that is so ridiculously cheap. I was not expecting much, but I was pleasantly surprised that this interface is actually OK in terms of frequency response and distortion. Distortion (THD) falls from around 0.1% at 20Hz to 0.03% at 1kHz, and keeps falling as frequency increases to below 0.01% THD. It's not going to win any awards, but it is totally acceptable because the distortion levels are significantly lower than what you would expect from the loudspeaker drivers themselves, unless you happen to use the very best (and most expensive) ones. It's a great mainstream level performance for mainstream level loudspeakers.
If you want better performance from USB you can get it. I have on order a couple of inexpensive USB stereo audio DACs that are spec'd for up to 96kHz, although I have to see if the Pi hardware, and the software I am using on the Pi, are capable of providing that. Assuming they are, then if you limit yourself to 2-channel audio you can likely pair an inexpensive 96kHz USB audio dongle with the inexpensive Pi to get a bargain priced embedded DSP active crossover (for one 2-way speaker). You would need another Pi+USB dongle for the other speaker in the stereo pair.
Attachments
Hello
maybe you interested in a free GPL Solution for a complete crossover with GUI.
You can find my setup here:
diyAudio server HTTPS page
HIFI-FORUM » Do it yourself » Lautsprecher » Aktive Frequenzweiche per Standard Software mit GUI.
Sorry it is in German.
you can have
4x2 channel crossover
limiter
several equalizer
and much more
HDMI 8 Channel and 8 Channel analog output possible
Easy to install and setup
Regards
Loafmeat
maybe you interested in a free GPL Solution for a complete crossover with GUI.
You can find my setup here:
diyAudio server HTTPS page
HIFI-FORUM » Do it yourself » Lautsprecher » Aktive Frequenzweiche per Standard Software mit GUI.
Sorry it is in German.
you can have
4x2 channel crossover
limiter
several equalizer
and much more
HDMI 8 Channel and 8 Channel analog output possible
Easy to install and setup
Regards
Loafmeat
Hi Charlie,
Here's a very simple working crossover for asound.conf/.asoundrc. Just an lr4 at 2500Hz. This reads one channel and creates a woofer/tweeter set.
The default pcm device uses the pcm named "crosser" which does the lr filtering and passes it on to the hardware pcm named "speaker" for output. I haven't tested this other than audibly and it sounds ok...
update: I ran some frequency sweeps and sure enough I've got an lr4 tweeter/woofer crossover.
Here's a very simple working crossover for asound.conf/.asoundrc. Just an lr4 at 2500Hz. This reads one channel and creates a woofer/tweeter set.
The default pcm device uses the pcm named "crosser" which does the lr filtering and passes it on to the hardware pcm named "speaker" for output. I haven't tested this other than audibly and it sounds ok...
update: I ran some frequency sweeps and sure enough I've got an lr4 tweeter/woofer crossover.
Code:
pcm.!default {
type plug
slave.pcm "crosser"
}
ctl.!default {
type hw
card 0
}
pcm.crosser {
type ladspa
slave.pcm speaker
path "/usr/local/lib/ladspa"
channels 2
plugins
{
0 {
label RTlr4lowpass
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [ 2500 ] }
}
1 {
label RTlr4hipass
policy none
input.bindings.0 "Input"
output.bindings.1 "Output"
input { controls [ 2500 ] }
}
}
}
pcm.speaker {
type plug
slave {
pcm "hw:0,0"
channels 2
}
}
Last edited:
Cool - that IS interesting, even if it is mono (1 channel) input. How did you find the documentation or online examples to put this together???
How far do you think this architecture can be extended? A real crossover will usually employ many more filters and EQ bands. How about a 3-way or 4-way crossover? These can easily grow to over 20 filters. How is that complexity accommodated using ALSA?
If this adapts to changing sample rates, it would be more flexible than ecasound...
Last edited:
Hi,
1) I think I made a mistake and should use input.bindings.1 for the tweeter crossover otherwise I think it may be serialing the two filters for the tweeter side... need more testing. I was switching between them and don't know which I sweep-tested.
As for how I figured this out... sheesh the doc is miserable so it's a bunch of guesses. My plan would be to take out the lr4 calls and replace them with pointers to more complex ladspa plugins sequences (as you can see using the 0{} and 1{} syntax is pretty easy for stacking filters) that do the specific channel crossovers.
Note that as far as I can tell this is rate/format irrelevant.
1) I think I made a mistake and should use input.bindings.1 for the tweeter crossover otherwise I think it may be serialing the two filters for the tweeter side... need more testing. I was switching between them and don't know which I sweep-tested.
As for how I figured this out... sheesh the doc is miserable so it's a bunch of guesses. My plan would be to take out the lr4 calls and replace them with pointers to more complex ladspa plugins sequences (as you can see using the 0{} and 1{} syntax is pretty easy for stacking filters) that do the specific channel crossovers.
Note that as far as I can tell this is rate/format irrelevant.
Last edited:
btw since you asked about references I culled through my browser history and found 4, in order of usefulness...
Linux ALSA sound notes
Linux Audio Developer's Simple Plugin API (LADSPA)
Problem with 5.1 channel mapping, help configuring asound.conf
https://forums.gentoo.org/viewtopic-p-4528619.html
Linux ALSA sound notes
Linux Audio Developer's Simple Plugin API (LADSPA)
Problem with 5.1 channel mapping, help configuring asound.conf
https://forums.gentoo.org/viewtopic-p-4528619.html
I need a little help. My 'Linux fluency' is too rudimentary.
Background: My interest is a subset of implementing LADSPA filters in ALSA - in that I am hoping to get it working on a board that uses a special kernel. Among other good stuff, this Debian distro switches the external system clock to match (a multiple of) the recording sample rate. Unfortunately, the pre-compiled distro does not include the needed ALSA PCM plugins so that ALSA.conf code can execute according to established syntax. So I'm attempting to update ALSA from "stable" 1.0.27 to the latest 1.0.29 version by building from source.
Problem: The ./configure and following make install commands of alsa-lib-1.0.29 fail to compile the entire contents of the /src/pcm/ directory (all the plugs). So no calls to ALSA plugs work. The source /src/pcm/ directory contains Makefile, Makefile.am, and Makefile.in plus all the *.c, *.lo, and *.h files needed. How do I manually install the needed plugins from source??? I don't want to mess up at this stage...
MANY TIA!
Frank
PS, Charlie... I think we'll get this working in ALSA! Adhering strictly to the plugin syntax (linked above) is critical. If we get it going in a clock-switching system like my BBB with capes - super bonus! No criticism of ecasound - it just doesn't adapt well on the fly.
Background: My interest is a subset of implementing LADSPA filters in ALSA - in that I am hoping to get it working on a board that uses a special kernel. Among other good stuff, this Debian distro switches the external system clock to match (a multiple of) the recording sample rate. Unfortunately, the pre-compiled distro does not include the needed ALSA PCM plugins so that ALSA.conf code can execute according to established syntax. So I'm attempting to update ALSA from "stable" 1.0.27 to the latest 1.0.29 version by building from source.
Problem: The ./configure and following make install commands of alsa-lib-1.0.29 fail to compile the entire contents of the /src/pcm/ directory (all the plugs). So no calls to ALSA plugs work. The source /src/pcm/ directory contains Makefile, Makefile.am, and Makefile.in plus all the *.c, *.lo, and *.h files needed. How do I manually install the needed plugins from source??? I don't want to mess up at this stage...
MANY TIA!
Frank
PS, Charlie... I think we'll get this working in ALSA! Adhering strictly to the plugin syntax (linked above) is critical. If we get it going in a clock-switching system like my BBB with capes - super bonus! No criticism of ecasound - it just doesn't adapt well on the fly.
Last edited:
Thanks for the reply! Only one error in ./configure, which I take as inconsequential:
No errors in make or in make install. I did notice that the pcm_*.lo (library object) files were processed during make. e.g.
I'm out of ideas at the moment. 😕
Code:
./configure: line 12642: python-config: command not found
./configure: line 12650: python-config: command not found
Unable to determine python libraries! Probably python-config is not
available on this system. Please, use --with-pythonlibs and
--with-pythonincludes options. Python components are disabled in this build.No errors in make or in make install. I did notice that the pcm_*.lo (library object) files were processed during make. e.g.
Code:
CC mask.lo
CC interval.lo
CC pcm.lo
CC pcm_params.lo
CC pcm_simple.lo
CC pcm_hw.lo
CC pcm_misc.lo
CC pcm_mmap.lo
CC pcm_generic.lo
CC pcm_plugin.lo
CC pcm_copy.lo
CC pcm_linear.lo
CC pcm_route.lo
CC pcm_mulaw.lo
CC pcm_alaw.lo
CC pcm_adpcm.lo
CC pcm_rate.lo
CC pcm_rate_linear.lo
CC pcm_plug.lo
CC pcm_multi.lo
CC pcm_shm.lo
CC pcm_file.lo
CC pcm_null.lo
CC pcm_empty.lo
CC pcm_share.lo
CC pcm_hooks.lo
CC pcm_lfloat.lo
CC pcm_ladspa.lo
CC pcm_dmix.lo
CC pcm_dshare.lo
CC pcm_dsnoop.lo
CC pcm_direct.lo
CC pcm_asym.lo
CC pcm_iec958.lo
CC pcm_softvol.lo
CC pcm_extplug.lo
CC pcm_ioplug.lo
CC pcm_mmap_emul.loI'm out of ideas at the moment. 😕