CamillaDSP is great, I am using it, but paxor worked on the J4105. I use 192kHz sampling on my Ryzen desktop and load was not very different between paxor and CamillaDSP.
I would try disabling realtime and changing the resampling algorithm to sox (if you have changed from default). With 44,1kHz sampling rate it should work fine.
I would try disabling realtime and changing the resampling algorithm to sox (if you have changed from default). With 44,1kHz sampling rate it should work fine.
I know cpu's get unreliable above 80% load, but I have had raspberry pi's run without issue at 95% cpu load on all cores. Took some fiddling with sample rates and buffer sizes (this was with jackaudio).
I have tried ubuntu 20.10 64bit on my Raspberry Pi 4/4Gb. It has very rich repositories, with very recent versions of software, and 64bit does offer a performance benefit. But I also experienced a number of issues, basically the gui is glitchy and I experienced constant ubuntu error messages. It wasn't worth patching pulseaudio.
Raspberry Pi OS now includes and integrates Pulseaudio by default. Next sleepless night will feature a first boot of RPi OS and installation of Pulseaudio Crossover Rack.
I have tried ubuntu 20.10 64bit on my Raspberry Pi 4/4Gb. It has very rich repositories, with very recent versions of software, and 64bit does offer a performance benefit. But I also experienced a number of issues, basically the gui is glitchy and I experienced constant ubuntu error messages. It wasn't worth patching pulseaudio.
Raspberry Pi OS now includes and integrates Pulseaudio by default. Next sleepless night will feature a first boot of RPi OS and installation of Pulseaudio Crossover Rack.
Hey, TFive, could you help me run through the 13.99 sink fixes to get the crossover rack set up properly? I confess I don't know what I'm supposed to do with the instructions on that GitLab page.
Jurgen Herrmann / pulseaudio_13.99_sink_fixes * GitLab
I tried chmod and bash for build.sh and got a syntax error:
build.sh: line 1: syntax error near unexpected token `newline'
build.sh: line 1: `<!DOCTYPE html>'
I've got Mint 20 and crossover rack installed and have edited the files on your help page.
Thanks!
Jurgen Herrmann / pulseaudio_13.99_sink_fixes * GitLab
I tried chmod and bash for build.sh and got a syntax error:
build.sh: line 1: syntax error near unexpected token `newline'
build.sh: line 1: `<!DOCTYPE html>'
I've got Mint 20 and crossover rack installed and have edited the files on your help page.
Thanks!
Download all files in zip and then unpack.
https://gitlab.com/t-5/pulseaudio_1...master/pulseaudio_13.99_sink_fixes-master.zip
https://gitlab.com/t-5/pulseaudio_1...master/pulseaudio_13.99_sink_fixes-master.zip
I've applied the fixes, except for the final "unhold.sh."
"Run ./unhold.sh to remove the hold for the pulseaudio package and enable
updates via apt/debain repository again. Be aware that this will in turn
remove support for SOXR again unless your distro has catched up in the
meantime! This script also upgrades packages to resolve any conflicts
that may arise from installing built packages in the future."
Am I supposed to wait on this until there's an update for crossover rack? Or do I run that and then add SOXR again?
"Run ./unhold.sh to remove the hold for the pulseaudio package and enable
updates via apt/debain repository again. Be aware that this will in turn
remove support for SOXR again unless your distro has catched up in the
meantime! This script also upgrades packages to resolve any conflicts
that may arise from installing built packages in the future."
Am I supposed to wait on this until there's an update for crossover rack? Or do I run that and then add SOXR again?
I got it working with two Behringer UCA202s for my open baffle two-way speakers! Squeezelite is feeding pulseaudio's input and automatically starts after user login into Mint. I also got remote access to the mint machine working well.
It sounds pretty darn good -- a definite upgrade from the active crossover I was using before (also Behringer).
I'm thrilled! Every once in a while there is a slight audible pop, but I'm not overly concerned with that. This is great until I decide to splurge on a Xonar U7 or a diyinhk multi-channel usb dac.
Thanks to Tfive for offering this amazing GUI DSP and setup guide! Plus the extra tweak for poor distro implementation of pulseaudio. All for free! Very generous.
And thanks to xorcz for helping me with the initial set up.
It sounds pretty darn good -- a definite upgrade from the active crossover I was using before (also Behringer).
I'm thrilled! Every once in a while there is a slight audible pop, but I'm not overly concerned with that. This is great until I decide to splurge on a Xonar U7 or a diyinhk multi-channel usb dac.
Thanks to Tfive for offering this amazing GUI DSP and setup guide! Plus the extra tweak for poor distro implementation of pulseaudio. All for free! Very generous.
And thanks to xorcz for helping me with the initial set up.
Attachments
Yep, thanks xorcz for doing support work 
@von Ah: glad you got it working. Hope that distros will pick up the fix from upstream soon...
Some notes: I'm pretty sure you don't want that 30ms delay... That is equivalent to an acoustical offset of 10 m (metres!)...
I'm also amazed how little (none) eq you apply
@von Ah: glad you got it working. Hope that distros will pick up the fix from upstream soon...
Some notes: I'm pretty sure you don't want that 30ms delay... That is equivalent to an acoustical offset of 10 m (metres!)...
I'm also amazed how little (none) eq you apply
Ha! Thanks! I added that based on recollection of another thread... Maybe it's supposed to be .30ms... Gotta track that down.
No EQ yet. I'm just enjoying OB benefits for now. And these drivers are pretty great for this layman's application. I also don't have a measurement system currently.
Gotta track that down.No EQ yet. I'm just enjoying OB benefits for now. And these drivers are pretty great for this layman's application. I also don't have a measurement system currently.
Id suggest it's more in the us range than in the ms range. But to a take advantage of that to bring the crossover region into phase will most definitely require measurements. I'd suggest either setting it to 0 or use a value that is equal to the offset of your drivers centres from the front baffle (something like 5cm, around 150us).
It should at least be better than 30ms, which was way out and to our ears should sound like a noticeable delay, if not masked by other stuff going on.
In the end this at least shows how forgiving our ears can be sometimes. If listening really carefully you'd be able to hear this might make a cool experiment.
From my own experience it can take a lot of fiddling to make things "fall into place", especially in the lower frequencies. If that happens though, it's totally audible, the bass feels tighter and more on point timing wise. Doing this by ear and without measurements is certainly very difficult. My own measurement setup is coming along nicely, together with new soundcard and amps for my two way f.a.s.t. monitors. I will be able to perform tweaks to my living room setup based in measurements pretty soon, reporting back on the progress probably in a new thread.
In the end this at least shows how forgiving our ears can be sometimes. If listening really carefully you'd be able to hear this might make a cool experiment.
From my own experience it can take a lot of fiddling to make things "fall into place", especially in the lower frequencies. If that happens though, it's totally audible, the bass feels tighter and more on point timing wise. Doing this by ear and without measurements is certainly very difficult. My own measurement setup is coming along nicely, together with new soundcard and amps for my two way f.a.s.t. monitors. I will be able to perform tweaks to my living room setup based in measurements pretty soon, reporting back on the progress probably in a new thread.
One more thing you could try without a measurement setup: invert either high or low passed signal, play a pure sine at the xo frequency and adjust for LOWEST audible tone level. This way you make sure the two signals are in phase, cancelling out each other as good as possible if one of them was inverted. Removing the inverter will make them sum correctly then. If you actually perform that experiment let me know your findings, I never tried that personally.