Isn't it as simple as that you indeed get steeper stop bands as you add those LP filters in series - yes, further away form the Fo as you add them but still, when summed, they would add less to the result and thus, "ripple"?
But maybe any (small) gain would be eaten by the loss of the signal handling (be it analog or digital) for every added branch as now, any branch later in the stage is not given the original signal as input anymore...
For steep filters the ripple gain may be insignificant but the serialisation distortion is still there - for 1:st order... well??
//
But maybe any (small) gain would be eaten by the loss of the signal handling (be it analog or digital) for every added branch as now, any branch later in the stage is not given the original signal as input anymore...
For steep filters the ripple gain may be insignificant but the serialisation distortion is still there - for 1:st order... well??
//
Even without Linkwitz, we can kind of understand the difference with a simple thought (or real) experiment.
But in simple words it comes down to the fact that each filter block will add a little bit of group delay (or phase errors)
So with branching filters you automatically compensate for that or at least it helps.
I actually don't agree with Linkwitz's explanation that parallel filters work for 2-way system.
Even in a 2-way system a branching filter will help with the phase between the tweeter and woofer.
Especially in an active system with an additional high-pass filter on the lower frequencies.
(very often used in PRO audio and PA equipment)
But in simple words it comes down to the fact that each filter block will add a little bit of group delay (or phase errors)
So with branching filters you automatically compensate for that or at least it helps.
I actually don't agree with Linkwitz's explanation that parallel filters work for 2-way system.
Even in a 2-way system a branching filter will help with the phase between the tweeter and woofer.
Especially in an active system with an additional high-pass filter on the lower frequencies.
(very often used in PRO audio and PA equipment)
Isn't it trivial to implement a branching filter configuration by say implementing multiple high pass filters on each driver? Such as:
T: HPF50 + HPF200 + HPF2000
M: HPF50 + HPF200 + LPF2000
W: HPF50 + LPF200
SW: LPF50
I always felt like I was missing something with this discussion because with DSP it seems really easy to implement.
Michael
T: HPF50 + HPF200 + HPF2000
M: HPF50 + HPF200 + LPF2000
W: HPF50 + LPF200
SW: LPF50
I always felt like I was missing something with this discussion because with DSP it seems really easy to implement.
Michael
Only problem I see is that you do calculation on the original music data 3 times in a row - potentially needing dither 3 times also..
//
//
Yes, because that's exactly the same thing.
You're only wasting resources, which isn't always an issue anymore these days.
But it's a decent work around for DSP's that don't have node based filter blocks but are always set in one specific order.
In theory there could be a tiny difference between the same filter blocks, since they are not physically the same thing
Indeed. It's fun to play with LR4's and CamillaDSP!
The nice thing with these IIR filters within CamillaDSP is the option to emulate a bunch of standard x-over filters. Such as the Linkwitz-Riley types. So it is possible to play with different setups, such as straight, or branched, as you do in these last posts. Why not. All this is located within a "traditional" range of approach to filtering, formerly set up with hardware capacitors and resistors around opamps. And such, as known, you will inherit all benefits, but also all drawbacks inherent to these filters types and setups.
CamillaDSP can alternatively also process FIR Filters, which allow for a different set of options and choices when x-over filtering.
Take a FIR 4-way x-over LR4 filterset with -6dB points at 180Hz, 720Hz and 3500Hz. Let's go first minimum phase, as with a IIR or a standard linear discrete filter. As expected, the sum of all filters equals not at 0dB:
Same, but in a range from +10dB to -140dB:
Now take the same 4-way x-over LR4 filterset with -6dB points at 180Hz, 720Hz and 3500Hz, but computed instad as linear-phase filters. These linear phase filters add up to a neat ruler-flat result. No need for branching or other tricks.
And if there is a need for steeper filtering, along with a corresponding set of FIR filters, no need for cascading or so. You may e.g. instead resort to FIR Neville-Thiele filters, of to these newer types of optimized jerkless crossover filters by U.Brüggemann:
And for a steeper flavor of it:
Anyway round, either IIR or FIR - it's absolutely super that CamillaDSP offers both options.
IIR and FIR are complementary in theirs merits. In my oppinion though, instead of emulating minimum phase LR4's along with IIR and juggling around phase behavior and maybe also levels for a more or less even summation, better switch to linphase FIR's. Knowing that in doing so, there are also some potential drawbacks and caveat's. Such as some preringing and some small signal delay. And if you need a brickwall type of filtering, then go FIR NT or UB. As shown and as available.
The nice thing with these IIR filters within CamillaDSP is the option to emulate a bunch of standard x-over filters. Such as the Linkwitz-Riley types. So it is possible to play with different setups, such as straight, or branched, as you do in these last posts. Why not. All this is located within a "traditional" range of approach to filtering, formerly set up with hardware capacitors and resistors around opamps. And such, as known, you will inherit all benefits, but also all drawbacks inherent to these filters types and setups.
CamillaDSP can alternatively also process FIR Filters, which allow for a different set of options and choices when x-over filtering.
Take a FIR 4-way x-over LR4 filterset with -6dB points at 180Hz, 720Hz and 3500Hz. Let's go first minimum phase, as with a IIR or a standard linear discrete filter. As expected, the sum of all filters equals not at 0dB:
Same, but in a range from +10dB to -140dB:
Now take the same 4-way x-over LR4 filterset with -6dB points at 180Hz, 720Hz and 3500Hz, but computed instad as linear-phase filters. These linear phase filters add up to a neat ruler-flat result. No need for branching or other tricks.
And if there is a need for steeper filtering, along with a corresponding set of FIR filters, no need for cascading or so. You may e.g. instead resort to FIR Neville-Thiele filters, of to these newer types of optimized jerkless crossover filters by U.Brüggemann:
And for a steeper flavor of it:
Anyway round, either IIR or FIR - it's absolutely super that CamillaDSP offers both options.
IIR and FIR are complementary in theirs merits. In my oppinion though, instead of emulating minimum phase LR4's along with IIR and juggling around phase behavior and maybe also levels for a more or less even summation, better switch to linphase FIR's. Knowing that in doing so, there are also some potential drawbacks and caveat's. Such as some preringing and some small signal delay. And if you need a brickwall type of filtering, then go FIR NT or UB. As shown and as available.
Last edited:
Yes, I took the topology figures from here:
http://www.linkwitzlab.com/frontiers_5.htm#VAllowing a branched routing topology gives the designer more flexibility to implement this kind of thing. On the other hand, with DSP one can achieve the exact same result using a parallel topology, tracing the path from the input to each output in the branched topology, and then implementing all of the filters that are traversed in that path. This requires that some filters are duplicated but the resulting outputs will have identical amplitude and phase when done that way. You would not want to do that if you were using analog filters (due to additional noise, cost, etc.) but when using DSP all of these concerns are a non-issue.
Last edited:
Well there is only so much one can fit in an hardware DSP like a ADAU1701 or so.
Or when a certain set of presets are needed, things add up very quickly.
So it can definitely be an issue 😀 😉
But assume that's not what you really meant with that 🙂
OK, ya got me there. 😛 But this thread is about CamillaDSP. It's software, so DSP capabilities in terms of numbers of signal processing blocks are much less limited compared to hardware DSP.
Running rc1 version on 64 bit Bullseye on RPI4b, output device is Okto DAC8PRO. I have been getting this error once in a while, seems to be intermittent:
Seems to happen after system has been idle for a while. Any ideas ?
Seems to happen after system has been idle for a while. Any ideas ?
Either the USB device gets into some weird state (but not disconnected), or some other process takes the device. Pulseaudio running?
I have had the DAC8PRO for some time and not had this type of problems in the past. Is there a way to troubleshoot this type of issue ?
Pulse audio is running but I almost never make use of it. The only configured ouput for pulseaudio is the loopback used by cmilladsp so probably not the problem but I will try to disable it, see what happens.
Last edited:
Just disable your USB DAC in PA (e.g. https://unix.stackexchange.com/questions/620961/disable-remove-audio-source-pulseaudio https://shallowsky.com/linux/pulseaudio-command-line.html )
if i try to play mono pcm wav files i get those errors:
do i have to make a mono profile? which maps one channel to stereo? would be nice if i can make one profile work for everything tho
how do i make camillaDSP combatible with mono files? (i just have stereo flac files beside the testfiles from audiocheck.net, i also may need to try stereo wav files (i dont have any) but the error seems to be mono related)
do i have to make a mono profile? which maps one channel to stereo? would be nice if i can make one profile work for everything tho
You can define two mixers, one to handle mono and one for stereo. And then use tokens in the pipeline to switch between them, see here: https://github.com/HEnquist/camilladsp#pipeline
Then when starting, override the number of channels: https://github.com/HEnquist/camilladsp#overriding-config-values
Then when starting, override the number of channels: https://github.com/HEnquist/camilladsp#overriding-config-values
hmmm could you give an example? i dont quite understand it
do i need to name the mixers Stereo_IN_2 and Mono_IN_1 ? (since adding a $channels$ token would just add 2 to both because i have in the main config set 2 channels or do i missunderstand it?)
do i just need to use channel 0 for mono?
and i should say that i use moode, so it handles overriding values (i hope it does it in the right way)
Ok, I don't think this will work in the gui, but if you edit the config file manually it should.
Make two mixers, one that converts mono to stereo, and one that just passes stereo on as stereo. Name them "monoswitch_1" and "monoswitch_2".
As the first step of the pipeline, add a mixer, and in the name field there enter "monoswitch_$channels$".
Make two mixers, one that converts mono to stereo, and one that just passes stereo on as stereo. Name them "monoswitch_1" and "monoswitch_2".
As the first step of the pipeline, add a mixer, and in the name field there enter "monoswitch_$channels$".
With (custom) software it doesn't really make sense any more I think?
Since you can just route it the "correct" way anyway.
The work-around is only for those ready-made DSP's where those things can't be changed