Yesterday I finally fixed my cross-compilation setup for the armhf versions of ladspa-t5-plugins, the LADSPA-plugins that do the DSP work in the background for pulseaudio crossover rack.
Before they were compiled in a arm emulator with the armv6 architecture. They are now cross-compiled for armv7, which should be more suitable for RPi versions >= 2, maybe even with some performance improvements. Please could somebody confirm that the plugins still work fine on a actual RPi? I checked them in a armv7-virt emulator but you never know, so some feedback from you guys would be cool!
Before they were compiled in a arm emulator with the armv6 architecture. They are now cross-compiled for armv7, which should be more suitable for RPi versions >= 2, maybe even with some performance improvements. Please could somebody confirm that the plugins still work fine on a actual RPi? I checked them in a armv7-virt emulator but you never know, so some feedback from you guys would be cool!
They seem to be working fine in Raspbian Buster on the RasPi4. Is there anything specific that you need me to try?
Currently just running various LR4 filers as well as parametric EQ
First of all some technical background: ATM I don't know of any way how to change parameters of LADSPA plugins after they were inserted into pulseaudio, so I had to roll my own API that each plugin I want to use has to implement (I asked on the pulseaudio mailing list but never received any reply to my question).
For this reason, at least at the moment, I cannot use any pre made plugins.
But there's another side to the story, there are literally dozens if not hundreds of different compressor/limiter plugins out there, if counting all the commercial ones too. So the first question to ask would be: "Why do you want to have a compressor in you chain in the first place? Which problem are you trying to solve?"
For this reason, at least at the moment, I cannot use any pre made plugins.
But there's another side to the story, there are literally dozens if not hundreds of different compressor/limiter plugins out there, if counting all the commercial ones too. So the first question to ask would be: "Why do you want to have a compressor in you chain in the first place? Which problem are you trying to solve?"
I would use it between the subwoofer x-over (70Hz LPF) and the subwoofer output for speaker protection. With your EQ I'll add a 6-9dB boost @ say 40Hz to a small woofer, forcing it to play lower than it naturally could in a given enclosure. That signal will go to the compressor with a threshold set to activate @ maybe 70% of the woofers excursion limit... Now, with with a 3:1 compression ratio for example, once the woofer reaches the specified threshold it will only see 1dB of gain for every 3dB of overall gain allowing the system to "appear" to play much louder than it should with it's extended low frequency range.
Last edited:
Man, go for it, and be the first to post that sweet "I did it with pulseaudio crossover rack" success story I'm still looking for
That looks like a pretty hefty boom box to me! We'll see what I can do about that crossover/limiter, but to be honest first of all I'm into delivering a solid base for crossover building and LS development experience. And as I mentioned, there are quite a few things on my plate as of now, you can always fortify that feature request by adding a feature request at gitlab.
Of course designing a boom box like this I can definitively see the benefits of having a fast acting compressor for pushing the SPL. That said, in your case I would even ditch the compression ideas and look more towards a really fast acting limiter. Maybe even look-ahead, introducing a minor delay, which can be compensated for.
Another thing I have to say about this topic: I worked a little while as a sound engineer in live sound. All the amps there have fast acting limiters, especially in the base. To be honest, if you drive your amps into mild "clipping" you won't even hear it at the levels that are used in PA. What's different is: Engineers always get some kind of feedback how much a limiter is limiting or a compressor is compressing. Another drawback of LADSPA plugins, they don't provide any meaningful UI, not even a compression ratio in dB, which is IMHO a must for a compressor. So in the long term if really incorporating any sort of level shaping plugins there's IMO a must for monitoring the action of the plugins.
FYI as I also feature the possibility to boost/cut gain in every filter there's a high priority TODO to offer VU meters for all outputs. That way you can at least adjust your gain structure to fit your filters and not throw away any digital resolution. This is tied to the measurement_support branch though, as it uses pulseaudio live inputs and it's associated prerequisites.
FYI as I also feature the possibility to boost/cut gain in every filter there's a high priority TODO to offer VU meters for all outputs. That way you can at least adjust your gain structure to fit your filters and not throw away any digital resolution. This is tied to the measurement_support branch though, as it uses pulseaudio live inputs and it's associated prerequisites.
Using pavucontrol, should my Playback application be -on PaXoverRack.Input, the default input device - Monitor of PaXoverRack.Output, and the default Output device - LineOut.
Also, I think LineOut used to be 'on' something but that has dropped off. Everything was working fine until earlier today and I'm beginning to repeat things.
Also, I think LineOut used to be 'on' something but that has dropped off. Everything was working fine until earlier today and I'm beginning to repeat things.
I've noticed every once in a blue my output channels seem to lose sync (Ex. there'll be a noticeable delay on two or four channels in relation to the others). This happens on the Pi 4 with 8Ch HDMI extractor with the latest version of Raspbian but very rarely... I haven't figured out what the conditions might be when this begins to happen although I don't believe it happens while under heavy CPU load.
I wasn't so much worried about it happening on the Pi 4 because it hasn't happened in days and when it does occur it's so slight (maybe 2-4ms) that one might not even notice. I figured I'd eventually figure it out or that it might sort itself out with an upcoming update of of Raspbian with better driver support for the Pi 4.
Last weekend however, I fired up the Atomic Pi SBPC running a fresh install of Lubuntu v19.04 (Same HDMI extractor)... This has the same issue but it happens much more often and to a much greater degree. Even restarting pulseAudio or fully rebooting. I've noticed that it's actually not a static time delay on certain channels, the CH offset ranges from approx 250ms and slowly catches up to the other channels and eventually drifts back and forth. It's crazy... Also when it's happening it's accompanied by ridiculous audio glitches and dropouts. It's the type of noise you'd hear if the CPU was at 100% but the 1st of 4-cores only reads around 18% and the other 3 cores are usually less than that, plus the OS is otherwise very responsive.
Any idea why this might be happening?
I wasn't so much worried about it happening on the Pi 4 because it hasn't happened in days and when it does occur it's so slight (maybe 2-4ms) that one might not even notice. I figured I'd eventually figure it out or that it might sort itself out with an upcoming update of of Raspbian with better driver support for the Pi 4.
Last weekend however, I fired up the Atomic Pi SBPC running a fresh install of Lubuntu v19.04 (Same HDMI extractor)... This has the same issue but it happens much more often and to a much greater degree. Even restarting pulseAudio or fully rebooting. I've noticed that it's actually not a static time delay on certain channels, the CH offset ranges from approx 250ms and slowly catches up to the other channels and eventually drifts back and forth. It's crazy... Also when it's happening it's accompanied by ridiculous audio glitches and dropouts. It's the type of noise you'd hear if the CPU was at 100% but the 1st of 4-cores only reads around 18% and the other 3 cores are usually less than that, plus the OS is otherwise very responsive.
Any idea why this might be happening?
Last edited:
Thank you, I have my EQ back. Apps and input OK. Output through LineOut, with PaXoverRack.output at max. You gotta love computers
[Feature Request]- The overlay is good, two may be better, and output *.frd
Edit: - A couple of reasons why (I currently have paper cutouts on the screen). frd out for editing on a simulator, then back in, also house curve etc. Then to consolidate and reduce the number of EQ plugins.
[Feature Request]- The overlay is good, two may be better, and output *.frd
Edit: - A couple of reasons why (I currently have paper cutouts on the screen). frd out for editing on a simulator, then back in, also house curve etc. Then to consolidate and reduce the number of EQ plugins.
Last edited:
I might have a suspicion, but still wasn't able to 100% confirm it. Please try adding tsched=0 to the module-udev-detect line in your $HOME/.config/pulse/default.pa like this:
Code:
load-module module-udev-detect tsched=0Then restart pulseaudio. Or better even your OS. Please report back. If we have this confirmed then it's finally time to pursue this bug in pulseaudio.
Thank you, I have my EQ back. Apps and input OK. Output through LineOut, with PaXoverRack.output at max. You gotta love computers
[Feature Request]- The overlay is good, two may be better, and output *.frd
Edit: - A couple of reasons why (I currently have paper cutouts on the screen). frd out for editing on a simulator, then back in, also house curve etc. Then to consolidate and reduce the number of EQ plugins.
Please elaborate, atm I'm not really getting what your request is about...
Just read up on this. Sounds about right... I'll try this out this evening and report back.
Thanks Tfive
Well, I've been playing music in JRiver from local files, streaming from the NAS, Streaming via DLNA as well as streaming bluetooth from my phone to Lubuntu for the past hour without a glitch. It looks like adding the tsched=0 did the trick!
I love your PaXoverRack software!
Thanks again Tfive
Good catch, Jürgen. I would not think the timer-based scheduling could timeshift individual channels of one stream, I would assume all channels would be delayed at once. Yet IRQ-based scheduling fixed the problem. Do you have any tip for a bug in PA in this regard? That's very interesting.
Ok.Please elaborate, atm I'm not really getting what your request is about...
Example of using 2 frd overlays. I have a measured response exported from my crossover designing app. I want to tweak that result, and aim for a non-flat target. So I need to see the starting response and the target response (the starting response will combine with the filters, but the target response just sits there as a fixed overlay).
2 examples of saving frds. To take back to my crossover designing app. And when I have too many EQ plugins and want to simplify the setup but need to save the result to use as a target on the new set.
Jürgen, please do you have any experience with capturing from one soundcard (module-alsa-source) and playing the incoming data (after your processing) to another soundcard (module-alsa-sink) with independent clock? The module-combine-sink adaptively resamples only between several sinks, I could not find any solution for adaptively resampling between source - sink.
I am asking because Charlie Laub with me have made the usb-audio gadget linux driver work in windows, which turns RPi4 (with USB OTG port) into a regular USB sound device (playback only for now, any samplerate, any number of channels). This allows building an "intelligent" USB soundcard with any processing running in linux on RPi. Data from the USB gadget are available on RPi as a virtual alsa capture soundcard (listed in arecord -l).
But the capture soundcard (source) is timed by the USB controller of the host (adaptive mode), whereas the playback (sink) is timed by the output soundcard - two clock domains to synchronize. The correct way would be making the usb-gadget proper async soundcard, but that is quite a major complication.
Thanks for any info.
I am asking because Charlie Laub with me have made the usb-audio gadget linux driver work in windows, which turns RPi4 (with USB OTG port) into a regular USB sound device (playback only for now, any samplerate, any number of channels). This allows building an "intelligent" USB soundcard with any processing running in linux on RPi. Data from the USB gadget are available on RPi as a virtual alsa capture soundcard (listed in arecord -l).
But the capture soundcard (source) is timed by the USB controller of the host (adaptive mode), whereas the playback (sink) is timed by the output soundcard - two clock domains to synchronize. The correct way would be making the usb-gadget proper async soundcard, but that is quite a major complication.
Thanks for any info.
Last edited: