No condemnation here, I am honestly curious as to what you want to accomplish.
My praise of BruteFIIR comes from it's ability to run huge filters with workable latency and space requirements - no small achievement.
I have just tried to install Pulseaudio Crossover Rack on my Rpi to test the 8 Channel output on HDMI; there is an error message:
Code:
pi@raspberrypi:~/PaXoverRack $ python3 pulseaudio-crossover-rack.py
Traceback (most recent call last):
File "pulseaudio-crossover-rack.py", line 14, in <module>
from qt5_t5darkstyle import darkstyle_css
ImportError: No module named 'qt5_t5darkstyle'
pi@raspberrypi:~/PaXoverRack $
You obviously tried to install via git... You will now find the required files for the qt5_t5darkstyle module here: Jurgen Herrmann / python3-qt5-t5darkstyle * GitLab
Hope that helps!
PS: may I ask which distro you use?
OK, I am sure you are right. My only concern is that if you have to load e.g. 10,000+ coefficients from disk that will stall the initial setup. At least in LADSPA this can be a problem (at least I think so).
In my application I would use such a plugin for doing delay compensation as part of a loudspeaker crossover. This would sort of be the last "step" after the rest of the crossover has been finalized. I would not need to modify the coefficients all that much, so inlining them in the code is no problem. I compile my plugins with a Makefile and doing so is quick and painless.
Can you share what approaches you were thinking of to handle the FIR coefficients?
I would very much appreciate that. I am not so clear on the proper way to so the partitioning and overlap aspects.
Yes, the LADSPA is certainly a bit stale and primative. The advantage of LADSPA is that it is supported by many free domain software programs and can even be called directly from within ALSA.
I use Gstreamer to do audio DSP processing and streaming. LADSPA plug-ins that I wrote (IIR filtering mostly) are an integral part of that. There is also the program "ecasound" that many DIY loudspeaker turn to for DSP processing on low power platforms like the Pi.
Because BruteFIR is just about the only free software tool for implementing FIR filters, users have to pipe or loop audio in and out of it. If FIR was implemented directly in a LADSPA plugin that would eliminate the extra latency penalty.
I use Raspbian with a modified Kernel. I have got Pulseaudio Crossover Rack up and running but what is missing (as expected) the Output Sink for 8 Channels PCM.
OK, is it latest raspbian based on Debian Buster? If not, your pulseaudio version will be too old!
And secondly, why didn't you use my debian repo? Would have made installation much easier...
Thirdly, if you already have a modified kernel, why don't you have 8 channels of PCM available?
That sounds more plausible. I have seen other programs storing IR coefficients as *.wav files. Why not simply text files?
I don't see any advantage to using *.wav over text, other than file-size, and that is a complete non sequitur for this domain.
It's a series of significant leaps, conceptually, from simple convolution, to streaming overlap-add/overlap-save, to streaming partitioned convolution. But, you will need FFTW at each step along way (unless you plan on starting with convolution in the time domain).
The FFTW wisdom files are something I would consider dead last, if at all.
To be fair, LADPSA is the only choice if you want to make use of the various IIR libraries floating around and integrate with Pulseaudio.I simply chose LADSPA because they plug in nicely into pulseaudio. Maybe that was not the best choice but well... You never really know until you try it yourself
I just load the coefficients from text files and have not observed initialization/timing problems.
If latency is an issue for an audio application, perhaps using long FIR filters is a fundamentally bad choice. Even (uniformly) partitioned convolution can reduce latency only so much.
I can't imagine that piping data to BruteFIR incurs much penalty. Have you actually measured that?
It seems to me that this concern (and many others) could be dealt with by properly integrating a convolution engine at the lowest levels of the user-space audio stack (i.e. ALSA). That way, any client can make use of it. While ALSA's LADSPA plugin framework may be suitably positioned, it is sorely lacking in other respects.
As I said, I needed such tooling for a speaker project and thought it would be a fun opportunity to brush the dust off my DSP skills that have not seen much exercise since grad school.
TBH, I'm not certain where this project may go, if anywhere. I started by simply making some software for my own use, and fell down a bit of a rabbit hole
Define "huge filters", please.
IMO, huge is somewhere around 65 ktaps for my domain.
Not sure I understand your statement about "space requirements". Could you explain?
As for latency, that is largely a product of the algorithm employed by BruteFIR - a degree of freedom exposed by design.
Don't misunderstand me: I think BruteFIR is very nice work.
1) I think it is Raspbian Stretch
2) I used your Repo in the second try
3) You will need a HDMI 7.1 Pulseaudio config, I do not think that this is automatically generated.
For me this was just a Test. I think your Software is fantastic for people who need a graphical Playground. My Brutefir Convolver is running headless with a Hifiberry digi I/O as Input and 4 Channel Output on HDMI straight into my AVR.
Brutefir is doing roomcorrection and crossover for my FAST system.
I can change roomcorrection Filters with LIRC, the Crossover section is allways the same.
Thanks Charlie!
A couple of lines of C code and a kernel recompile is not a problem.
A Raspi running the DSP, and possible sourcing the music would be incredible. If I go forward (soon), I'll post docs here.
Yep. "This is easily done by xxx into yyy and then changing zzz parameter into 999 and then you simply do what you must always do and is outside the scope of this tutorial, which you can find in that manual, which leads to a dead link as the debian foundation totally sucks and arch is where it's at but now this wiki is hacked by manjaro and all you have to do is..."
There is a little gap between absolute beginner level and black belt linux hacker fu level.
I have had a test pair of 10" Ciare CH250 fullrange drivers in open baffles on the desk, with a Raspberry Pi 3 with Hifiberry Amp2 and pulseaudio crossover rack. It has enough power and LOUDness for a party. The Amp2 has sufficient quality and dynamics and is very silent (with a generic laptop powersupply). The GUI makes it a totally flexible and easy solution. I put the system away again, because I am waiting for Kodi to be repaired in the new Raspbian (I want to use that as mediaplayer). I heard it is fixed now, so I will try again soon.
All in all, the rpi with a simple HAT is a fantastic mediacenter, with streaming and playback capabilities, an amplifier, etc. etc. etc.
Ubuntu should include it in their distro at some point. I really think so.
Yep. "This is easily done by xxx into yyy and then changing zzz parameter into 999 and then you simply do what you must always do and is outside the scope of this tutorial, which you can find in that manual, which leads to a dead link as the debian foundation totally sucks and arch is where it's at but now this wiki is hacked by manjaro and all you have to do is..."
There is a little gap between absolute beginner level and black belt linux hacker fu level.
As a long time Linux user and sometimes hacker, you are absolutely correct.
Can't tell you how many days I wasted in ALSA trying to get a MAudio 1010 card setup correctly.
But what was "rocket science" in 2005 becomes plug and play in 2020. There is hope for open source solutions.
For regular computer use, everything works plug and play when using a distro that is meant to be plug and play. Like Ubuntu derivatives.
The trouble starts when you do a little command line, a little compiling, and you get an interesting idea and someone says "oh, that's easy, you just..." ;-)
Big respect for pulseaudio crossover rack in that regard!
The trouble starts when you do a little command line, a little compiling, and you get an interesting idea and someone says "oh, that's easy, you just..." ;-)
Big respect for pulseaudio crossover rack in that regard!
As I said, I needed such tooling for a speaker project and thought it would be a fun opportunity to brush the dust off my DSP skills that have not seen much exercise since grad school.
TBH, I'm not certain where this project may go, if anywhere. I started by simply making some software for my own use, and fell down a bit of a rabbit hole
Define "huge filters", please.
IMO, huge is somewhere around 65 ktaps for my domain.
Not sure I understand your statement about "space requirements". Could you explain?
As for latency, that is largely a product of the algorithm employed by BruteFIR - a degree of freedom exposed by design.
Don't misunderstand me: I think BruteFIR is very nice work.
I had a room EQ application that was 16 channels of 2480 tap filters. BruteFIIR handled it with a mere 28ms latency.
There are tons of user cases to think of.
The most straight forward is a HTPC/Media center with a multichannel soundcard (or HDMI
) were the settings can be changed via a smartphone instead of fiddling around with a keyboard and a mouse.This makes the total user experience a lot nicer.
Especially when this can be implemented next to KODI or LibreElec or similar, you basically get a (very close to) professional experience.
But I am actually thinking a couple of steps further. What makes Crossover Rack so nice is the simplicity of it. So basically people only have to add a ADC/DAC (or CODEC) and it's VERY easy to build some active speakers with it.
When combined with something like a Rasp Zero W, you even have Bluetooth audio and everything.
Also this can be totally programmed with a smartphone (via bluetooth or wifi)
In the end it's a whole lot easier to install and use than something like a ADAU1701 board or similar.
The main question is to keep the latency low, but I think that will do fine with a RT kernel.
It's a bit ironic, because as a professional I do make a lot of audio DSP boards (mostly with the ADAU145x and SHARC series) for professional companies.
Bit in sense of simplicity nothing gets close to a Rasp Berry Pi. Besides, it's impossible to beat the price for a Rasp Zero.
At this moment there are absolute zero solutions who could beat the price of a little RaspB board including a ADC/DAC. So I really do see a great gap in the market for makers and DIY'ers.
Mostly because you really do see people getting stuck at this. Making active filters isn't hard, but just buying an off the shelf solution for 70-150 bucks is just a bit to much in most cases.
Think of little bluetooth speakers etc.
There is a lot to beat with BruteFIR. Just already installing and using it is an absolute pain in the butt for most people.
Where I see the power, is implementing IIR and FIR in just one simple program, like little building blocks.
I am absolutely not new to Linux, compiling and that kind of stuff, but a lot of times I just simply don't enjoy spending hours and hours (and sometimes multiple weekends) trying to get something very basic to work properly.
Something that's actually extremely easy to program properly from the developers side.
Please don't get me wrong on this, I am trying to be very constructive here, MOSTLY because I see so much potential in this.
(not only as an enthusiastic hobbyist, but also as a professional)
Last edited:
Please don't take this as an insult, but the most challenging aspect there sounds like finding a DAC supporting 16 output channels
A pro-model of some sort?
Please don't take this as an insult, but the most challenging aspect there sounds like finding a DAC supporting 16 output channels
A pro-model of some sort?
It was a commercial cinema product. For DACs we used 4 TI PCM4104s. In the end, it worked well.