Frank, one of the two of us is reading the configuration option incorrectly.
The man page tells me
Which I interpret as buffer time * period count so 80*4 = 320... but maybe that's wrong :shrug:
I'll keep tweaking and report back
@Charlie, on certain tracks, I noticed that the bass was getting distorted using my filters. (posted below). Am I overdriving the bass/getting clipping. If so, should I aim to have the peak levels at 0db and bring everything else down to match? I tried reducing the level of my woofer by 3db and reducing the mid and tweeter by 3db also. That seemed to help, but I just want to make sure I understand the mechanism.
Thanks,
James
Thanks,
James
Code:
#asound rc new version jrubinstein - experimental with charlies plugin
pcm.!default {
type plug
slave.pcm filtereq
}
ctl.!default {
type hw
card 0
}
pcm.filtereq {
type ladspa
slave.pcm filtercross
path "/usr/lib/ladspa"
channels 8
plugins
{
0 {
label ACDf
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [28 1 6 120 1 1 1] }
}
1{
label ACDf
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [26 1 -6 164 4 1 1] }
}
2{
label ACDf
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [26 1 -6 250 4 1 1] }
}
3{
label ACDf
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [26 1 6 193 5 1 1] }
}
4{
label ACDf
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [28 1 6 120 1 1 1] }
}
5{
label ACDf
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [26 1 -6 164 4 1 1] }
}
6{
label ACDf
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [26 1 -6 250 4 1 1] }
}
7{
label ACDf
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [26 1 6 193 5 1 1] }
}
8{
label ACDf
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [22 1 0 40 1 1 1] } #2nd order highpass at 40 hz to act as subsonic filter
}
9{
label ACDf
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [22 1 0 40 1 1 1] } #2nd order highpass at 40 hz
}
10{
label ACDf
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [22 1 0 40 1 1 1] } #2nd order highpass at 40 hz to act as subsonic filter
}
11{
label ACDf
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [22 1 0 40 1 1 1] } #2nd order highpass at 40 hz
}
}
}
pcm.filtercross {
type ladspa
slave.pcm speaker
path "/usr/lib/ladspa"
channels 8
plugins
{
0 {
label ACDf #lowpass for woofer output to channel2
policy none
input.bindings.0 "Input"
output.bindings.2 "Output"
input { controls [21 -1 -3 300 0.5 1 1] } # [filter type polarity dbgain frequency q]
}
1 {
label ACDf #lowpass for woofer output to channel3
policy none
input.bindings.1 "Input"
output.bindings.3 "Output"
input { controls [21 -1 -3 300 0.5 1 1] } #2nd order lowpass at 300hz
}
2 {
label ACDf #highpass for tweeter output to channel4
policy none
input.bindings.0 "Input"
output.bindings.4 "Output"
input { controls [22 -1 -16 3000 1 1 1] } #2nd order highpass at 3000 hz
}
3 {
label ACDf #highpass for tweeter output to channel4 filter 2
policy none
input.bindings.0 "Input"
output.bindings.4 "Output"
input { controls [22 1 0 3000 1 1 1] } #2nd order highpass at 3000 hz
}
4 {
label ACDf #highpass for tweeter output to channel4
policy none
input.bindings.1 "Input"
output.bindings.5 "Output"
input { controls [22 -1 -16 3000 1 1 1] } #2nd order highpass at 3000 hz
}
5 {
label ACDf #highpass for tweeter output to channel4 filter 2
policy none
input.bindings.1 "Input"
output.bindings.5 "Output"
input { controls [22 1 0 3000 1 1 1] } #2nd order highpass at 3000 hz
}
6 {
label ACDf #lowpass1 for mid output to channel0
policy none
input.bindings.0 "Input"
output.bindings.6 "Output"
input { controls [21 1 -7 3000 0.707 1 1] } # 2nd order lowpass at 3000 hz -4db cut
}
7 {
label ACDf #lowpass2 for mid output to channel0
policy none
input.bindings.0 "Input"
output.bindings.6 "Output"
input { controls [21 1 0 3000 0.707 1 1] } # 2nd order lowpass at 3000 hz
}
8 {
label ACDf #highpass for mid output to channel0
policy none
input.bindings.0 "Input"
output.bindings.6 "Output"
input { controls [22 1 0 300 0.5 1 1] } # 2nd order highpass at 300 hz
}
9 {
label ACDf #lowpass1 for mid output to channel1
policy none
input.bindings.1 "Input"
output.bindings.7 "Output"
input { controls [21 1 -7 3000 0.707 1 1] } # 2nd order lowpass at 3000 hz -4db cut
}
10 {
label ACDf #lowpass2 for mid output to channel1
policy none
input.bindings.1 "Input"
output.bindings.7 "Output"
input { controls [21 1 0 3000 0.707 1 1] } # 2nd order lowpass at 3000 hz
}
11 {
label ACDf #highpass for mid output to channel1
policy none
input.bindings.1 "Input"
output.bindings.7 "Output"
input { controls [22 1 0 300 0.5 1 1] } # 2nd order highpass at 300 hz
}
}
}
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.0 0 # audio = left woofer channel = left front
1.1 0 # channel in.channel out on/off
2.0 1 #left bass this gives me the low filter for left woofer onto channel 0 = front left
3.7 1 #right bass = SBR
4.6 1 #left tweeter = SBL
5.5 1 #right tweeter = Surr Right
6.4 1 #left mid = surr left
7.3 1 #right mid = center
}
}
pcm.plughw.slave.rate = "unchanged";Greetings James,
I wonder about some of the structure in your plugs. I have had success adding one filter after another along a single input-output channel. So I believe that should work as you adjust the signal in your first plugin. However - and I'm not saying it doesn't work - I'm suspicious of the second plugin. For example, (in the box below) both of the filters input from channel 0 and output to channel 4. I would expect the content of channel 4 to be limited to the effects of only the second (or last) 0 ->4 filter. This could seriously affect phase and delta dB. I think you should devise a test to be certain that your routing scheme among the various filters is, in fact, additive. I would expect the I/O routing to be better as 0 -> 0 -> 4 or 0 -> 4 -> 4.
Code:
2 {
label ACDf #highpass for tweeter output to channel4
policy none
input.bindings.0 "Input"
output.bindings.4 "Output"
input { controls [22 -1 -16 3000 1 1 1] } #2nd order highpass at 3000 hz
}
3 {
label ACDf #highpass for tweeter output to channel4 filter 2
policy none
input.bindings.0 "Input"
output.bindings.4 "Output"
input { controls [22 1 0 3000 1 1 1] } #2nd order highpass at 3000 hzAlso, an experience to share... I found on the BBB that if I serially modified a signal too much, or too asymmetrically (or something, I'm not quite sure) then the channel numbers would randomly flip around during the filtration. Tweeters could get highs for a while, then bass, then anything else, and not necessarily from the same side. So that is why my 3-way stereo crossover uses 8 channels. It distributed the work in a way that eliminated that very undesirable behavior. So just a mini-heads up there... If something wonky starts happening, I would start by dividing serial chains among more plugs - fewer filters per channel per plug. That said, it is quite possible that ALSA in the RPi has different behaviors than ALSA in the BBB.
Eventually, I think we need to test our crossovers on a scope using white or pink impulses. Just to be sure the phase is what we think it is... Has anybody done that with ecasound?
Best,
Frank
With a little more consideration of this in the background, I think when I get to this stage I will simply substitute an audibly identifiable LADSPA plugin into each filter position. One location at a time, relative to the flow of effects for each channel number. From the computer music toolkit, perhaps pink noise (id 1844) would suffice. If I were playing the output through my good speakers, I might add a limiter plugin just before the t-table for safety. Then simply step through the chain and be sure some pink noise comes out when it is generated at each location that will otherwise filter the signal?
Of course, an FFT spectrum analyzer might be quicker (and more to the point) - I've never used one. Anybody have software that they recommend?
Cheers,
Frank
Although I did not go through all your filters I can make some guesses and provide some guidance.
I think you mentioned you used my ACD-L spreadsheets. These will plot the overall filter for each driver (that is the overall filtering you get with all the filters you are using for a given driver). From what I believe, any time there is overall boost (the overall filter exceeds 0dB) what can happen is that the computer must truncate the signal down to the allowable output range (e.g. -1.0 to 1.0 for floating point representation). This is like very hard clipping, and it is usually very audible.
I try to design my crossovers so that the level for each driver NEVER exceeds 0dB. In that way I am assured that digital clipping will never happen. Let's say for your least sensitive driver you have to boost the signal by 6dB so that it matches the level of the other drivers. To eliminate clipping you must reduce this by 6dB down to 0dB, or more if any of the filters for that driver have peaking. But to keep things consisting you now have to reduce all the other drivers by 6dB as well so the relative levels between them remain the same.
This causes some problems. Your system is only as loud as the driver with the least sensitivity and its amplifier. Unlike good old analog audio circuits, the computer must output the digital representation of the audio via a DAC. Most DACs only have the capability of 1Vrms output. This is pretty weak and will not be able to driver some amplifiers to their maximum output power. Remember that this 1Vrms (or whatever the voltage limit of the DAC) is the PEAK voltage output. Music is dynamic and a good quality recording has an average level that might be 10dB or even 20dB BELOW the peak level. What I have found is that I can turn up the volume to maximum only to find that the resulting audio is just not all that "loud". This is a problem that is inherent in the system. Unlike an analog preamp that might be capable of 5Vrms peak output, you can not turn up the gain and make the output signal louder with digital audio if you do not want to incur digital clipping of the signal.
I make sure that my DACs can drive my amplfiers. I look for 2Vrms output DACs and/or amplifiers with 1Vrms or less input sensitivity. For lower sensitivity drivers try to find amplifiers with more gain in the amplifier itself.
You may be experiencing a similar problem.
Within ecasound and LADSPA there is essentially infinite headroom so the problem isn't there. With a float representation, the audio signal is bounded by -1 and 1, while a single precision float can represent numbers out to something like 3x10^38 (although with decreasing accuracy).
You can use a measurement package like ARTA to do this. It will show the frequency response, so that each time you "turn on" a new filter you can see the difference. Note with my filters you can use type 0 with no gain and the filter is there but not doing anything. Then you can change the type to something that will show up easily, like an EQ peak or notch, and turn each one on in turn to make sure they are working in the desired way.
I suspected as much...
Okay, I will have to reduce the overall level to =< 0
So, this is an advantage of ecasound? Why wouldn't ALSA represent the filter the same way... it's just calling a LADSPA plugin, no?
I'll try to get my overall levels back to 0 and see how that goes.
Thanks,
James
Hmmm, thanks for the thoughts, Frank. I'll have to check it out to be sure, but I'm definitely getting the first filter on the tweeter, because if that one isn't there, it would be 16db higher, which is clearly audible. I could run pink noise through each driver and check if the rolloffs and EQ are present. My ears tell me that something is happening, so I assume the filters are working.
I'll keep an eye (or ear) on it
Thanks,
James
posted my tutorial, would love to know what you guys think
http://www.diyaudio.com/forums/pc-b...i-music-server-dsp-crossover.html#post4646529
goes to
Raspberry Pi Music Server with Built-in Crossover and DSP
http://www.diyaudio.com/forums/pc-b...i-music-server-dsp-crossover.html#post4646529
goes to
Raspberry Pi Music Server with Built-in Crossover and DSP
Gave the Instructable a quick scan - comprehensive and easy to read! Nice!
Here is an essential reference for ALSA manipulations:
ALSA project - the C library reference: PCM (digital audio) plugins
Regarding the 'policy' operator in type-plug plugins, it can have any of several functions delineated by a string. The entry we use there keeps things predictable.
Code:
pcm.name {
type plug # Automatic conversion PCM
slave STR # Slave name
# or
slave { # Slave definition
pcm STR # Slave PCM name
# or
pcm { } # Slave PCM definition
[format STR] # Slave format (default nearest) or "unchanged"
[channels INT] # Slave channels (default nearest) or "unchanged"
[rate INT] # Slave rate (default nearest) or "unchanged"
}
route_policy STR # route policy for automatic ttable generation
# STR can be 'default', 'average', 'copy', 'duplicate'
# average: result is average of input channels
# copy: only first channels are copied to destination
# duplicate: duplicate first set of channels
# default: copy policy, except for mono capture - sum
ttable { # Transfer table (bi-dimensional compound of cchannels * schannels numbers)
CCHANNEL {
SCHANNEL REAL # route value (0.0 - 1.0)
}
}
rate_converter STR # type of rate converter
# or
rate_converter [ STR1 STR2 ... ]
# type of rate converter
# default value is taken from defaults.pcm.rate_converterBTW, I have never gotten a t-table to work in a type-plug plugin...
Greetings Charlie,
On a 'snow day' here in Colorado I went back to the segmentation fault question when using ACDf in ALSA. Progress. I had been using an OS image including the Botic kernel (external clock input and switching) - based on Debian 7.5 'wheezy'. I installed a fresh image of Debian 8.3 'jessie' and tried the ACDf plugins in ALSA. They seem to work. So the next step is to now change the 'jessie' kernel to add clock switching and other Botic functions. Then I can actually hear what is happening. ...will update as progress is made...
Frank
ACDf executing in ALSA plus Botic kernel clock-switching is now functioning on top of Debian 8.3 'jessie'.
Miero's instructions were a piece of cake: http://www.diyaudio.com/forums/twisted-pear/258254-support-botic-linux-driver-135.html#post4505281Significant work remains to move all of my control scripts and services to the newer system. First, I want to strip unnecessary packages from the system - like the windows manager and web server. Once that is done, I'll go 'all-in' with a calibration setup and see how best to blend my drivers. ...will publish impressions/experiences and a 'how-to' here when all is singing smoothly...
Frank
Guys,
First, I did try optimizing ACDf compilation specifically for the BBB and CPU use is essentially unaffected.
Second, I find that ACDf filter 22 { controls [22 0 -1 4000 0.5] } gives ALSA trouble. I get small drop-outs and occasional small time-compressions at high sample rates. I have been unable, as yet, to externally increase buffer and period size in ALSA. All attempts have caused the system to default to 2-channel playback. Changing Squeezelite parameters does not change the alsa buffers, which I believe are indicated by 'hw_params' from the active system:
Third, comparing Debian 8.3 to 7.5 (each w/ Botic kernel) I find that the older version is more efficient with CPU while doing crossover work. The same crossover (using RT linkwitz-riley plugs since they work on both systems) running from the same squeezelite settings and source files is about 15% more efficient in Debian 7.5. This is at first blush, but it does indicate an avenue for optimization.
Bottom line: I'll give this a rest while I work on other system components. Your suggestions will be much appreciated and as ideas come to me, I'll follow up...
Frank
First, I did try optimizing ACDf compilation specifically for the BBB and CPU use is essentially unaffected.
Second, I find that ACDf filter 22 { controls [22 0 -1 4000 0.5] } gives ALSA trouble. I get small drop-outs and occasional small time-compressions at high sample rates. I have been unable, as yet, to externally increase buffer and period size in ALSA. All attempts have caused the system to default to 2-channel playback. Changing Squeezelite parameters does not change the alsa buffers, which I believe are indicated by 'hw_params' from the active system:
Third, comparing Debian 8.3 to 7.5 (each w/ Botic kernel) I find that the older version is more efficient with CPU while doing crossover work. The same crossover (using RT linkwitz-riley plugs since they work on both systems) running from the same squeezelite settings and source files is about 15% more efficient in Debian 7.5. This is at first blush, but it does indicate an avenue for optimization.
Bottom line: I'll give this a rest while I work on other system components. Your suggestions will be much appreciated and as ideas come to me, I'll follow up...
Frank
Hi James, I have been testing using squeezelite, which I optimized some time ago for a broad range of sample frequencies. The consensus from web sources is that the ALSA buffer and period size are too small. Until I find a way to increase them I don't want to bother with the other vagaries of changing the OS. It contains a newer version of Python that is wreaking havoc with my control scripts!
Rather than asound.rc, I prefer putting the ALSA config into /etc/asound.config. Functionally it is just about the same. ...a little more general than the user-specific settings of asound.rc. I believe there is a way to specify alsa's buffer and period, but the state of ALSA documentation is dismal. It may take another 'snow day' before that research begins. Overall, I'm happy with what I learned and the devil will be in the details to apply ACDf in Debian 8.3 for hi-rez source files.
Cheers,
Frank
If you look at the ACDf code you will see that things are pretty much the same for all the filters in terms of calculations. I would probably look elsewhere for bottlenecks.
I'm curious what optimization flags you used when compiling the plugins on your platform? Can you post the complete compiler CFLAGS string from the Makefile?
I have not looked at the code but trust implicitly that it is optimized.
It occurs to me that I didn't test the alsa-LADSPA plugin without the reverse polarity flag - in case that was a source of 'confusion'. Hope not, as polarity is a great option! Though, for me its one amp channel/driver so easy to simply reverse speaker wires....not sure all of these added flags are as good as possible. For example, I think there are additional options for 'neon'. I just gave it a shot. GCC is version 4:4.9.2-2. I'm not sure what '-DPIC' does so I left it in.
Code:
CC = gcc
LD = g++
CFLAGS = -I. -Ofast -Wall -c -fPIC -DPIC -march=armv7-a -mtune=cortex-a8 -mfloat-abi=hard -mfpu=neonAnyway, I'll get back to the ALSA stuff in due course. Ideas will come to me while working on cabinets (which are coming slow but looking good). [BTW, your power control system is cool!
]Cheers,
Frank
Further motivation to wait on updating to Debian 8.3 Jessie: Volumio2, based on jessie, has pared the OS to the bare minimum. Volumio2 is still in beta and not yet ported to the BBB. However, it will include significant enhancements in 'adaptability', with plugins of all kinds and APIs to customize one's own. The previous version (1.55) for the BBB can be converted with the Botic kernel to perform clock-switching. Should that also be possible with Volumio2, then it would be a great jump-start because of the many audio-specific enhancements built-in.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.