There are lots of variables here, but I would be curious to see the command line you used to start Squeezelite. One common implementation is to have Squeezelite render and upsample everything to some fixed frequency using SoX routines. My listening experience has been different from yours when comparing MPD vs. Squeezelite output. All within Botic, and with no up sampling, I listened via headphones driven from the B3 I/V output buffers (B3 running asynchronously). Under those conditions I haven't (yet) heard any significant difference.
So unless different and better software comes along, I plan to enjoy the Logitech music server interface and Squeezelite. To control LMS via a tablet, I like the iPeng HD app.
Aaah, yes. Thanks for patience...
I am not in a big hurry, but it would be nice to know if I2S input to the BBB is working (or at least that it is trivial to eventually get working). I hope to process SPDIF from video one way or another, and the other options are much less nice than converting SPDIF -> I2S -> BBB & ALSA. Again, critical SQ is not the first concern. I have an optocoupler chip coming just in case...
Many thanks, Miero!
I'd agree with "there are a lot of variables".
IMO it depends on the tweaks and setup (OS and app) if and how much MPD and squeezelite differs.
A friend of mine tests all these MPD images against my stuff all the time. A soon as he notices me that one of them catching up, I feel challenged to look into my image.
I usually succeed to beat that MPD based installation again.
However. Both solutions can get pretty close in terms of soundquality - if tweaked in a similar way.
My main issues are other issues.
I don't like the way MPD handles coverarts.
How about Qobuz,Tidal asf. Can MPD handle these meanwhile?
I do also agree to FrancoLargo. I also prefer iPeng or Orange Squeeze over similar MPD apps.
Beside that there are squeeze playback apps for the mobile devices (iOS/Android).
That makes it easy to listen locally and/or feed your bluetooth speaker/DAC/receiver.
IMO it depends on the tweaks and setup (OS and app) if and how much MPD and squeezelite differs.
A friend of mine tests all these MPD images against my stuff all the time. A soon as he notices me that one of them catching up, I feel challenged to look into my image.
I usually succeed to beat that MPD based installation again.
However. Both solutions can get pretty close in terms of soundquality - if tweaked in a similar way.
My main issues are other issues.
I don't like the way MPD handles coverarts.
How about Qobuz,Tidal asf. Can MPD handle these meanwhile?
I do also agree to FrancoLargo. I also prefer iPeng or Orange Squeeze over similar MPD apps.
Beside that there are squeeze playback apps for the mobile devices (iOS/Android).
That makes it easy to listen locally and/or feed your bluetooth speaker/DAC/receiver.
Hi Pavle, Franco, or anyone ALSA fluent,
as a Linux noob, I have been working through setting-up digital crossover based on this topic, but seem to have some misunderstanding about how ALSA works. My file
looks as follows:
The intention is to use ALSA channel 0 as an input to a high-pass filter and because the channel 0 will be reused for the low-pass filter, the output of the high-pass filter is assigned to ALSA channel 2. Then the ALSA channel 0 is reused as an input to the low-pass filter and since the ALSA channel 0 will not be processed anymore, the output of the low pass filter can remain as ALSA channel 0.
Here is the output of:
As best as I can understand, the lines:
Similarly, the lines:
Here is the problem. The output of the low-pass filter is on ALSA channel 0, I can test it on as speaker. I tend to believe that the output of the high-pass filter is on ALSA channel 2; however, when I connect the speaker to a sound-card connector on which ALSA channel 2 is, there is no signal there.
Can anyone please explain why the ALSA channel 2 has no signal? Is it because the
Kindest regards,
M
as a Linux noob, I have been working through setting-up digital crossover based on this topic, but seem to have some misunderstanding about how ALSA works. My file
Code:
/etc/asound.confThe intention is to use ALSA channel 0 as an input to a high-pass filter and because the channel 0 will be reused for the low-pass filter, the output of the high-pass filter is assigned to ALSA channel 2. Then the ALSA channel 0 is reused as an input to the low-pass filter and since the ALSA channel 0 will not be processed anymore, the output of the low pass filter can remain as ALSA channel 0.
Here is the output of:
Code:
aplay -vv Track1.wavAs best as I can understand, the lines:
are interpreted as follows. InChannels is the ALSA channel to be processed, and is mapped on InPorts, which is the input of the high-pass filter. The OutChannels is the ALSA output channel which is provided by the OutPorts of the high-pass filter. This appears to be correct based on:
Similarly, the lines:
are interpreted in the same manner as confirmed by the lines:
Here is the problem. The output of the low-pass filter is on ALSA channel 0, I can test it on as speaker. I tend to believe that the output of the high-pass filter is on ALSA channel 2; however, when I connect the speaker to a sound-card connector on which ALSA channel 2 is, there is no signal there.
Can anyone please explain why the ALSA channel 2 has no signal? Is it because the
takes as a default only ALSA channel 0 and 1?
Kindest regards,
M
Last edited:
M.,
There could be a number of causes. Perhaps the most basic problem is that (AFAIK) a two channel plugin will only address channels numbered 0 and 1. Thus, when you specify a filter output binding of 2, it could be out of range. Try changing "output.bindings.2" to "output.bindings.1". Using channels numbered 2 & 3 would require the total number of channels in the plugin to be raised to four. So, try that change first and see what happens.
Stepping back from the problem a bit, you haven't mentioned specific details about your hardware. Again, running LADSPA filters in ALSA with a clock-switching kernel like Botic is advantageous for two particular reasons: it avoids resampling the signal to the fixed rate of the filter host, and this helps lower CPU load. If, in your system, output at the native sample rate is not particularly meaningful because the system clock can't switch frequencies (and you have plenty of CPU power), I almost suggest running the LADSPA filters in ecasound as per the Richard Taylor method. The ALSA examples I gave were customized for the BBB/Hermes/Cronus. That rig doesn't have a lot of CPU power but it has exquisite system clocks that switch to accommodate the recording sample rate of the music.
Let us know if this helps.
Frank
There could be a number of causes. Perhaps the most basic problem is that (AFAIK) a two channel plugin will only address channels numbered 0 and 1. Thus, when you specify a filter output binding of 2, it could be out of range. Try changing "output.bindings.2" to "output.bindings.1". Using channels numbered 2 & 3 would require the total number of channels in the plugin to be raised to four. So, try that change first and see what happens.
Stepping back from the problem a bit, you haven't mentioned specific details about your hardware. Again, running LADSPA filters in ALSA with a clock-switching kernel like Botic is advantageous for two particular reasons: it avoids resampling the signal to the fixed rate of the filter host, and this helps lower CPU load. If, in your system, output at the native sample rate is not particularly meaningful because the system clock can't switch frequencies (and you have plenty of CPU power), I almost suggest running the LADSPA filters in ecasound as per the Richard Taylor method. The ALSA examples I gave were customized for the BBB/Hermes/Cronus. That rig doesn't have a lot of CPU power but it has exquisite system clocks that switch to accommodate the recording sample rate of the music.
Let us know if this helps.
Frank
Hi Frank,
thank you very much for the reply.
Your AFAIK appears to confirm my hypothesis and, yes, I had already tried your proposed solution of "changing 'output.bindings.2' to 'output.bindings.1'", just to confirm my hypothesis. It did work.
However, the reason for me asking despite the above-mentioned "solution"; the solution has two problems. (1) In my understanding ALSA channel 1 is now output of the high-pass filter. So when I try to run stereo, ALSA channel 1 carries the other channel. (2) Is more fundamental - I do not just want to "make it work", I want to understand what is going on.
Regarding the specific details about the hardware, I am running Debian (since there is lot of help available) on an older Gigabyte motherboard with C2D processor and Audigy2 ZS card. This is just a proof of concept and attempt to understand the underlying issues.
Please keep us informed about your progress.
Kindest regards,
M
thank you very much for the reply.
Your AFAIK appears to confirm my hypothesis and, yes, I had already tried your proposed solution of "changing 'output.bindings.2' to 'output.bindings.1'", just to confirm my hypothesis. It did work.
However, the reason for me asking despite the above-mentioned "solution"; the solution has two problems. (1) In my understanding ALSA channel 1 is now output of the high-pass filter. So when I try to run stereo, ALSA channel 1 carries the other channel. (2) Is more fundamental - I do not just want to "make it work", I want to understand what is going on.
Regarding the specific details about the hardware, I am running Debian (since there is lot of help available) on an older Gigabyte motherboard with C2D processor and Audigy2 ZS card. This is just a proof of concept and attempt to understand the underlying issues.
Please keep us informed about your progress.
Kindest regards,
M
OK, this is a feature of your Audigy card. You will, of course, need to manage the signals once they are divided. The Audigy card (and possibly the ALSA plugins) will need to manage four channels. The linux speaker-test utility will also help. In the extreme case, you could tweak the Audigy alsa configuration. I can't help with that but you might find some ALSA.conf examples online. Can you specify output format as 'surround4.0'?
If your test rig resembles what will be your final setup, perhaps the Richard Taylor methods using ecasound will prevent some frustration. Or, look into Charlie Laub's new modular filters, which run in ecasound and give more control than the RT series.
Cheers,
Frank
Hi Franco,
thank you for the reply. I looked at Charlie's thread, but I am not sure why another layer of complexity -
- is inserted into already complex ALCA framework. So I try to continue in my direction.
The problem appears to be lack of good documentation re ALSA.
I will move out of your thread as it really does not fit; just one last question. Is the configuration file your post 74 working?
Kindest regards,
M
thank you for the reply. I looked at Charlie's thread, but I am not sure why another layer of complexity -
Code:
ecasoundThe problem appears to be lack of good documentation re ALSA.
I will move out of your thread as it really does not fit; just one last question. Is the configuration file your post 74 working?
Kindest regards,
M
Within ALSA, there exists a wrapper to host LADSPA filters. It is the 'type LADSPA' plugin. The plugin is on the same 'layer' as ecasound, which is an alternate host for the same filters except it is more powerful and robust than the ALSA plugin. For example, Charlie Laub's modular filter set won't run in the ALSA wrapper but they do run in ecasound. So as I said, you will save yourself some headaches and gain some options by using ecasound. ...ASSUMING you are not working in a clock switching environment.
This thread, of course, concerns extracting the best crossover filter results using clock switching hardware with support from a customized kernel.
All the best,
Frank
In a sense, yes. Both do the same math at nearly the same place in the signal chain. In the end, you will probably want to think about sample rates and how they affect sound quality. It will depend on many factors, not the least of which is the resolution of your DAC/sound card. But to get you going, here are a few links.
http://lac.zkm.de/2005/papers/julien_claassen.pdf
ecasound
Ecasound Examples
Digital Crossover/EQ with Open-Source Software: HOWTO | Richard's Stuff
Cheers,
Frank
Hi Frank,
thank you for the reply; I have sort of success, please see Charlie's thread if interested.
In fact, in the end, I would like to implement brutefir/jconvolver for FIR filters. But I do not know how to deal with the fact that music files have different sample rates.
Kindest regards,
M
thank you for the reply; I have sort of success, please see Charlie's thread if interested.
In fact, in the end, I would like to implement brutefir/jconvolver for FIR filters. But I do not know how to deal with the fact that music files have different sample rates.
Kindest regards,
M
update to 3-way LADSPA crossover in ALSA
Below is an update that addresses an unusual issue found in the 3-way ALSA crossover listed in post #74 of this thread. Using 6 data channels in ALSA resulted in rare random shifts in the signal carried by each DAC output channel. A channel that was playing a tweeter signal might shift to midrange or bass - usually preceded by an audible 'tick'. I remedied this by adding two more channels in ALSA and distributing the filter work more widely. Note that the ttable alignments seem to have no rhyme or reason. In my system they are set so that each of the DACs process a stereo pair of the same frequency range. The easiest way to map the channels is via the ttable. Change the '1' after some of the output pairs to '0', which mutes that channel. You can trace fewer signals more confidently.
CPU draw for this version is a bit higher. A 176K file draws about 80% CPU playing via Squeezelite. Still, I haven't had issues with data underruns when the player is initiated using: squeezelite -z -a 8192:2048::0
By the way, I also tested the same filter topology using Richard Taylor's 2-pole filters. The CPU draw was nearly identical. Rolloff was obviously broader than with the Linkwitz-Riley 4-pole configuration below.
All the best, as always...
Below is an update that addresses an unusual issue found in the 3-way ALSA crossover listed in post #74 of this thread. Using 6 data channels in ALSA resulted in rare random shifts in the signal carried by each DAC output channel. A channel that was playing a tweeter signal might shift to midrange or bass - usually preceded by an audible 'tick'. I remedied this by adding two more channels in ALSA and distributing the filter work more widely. Note that the ttable alignments seem to have no rhyme or reason. In my system they are set so that each of the DACs process a stereo pair of the same frequency range. The easiest way to map the channels is via the ttable. Change the '1' after some of the output pairs to '0', which mutes that channel. You can trace fewer signals more confidently.
CPU draw for this version is a bit higher. A 176K file draws about 80% CPU playing via Squeezelite. Still, I haven't had issues with data underruns when the player is initiated using: squeezelite -z -a 8192:2048::0
By the way, I also tested the same filter topology using Richard Taylor's 2-pole filters. The CPU draw was nearly identical. Rolloff was obviously broader than with the Linkwitz-Riley 4-pole configuration below.
All the best, as always...
Code:
pcm.!default {
type plug
slave.pcm filter1
}
ctl.!default {
type hw
card 0
}
pcm.filter1 {
type ladspa
slave.pcm delay
path "/usr/lib/ladspa"
channels 8
plugins
{
0 {
label RTlr4lowpass
policy none
input.bindings.0 "Input"
output.bindings.2 "Output"
input { controls [ 180 ] } # [frequency (Hz)]
}
1 {
label RTlr4hipass
policy none
input.bindings.0 "Input"
output.bindings.4 "Output"
input { controls [ 4000 ] }
}
2 {
label RTlr4lowpass
policy none
input.bindings.1 "Input"
output.bindings.3 "Output"
input { controls [ 180 ] }
}
3 {
label RTlr4hipass
policy none
input.bindings.1 "Input"
output.bindings.5 "Output"
input { controls [ 4000 ] }
}
4 {
label RTlr4hipass
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [ 180 ] }
}
5 {
label RTlr4hipass
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [ 180 ] }
}
6 {
label RTlr4lowpass
policy none
input.bindings.0"Input"
output.bindings.6 "Output"
input { controls [ 4000 ] }
}
7 {
label RTlr4lowpass
policy none
input.bindings.1 "Input"
output.bindings.7 "Output"
input { controls [ 4000 ] }
pcm.delay {
type ladspa
slave.pcm speaker
path "/usr/lib/ladspa"
channels 8
plugins
{
0 {
label delay_5s
policy none
input.bindings.2 "Input"
output.bindings.2 "Output"
input { controls [ 0.012 1 ] } # [delay in seconds, wet/dry (0=all input, 1=all output)]
}
1 {
label delay_5s
policy none
input.bindings.3 "Input"
output.bindings.3 "Output"
input { controls [ 0.012 1 ] }
}
2 {
label delay_5s
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [ 0.0 0 ] }
}
3 {
label delay_5s
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [ 0.0 0 ] }
}
4 {
label delay_5s
policy none
input.bindings.4 "Input"
output.bindings.4 "Output"
input { controls [ 0.0 0 ] }
}
5 {
label delay_5s
policy none
input.bindings.5 "Input"
output.bindings.5 "Output"
input { controls [ 0.0 0 ] }
}
6 {
label delay_5s
policy none
input.bindings.6 "Input"
output.bindings.6 "Output"
input { controls [ 0.0 0 ] }
}
7 {
label delay_5s
policy none
input.bindings.7 "Input"
output.bindings.7 "Output"
input { controls [ 0.0 0 ] }
}
}
}
pcm.speaker {
type plug
slave {
pcm "t-table"
channels 8
rate "unchanged"
}
}
pcm.t-table {
type route
slave {
pcm "hw:0,0"
channels 8
}
ttable {
0.6 0
1.7 0
2.2 1
3.6 1
4.1 1
5.5 1
6.0 1
7.4 1
}
}
pcm.plughw.slave.rate = "unchanged";Here is an update on a few minor points:
1. I just placed the crossover code I am now using on github. I find that the Linkwitz-Riley 4 pole filters are unnecessarily sharp when used between the midrange and the tweeter. [I'm still using them for bass, however.] The result when used between tweeter and mid is a loss of spatial resolution. Phase effects, no? With the 2 pole filter much more spatial detail is heard. This spatial effect is noticeable over a broad range of cutoff frequencies for the upper transition.
2. With my BBB/Hermes/Cronus/Botic player I have noticed that turn-on and initialization order matters. If the DAC boards are powered after the BBB is initialized, then the channel alignments are not correct. For example, tweeter signals come through the woofers, etc. The channel alignments at the bottom of the asound.conf file work for me with my current system config. However, you may have to work out your own using speaker-test and the 1 or 0 (on/off) - the third parameter of the routing plugin.
3. I have some room nodes so out of curiosity I tried the equalization filter on bass. It was worse than nothing! It killed the bass dynamics and limited the 'punch'. This should be revisited after I identify the exact frequencies that need treatment, and exactly how much to dial them down. ...new 'lektronix need to burn-in and stabilize first...
1. I just placed the crossover code I am now using on github. I find that the Linkwitz-Riley 4 pole filters are unnecessarily sharp when used between the midrange and the tweeter. [I'm still using them for bass, however.] The result when used between tweeter and mid is a loss of spatial resolution. Phase effects, no? With the 2 pole filter much more spatial detail is heard. This spatial effect is noticeable over a broad range of cutoff frequencies for the upper transition.
2. With my BBB/Hermes/Cronus/Botic player I have noticed that turn-on and initialization order matters. If the DAC boards are powered after the BBB is initialized, then the channel alignments are not correct. For example, tweeter signals come through the woofers, etc. The channel alignments at the bottom of the asound.conf file work for me with my current system config. However, you may have to work out your own using speaker-test and the 1 or 0 (on/off) - the third parameter of the routing plugin.
3. I have some room nodes so out of curiosity I tried the equalization filter on bass. It was worse than nothing! It killed the bass dynamics and limited the 'punch'.
This should be revisited after I identify the exact frequencies that need treatment, and exactly how much to dial them down. ...new 'lektronix need to burn-in and stabilize first...2. This might be related to your I2C initialization code on BBB. It should not be started before DAC is powered.
3. For solving room modes you might need different solution than equalization. Check this: https://mehlau.net/audio/multisub_geddes/
3. For solving room modes you might need different solution than equalization. Check this: https://mehlau.net/audio/multisub_geddes/
Thanks for the interesting article on subs, Miero! Interesting concept to create more modes rather than (try to) eliminate them. Now I must get my calibration microphone repaired!
I'm still working on the cabinet for amps and the DAC. When my speaker enclosures are re-built to match I will be adding a port to the midrange cabinets, which will allow them to play flat down to perhaps 80Hz. Then the 2 woofers could function as pure 'subs'.
For any who want to try this you can create a mono subwoofer signal using the ttable in the ALSA asound.conf code. In my 6 channel system it would look something like this (untested):
I have made satisfactory progress on my own room modes simply by aiming the woofers slightly up and out. The new high-WAF woofer enclosures will have driver baffles directed that way...
I'm still working on the cabinet for amps and the DAC. When my speaker enclosures are re-built to match I will be adding a port to the midrange cabinets, which will allow them to play flat down to perhaps 80Hz. Then the 2 woofers could function as pure 'subs'.
For any who want to try this you can create a mono subwoofer signal using the ttable in the ALSA asound.conf code. In my 6 channel system it would look something like this (untested):
Code:
ttable {
0.7 0
1.3 0
2.1 .5 #left sub
2.5 .5
3.5 .5 #right sub
3.1 .5
4.2 1 #left tweeter
5.6 1 #right tweeter
6.0 1 #left mid
7.4 1 #right mid
}I have made satisfactory progress on my own room modes simply by aiming the woofers slightly up and out. The new high-WAF woofer enclosures will have driver baffles directed that way...
Last edited:
I wonder if any of you fine gentlemen or ladies can help me out...
I'm trying to implement a 3 way (6 channel) crossover on my raspberry pi, output via HDMI. I got the HDMI working, which I thought would be the hard part ... ha!
I have been trying to get audio out using ecasound as ladspa host to alsa. I can get audio out to work, but not consistently. Here's the issue (as posted on Richard Taylor's site)
So, I thought I'd follow the instructions on the beginning of this thread. I'm trying to use the .asoundrc file from page 7 of the thread. However, the RTplugins don't seem to work. I copied them to the right place...
Anyway, I'd rather use @claub's filters because they seem to be more performant.
To make matters more interesting, I don't want to just spit out channel 1-> 1 and 2->2 and so on. My 7.1 receiver has a dead Front right channel, so I need to avoid that, so I *need* to use an 8 channel configuration to run 6 channels.
Is there anyone using a ladspa on alsa configuration that does something similar?
Thanks,
James
PS: when I try to use the .asoundrc file from above I get the following error message:
I'm trying to implement a 3 way (6 channel) crossover on my raspberry pi, output via HDMI. I got the HDMI working, which I thought would be the hard part ... ha!
I have been trying to get audio out using ecasound as ladspa host to alsa. I can get audio out to work, but not consistently. Here's the issue (as posted on Richard Taylor's site)
So, I thought I'd follow the instructions on the beginning of this thread. I'm trying to use the .asoundrc file from page 7 of the thread. However, the RTplugins don't seem to work. I copied them to the right place...
Anyway, I'd rather use @claub's filters because they seem to be more performant.
To make matters more interesting, I don't want to just spit out channel 1-> 1 and 2->2 and so on. My 7.1 receiver has a dead Front right channel, so I need to avoid that, so I *need* to use an 8 channel configuration to run 6 channels.
Is there anyone using a ladspa on alsa configuration that does something similar?
Thanks,
James
PS: when I try to use the .asoundrc file from above I get the following error message:
Code:
aplay -D filter1 /media/usbstick/chan_labels_6.wav
ALSA lib conf.c:1697:(snd_config_load1) _toplevel_:166:0:Unexpected char
ALSA lib conf.c:3417:(config_file_open) /home/pi/.asoundrc may be old or corrupted: consider to remove or fix it
ALSA lib conf.c:3339:(snd_config_hooks_call) function snd_config_hook_load returned error: Invalid argument
ALSA lib conf.c:3788:(snd_config_update_r) hooks failed, removing configuration
aplay: main:722: audio open error: Invalid argument
Last edited:
Greetings! Perhaps some of my experiences can help, but they were obtained using specific equipment that is very different from yours. Still, it would be pretty cool to be able what you want to do. Here goes...
First, I have been successful using ecasound for a 2-way system (4 channels, using RT filters) and if you know you will only ever want to use a single sample rate, then I would first pursue the ecasound method. Unfortunately, I did not save my working ecasound configurations but that doesn't seem to be the main problem. I think you have to pay attention the the ecasound channel mapping for each filter result. Do I remember correctly that "-chorder:0,0,0,0,0,0,0,0" sends channel 0 to every output channel? If you can map your channels in ecasound it will be faster and easier than doing it in ALSA, but if you want to try ALSA plugins for LADSPA filters, then might as well map the channels using a t-table, described below.
You don't say what OS is running on the Pi, but of course it needs to manage your 6/8 channels and that is done in ALSA. There are several places where that configuration can occur, including .asoundrc. Channel routing in ALSA - at least on the BBB using the Botic kernel - does not make sense to me but it is what it is. In ALSA you can create a 't-table' to move things around as needed, but the syntax is finicky. For example, a 'route' type plug doesn't work following a 'ladspa' type plug - it needs to follow a 'plug' type plug.
I was unable to get Charlie Laub's filters running in ALSA and I have not revisited that problem, whereas the R Taylor filters do work. For simple Linkwitz-Riley filter curves, I don't think there is any difference between the two sets in terms of the math. So it might be interesting to just try my current configuration using ALSA LADSPA plugins and see if anything promising happens. Again, the potential advantage is that ALSA itself doesn't force resampling, which can draw a lot of CPU load and to some extent degrade the SQ. If you choose to test the whole thing, use the asound.conf file that is on GitHub. URL in first post of this thread.
This could be something as simple as a typo or a minor syntax problem, or it could indicate that your basic ALSA configuration can't handle all the needed channels and needs to be configured specifically for 8. Or there are many other possible sources of this error, which I have not encountered.
Now, this is just a blind suggestion if you want to try ALSA LADSPA plugins... I can't test it or help much with troubleshooting, but make an asound.conf file in the directory /etc. Put in a default plug that points to a route plug and see what happens when you mess with the routing. Maybe like so:
In the table, the first digit is the source channel number, the digit after the period is the output channel number, and the third digit after the space is the contribution factor (0='off', 1=100%, etc.). You see that in my setup, source channels 0 and 1 are routed to output channels that are not used. And as for what output channel arrives at which location...0, 1, and 2 arrive at the left side and 4, 5, and 6 go to the right. I had to work out this hardware configuration by turning off all but one channel at a time using the third digit of the t-table. Doing this is how (I imagine) you can ultimately avoid the one bad channel in your amp. (note, the comments delimited by the '#' probably won't apply to your situation). With ecasound channel order you should also be able to discover the correct channel routes. In that case you probably don't need the t-table, or perhaps it could be all symmetrical, like "0.0 1", etc.
I know this isn't much to start with, but it is a start at least...
First, I have been successful using ecasound for a 2-way system (4 channels, using RT filters) and if you know you will only ever want to use a single sample rate, then I would first pursue the ecasound method. Unfortunately, I did not save my working ecasound configurations but that doesn't seem to be the main problem. I think you have to pay attention the the ecasound channel mapping for each filter result. Do I remember correctly that "-chorder:0,0,0,0,0,0,0,0" sends channel 0 to every output channel? If you can map your channels in ecasound it will be faster and easier than doing it in ALSA, but if you want to try ALSA plugins for LADSPA filters, then might as well map the channels using a t-table, described below.
You don't say what OS is running on the Pi, but of course it needs to manage your 6/8 channels and that is done in ALSA. There are several places where that configuration can occur, including .asoundrc. Channel routing in ALSA - at least on the BBB using the Botic kernel - does not make sense to me but it is what it is. In ALSA you can create a 't-table' to move things around as needed, but the syntax is finicky. For example, a 'route' type plug doesn't work following a 'ladspa' type plug - it needs to follow a 'plug' type plug.
I was unable to get Charlie Laub's filters running in ALSA and I have not revisited that problem, whereas the R Taylor filters do work. For simple Linkwitz-Riley filter curves, I don't think there is any difference between the two sets in terms of the math. So it might be interesting to just try my current configuration using ALSA LADSPA plugins and see if anything promising happens. Again, the potential advantage is that ALSA itself doesn't force resampling, which can draw a lot of CPU load and to some extent degrade the SQ. If you choose to test the whole thing, use the asound.conf file that is on GitHub. URL in first post of this thread.
This could be something as simple as a typo or a minor syntax problem, or it could indicate that your basic ALSA configuration can't handle all the needed channels and needs to be configured specifically for 8. Or there are many other possible sources of this error, which I have not encountered.
Now, this is just a blind suggestion if you want to try ALSA LADSPA plugins... I can't test it or help much with troubleshooting, but make an asound.conf file in the directory /etc. Put in a default plug that points to a route plug and see what happens when you mess with the routing. Maybe like so:
Code:
pcm.!default {
type plug
slave {
pcm "t-table"
channels 8
}
}
ctl.!default {
type hw
card 0
}
pcm.t-table {
type route
slave {
pcm "hw:0,0"
channels 8
}
ttable {
0.7 0
1.3 0
2.1 1 #left bass
3.5 1 #right bass
4.2 1 #left tweeter
5.6 1 #right tweeter
6.0 1 #left mid
7.4 1 #right mid
}
}In the table, the first digit is the source channel number, the digit after the period is the output channel number, and the third digit after the space is the contribution factor (0='off', 1=100%, etc.). You see that in my setup, source channels 0 and 1 are routed to output channels that are not used. And as for what output channel arrives at which location...0, 1, and 2 arrive at the left side and 4, 5, and 6 go to the right. I had to work out this hardware configuration by turning off all but one channel at a time using the third digit of the t-table. Doing this is how (I imagine) you can ultimately avoid the one bad channel in your amp. (note, the comments delimited by the '#' probably won't apply to your situation). With ecasound channel order you should also be able to discover the correct channel routes. In that case you probably don't need the t-table, or perhaps it could be all symmetrical, like "0.0 1", etc.
I know this isn't much to start with, but it is a start at least...
OK, ok... I went back to ecasound
I had it backwards. -chorder:2,1 is the same as ('out1,out2' = 'in2,in1'), and zero is mute.
So to channel map, have you run run iterations of the following command?
where everything in -chorder is zero except one position of the sequence, which then gets either a 1 or a 2 - the potential input channels? ... or does that not work?
If not, then ALSA might be the issue and if you specify an 8 channel default, as I mentioned above, you might only need to send ecasound output to the default plugin you specified.
something like: -o:alsa,'default'
I remember it took me a while to arrive at the exact output (-o:xxx) syntax. Sorry, not sure if default needed to be in single or double quotes or exactly what eventually succeeded. You should be able to route the output to any of the ALSA plugins that you can see when you execute 'aplay -L'. [On the BBB, output to alsahw,0,0 did work for me.]
I also seem to recall using only one loop command before, and one channel map command after the filter chains. But again, those memories are not fresh. Unfortunately, that configuration info was in a file that was accidentally deleted.
Good luck!
I had it backwards. -chorder:2,1 is the same as ('out1,out2' = 'in2,in1'), and zero is mute.
So to channel map, have you run run iterations of the following command?
Code:
pi@raspberrypi:/media/usbstick $ ecasound -tl -i chan_labels_6.wav -f:16,8,44100 -eadb:-2 -o:alsahw,0,0 -chorder:1,2,3,4,5,6,7,8If not, then ALSA might be the issue and if you specify an 8 channel default, as I mentioned above, you might only need to send ecasound output to the default plugin you specified.
something like: -o:alsa,'default'
I remember it took me a while to arrive at the exact output (-o:xxx) syntax. Sorry, not sure if default needed to be in single or double quotes or exactly what eventually succeeded. You should be able to route the output to any of the ALSA plugins that you can see when you execute 'aplay -L'. [On the BBB, output to alsahw,0,0 did work for me.]
I also seem to recall using only one loop command before, and one channel map command after the filter chains. But again, those memories are not fresh. Unfortunately, that configuration info was in a file that was accidentally deleted.
Good luck!
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.