Ok I see, then a tcp socket or something like that is really needed. I'm not opposed to adding that, but it will take some time. I'll investigate a bit to get a better idea.One thing I definitely don't want to loose is instant parameter changing without any interruption of the sound. I have sliders on the filter configuration dialogs which of course can spit out lots of updates per second. Currently I have a memory-mapped-file interface in my LADSPA plugins to achieve seamless, uninterrupted updates of parameters.
Please don't feel bothered by me, just stating my needs here. If it can't be done easily in your design then I won't (and can't) beat you to it
PS: it's just a curious coincidence that I thought about moving the DSP processing to a monolythic process instead of LADSPA plugins since a few weeks. It just offers so much greater flexiblity. So then I stumbled upon your project and it immediately seemed like a good candidate to just plug in there. And FIR filters are on my todo list also, so your software would tick that box "for free"
How would you enter (or change) FIR parameters in the gui? Do you just pick a file, or actually enter or modify all the coefficients in an editor?
SIGHUP for reloading would also work, but config reloading might not help with very fast changes from a slider.
Last edited:
A shameless plug here... I am currently developing (AKA hacking together) a LADSPA based FIR plugin. I recently mentioned it over here. Read that post for some implementation details.
Tfive: I use a FIFO to communicate parameters between the LADSPA plugin and the (separate) process that I call the "FIR engine" that does the actual convolution. I was not anticipating updating the FIR filter after the filter processing had been launched because this would involve moving thousands of coefficients over the FIFO, but it could certainly be done within the framework I have created. I just do not see a need for it, and most LADSPA hosts do not easily support real time changes to parameters. Instead the user can kill and restart with the new ones, if a change is desired. That is perfectly adequate for my intended application: loudspeaker crossovers.
It would be fun to take a look at your project. Do you have the code published somewhere?
Ah I meant CharlieLaub's FIR plugin. Your repos are easy to findYep, looki looki: Pulseaudio Crossover Rack :: T5! DIY Audio Software & Hardware
It turned out to be quite easy to reload on SIGHUP. I'm playing around with that in a (very) preliminary version. This is working better than expected.
If I reload a config with only BiQuads it's completely inaudible. If there are a FIR filters in the config there is a slight click since the overlap buffers of the FIR filters get cleared.
It needs some cleaning up and more testing before I upload, but that shouldn't take long.
If I reload a config with only BiQuads it's completely inaudible. If there are a FIR filters in the config there is a slight click since the overlap buffers of the FIR filters get cleared.
It needs some cleaning up and more testing before I upload, but that shouldn't take long.
Wow, you're rushing ahead. Me like!
If this only works on parameter changes on biquads, I'm all fine with it, after all I don't offer a way to construct FIR filter reponses nor do I plan to do that. For that I'd rely on something like rePhase. So loading new impulse responses is fine to glitch out a little IMHO. What I like though is being able to adjust the Q/F/G of a filter, especially in the base region to tighten up the response presented to my ears. I have to deal with very small listening rooms all the time and there this feature comes in quite handy. And to be honest, who doesn't like to adjust a little here and there from time to time by ear? I know. I should get into measuring my systems. Will do that with my new semi-infinite-baffle-coax project soon... Measurement support for PaXoverRack is in alpha right now.
If this only works on parameter changes on biquads, I'm all fine with it, after all I don't offer a way to construct FIR filter reponses nor do I plan to do that. For that I'd rely on something like rePhase. So loading new impulse responses is fine to glitch out a little IMHO. What I like though is being able to adjust the Q/F/G of a filter, especially in the base region to tighten up the response presented to my ears. I have to deal with very small listening rooms all the time and there this feature comes in quite handy. And to be honest, who doesn't like to adjust a little here and there from time to time by ear? I know. I should get into measuring my systems. Will do that with my new semi-infinite-baffle-coax project soon... Measurement support for PaXoverRack is in alpha right now.
I tried adjusting by ear when I first swithed over to active crossovers, but it didn't work very well. Most of the time I ended up with something that was worse than what I started with. It sounded better on exactly that piece of music I experimented on, but other stuff tended to suffer. So instead I measure, adjust, measure, adjust....
Anyway, I have been thinking a bit more and I will be able to get rid of the glitches when reloading fir coefficients as well. At least as long as the new coefficients are reasonably similar to the previous ones. If only the filter parameters change I don't need to rebuild the pipeline. It's enough to update the filter coefficients, and that can be done without clearing buffers.
Anyway, I have been thinking a bit more and I will be able to get rid of the glitches when reloading fir coefficients as well. At least as long as the new coefficients are reasonably similar to the previous ones. If only the filter parameters change I don't need to rebuild the pipeline. It's enough to update the filter coefficients, and that can be done without clearing buffers.
To prevent glitches when you change FIR filters, you could retain the last frame of unprocessed (e.g. input) audio data. Then if/when you change the FIR filter you re-convolve the last frame with the new filter, or at least the last M samples of it, where M is the filter length of the new filter. This will produce a "replacement" overlap add dataset. After that you proceed as usual with the new filter.
RE my code: I don't have a repo. I'm just working with another guy on getting my code up and running at this point. Assuming everything works out swell I will eventually release it publicly. If you want to see if privately, drop me a line.
RE my code: I don't have a repo. I'm just working with another guy on getting my code up and running at this point. Assuming everything works out swell I will eventually release it publicly. If you want to see if privately, drop me a line.
Glitch free updates of both Biquads and FIR filters are working!
Check out the branch "reload" in Github.
I didn't need to do anything special to get the FIR filters to behave well. Just keeping the overlap buffer intact when switching is enough. This means the decay from the previous filter meets up fine with the start of the new one.
On SIGHUP it reads the config file again, and anything that changed is updated.
- If only filter parameters changed it updates the coefficients of the filters. This is completely glitch free also for FIR filters.
- If the pipeline changed or if a filter changed type (for example from Biquad to Delay) the pipeline is rebuilt. This gives a small glitch if there are FIR filters involved.
- Changing the input or output device config isn't ready yet. The plan is simply to restart everything.
Check out the branch "reload" in Github.
I didn't need to do anything special to get the FIR filters to behave well. Just keeping the overlap buffer intact when switching is enough. This means the decay from the previous filter meets up fine with the start of the new one.
On SIGHUP it reads the config file again, and anything that changed is updated.
- If only filter parameters changed it updates the coefficients of the filters. This is completely glitch free also for FIR filters.
- If the pipeline changed or if a filter changed type (for example from Biquad to Delay) the pipeline is rebuilt. This gives a small glitch if there are FIR filters involved.
- Changing the input or output device config isn't ready yet. The plan is simply to restart everything.
New version is up!
- I added all the usual filter function for Biquad, like first order high/lowpass, bandpass, notch etc.
- It also checks that IIR filters are stable.
- Config reloading is working fine now. Any part of the config can be updated and it will update coefficients or restart as needed. Coefficient changes are glitch free.
Next steps then, some ideas:
- Option to add noise shaped dither when outputting as 16 bit.
- Partitioned convolution for shorter delay with long fir filters.
- Some way to read the active configuration, to know for sure that a reload really did reload.
What do you think? Something else that is missing?
- I added all the usual filter function for Biquad, like first order high/lowpass, bandpass, notch etc.
- It also checks that IIR filters are stable.
- Config reloading is working fine now. Any part of the config can be updated and it will update coefficients or restart as needed. Coefficient changes are glitch free.
Next steps then, some ideas:
- Option to add noise shaped dither when outputting as 16 bit.
- Partitioned convolution for shorter delay with long fir filters.
- Some way to read the active configuration, to know for sure that a reload really did reload.
What do you think? Something else that is missing?