This is to test getting the frequency sweep out of REW into Camilladsp. Have another config for squeezelite, both are working aside from this annoying issue at the moment. Its making my brain ache
However I will sort it eventually I am sure so I can proceed on the decision around the multichannel DAC.
However I will sort it eventually I am sure so I can proceed on the decision around the multichannel DAC.
Based on your log it looks like your capture device doesn’t like the S32LE format, I think you want this to be S16LE.
Don’t quite understand the GUI issues to be honest. Do you have this configuration saved to camilladsp.yml? Just wondering if your camilladsp is starting with a different configuration that works but when you load your USB input configuration it doesn’t work because of the S32LE vs S16LE issue?
Michael
Don’t quite understand the GUI issues to be honest. Do you have this configuration saved to camilladsp.yml? Just wondering if your camilladsp is starting with a different configuration that works but when you load your USB input configuration it doesn’t work because of the S32LE vs S16LE issue?
Michael
That seemed to have worked but tried to load the squeezelite config and it didn't seem to pick it up after applying to the dsp. Doing a fetch just got the old config back again.
I think I will build another SDCARD from scratch, it did seem to work for a while at least. I will keep th card that has the SW causing me the issue as is so i can try out any other ideas people may have.
I think I will build another SDCARD from scratch, it did seem to work for a while at least. I will keep th card that has the SW causing me the issue as is so i can try out any other ideas people may have.
The rebuilt Ubuntu/Camilla is working fine so far. Must admit I went for v0.6.3 just to be safe, may go to a more recent version at a later date if all goes well.
At this point I am wondering if all the config changes, saving, loading confused things causing the issues I had. Certainly confused me
Anyhow thanks for the help, hopefully I won't be asking more questions for a while.
At this point I am wondering if all the config changes, saving, loading confused things causing the issues I had. Certainly confused me
Anyhow thanks for the help, hopefully I won't be asking more questions for a while.
Last edited:
Yes this is a known problem, caused by this: https://github.com/dtolnay/serde-yaml/issues/153
What would the disadvantages be of running CamillaDSP on a 32-bit system rather than a 64-bit one? Are there use cases where it makes no difference, for example a below a certain number of channels or number of chunks?
The Wiki mentions speed issues due to the 32-bit architecture having to deal with 64-bit floats, and also quotes some performance examples with different CPU loads.
The Wiki mentions speed issues due to the 32-bit architecture having to deal with 64-bit floats, and also quotes some performance examples with different CPU loads.
Should this be interpreted that as long as your channel/chunk/tap requirements are not pushing the CPU beyond where you want it to be, the 32-bit system will be just as good for your requirements as a 64-bit?
Last edited:
The disadvantage is that you get 20-ish percent lower CPU performance overall. Also the asynchronous resampler can't use Neon on 32-bit, which costs another 20-30% for that one.
Yes exactly!
Dear Community, Henrik,
thank you for the amazing work. CamillaDSP makes sense.
My question: I intend to use Alsa only, do I have to install PulseAudio on a Linux Ubuntu server in order to run CamillaDSP's pre-built binary ?
And - more generally - what packages do I need to install on a debian machine to run CamillaDSP ?
Detailed context:
I want to set up a loudspeaker crossover with CamillaDSP.
I intent to use an older Linux Celeron PC on which I have installed the latest stable Ubuntu Server version - headless.
I had first to install Alsa (alsa; alsa-tools & alsa-utils I think), "speaker-test" now works on the 6 channels.
I have downloaded the camilladsp pre-built binary v1.0.0-alpha5.
When I start camilladsp I get "error while loading shared libraries: libpulse-simple.so.0: cannot open shared object file: No such file or directory".
I had understood I could use CamillaDSP on Alsa without Pulseaudio and I am reluctant to install too many packages on this machine unless needed. The "Dependencies" section of the main CamillaDSP readme file is cryptic to me - and seems focused on the self-build alternative.
Merci !
Daniel.
thank you for the amazing work. CamillaDSP makes sense.
My question: I intend to use Alsa only, do I have to install PulseAudio on a Linux Ubuntu server in order to run CamillaDSP's pre-built binary ?
And - more generally - what packages do I need to install on a debian machine to run CamillaDSP ?
Detailed context:
I want to set up a loudspeaker crossover with CamillaDSP.
I intent to use an older Linux Celeron PC on which I have installed the latest stable Ubuntu Server version - headless.
I had first to install Alsa (alsa; alsa-tools & alsa-utils I think), "speaker-test" now works on the 6 channels.
I have downloaded the camilladsp pre-built binary v1.0.0-alpha5.
When I start camilladsp I get "error while loading shared libraries: libpulse-simple.so.0: cannot open shared object file: No such file or directory".
I had understood I could use CamillaDSP on Alsa without Pulseaudio and I am reluctant to install too many packages on this machine unless needed. The "Dependencies" section of the main CamillaDSP readme file is cryptic to me - and seems focused on the self-build alternative.
Merci !
Daniel.
Last edited:
Tack Henrik. I am choosing between 32-bit and 64-bit for my RPi4 with HiFiBerry DAC+DSP. You rightly point out the issues with lack of Neon benefit etc., and it would be nicer to be able to use 64-bit. Since it looks like I need dsptoolkit in order for my sound card to work, I thought I was limited to 32-bit Raspbian – but this thread implicitly suggests that it might work on 64-bit, too (though of course the 64-bit version of Raspbian is not officially supported). If anyone has actually used this successfully I'd appreciate some confirmation.
@danhilu The prebuilt binary needs PulseAudio installed. But you can quite easily build a version without PulseAudio.
Just follow the steps here: https://github.com/HEnquist/camilla...E.md#building-in-linux-with-standard-features
I just saw that it still mentions that you should install pulseaudio, "Install Pulse dependency". You can skip that step! I'll fix that.
Just follow the steps here: https://github.com/HEnquist/camilla...E.md#building-in-linux-with-standard-features
I just saw that it still mentions that you should install pulseaudio, "Install Pulse dependency". You can skip that step! I'll fix that.
Thank you Henrik.
Well, as I'm lazy, I opted for PulseAudio installation - I'd rather keep using CamillaDSP's convenient pre-built binary.
To do so, I decided to .. first make sure my previous installation of Alsa was complete - following directions from askUbuntu/how-do-i-run-pulseaudio-in-a-headless-server-installation:
Apt-get found out ibasound2-plugins & alsa-oss where missing. And pulled some other dependencies with it, including libpulse0.
Result: camilladsp now starts, problem solved.
Merci !
Daniel.
Well, as I'm lazy, I opted for PulseAudio installation - I'd rather keep using CamillaDSP's convenient pre-built binary.
To do so, I decided to .. first make sure my previous installation of Alsa was complete - following directions from askUbuntu/how-do-i-run-pulseaudio-in-a-headless-server-installation:
Code:
sudo apt-get install libasound2 libasound2-plugins alsa-utils alsa-ossResult: camilladsp now starts, problem solved.
Merci !
Daniel.
New version: v1.0.0-rc1
This is the first release candidate for v1.0.0.
Get it from here: https://github.com/HEnquist/camilladsp/releases/tag/v1.0.0-rc1
Changes from the last preview:
Floating point numbers are stored in a normalized format, as a number called significand or mantissa, and an exponent. Subnormal numbers are the numbers with absolute values that are smaller than the smallest value that can be expressed this way. For 64-bit float, that means values smaller than about 2.2 *10^-308 (yes that is really small!). These are then stored in a special "subnormal" format. Most CPUs get much slower when doing math with subnormal numbers. "Much slower" can mean a factor 100!
This is normally not a problem, 2.2 *10^-308 is about -6000 dB (and for 32-bit floats the limit is about -760 dB). This only becomes a problem with IIR filters that process some signal that then becomes perfectly silent. IIR means the filter remembers the history (for a Biquad this is done via two stored numbers). At each iteration, the stored numbers become smaller and smaller, until at some point (typically a few seconds after the signal goes silent) they end up in the subnormal range. And then the filtering suddenly takes a lot more CPU. This version fixes this by flushing any subnormal number to zero after processing each chunk.
This is the first release candidate for v1.0.0.
Get it from here: https://github.com/HEnquist/camilladsp/releases/tag/v1.0.0-rc1
Changes from the last preview:
- Clean up and remove unused config options
- Handle subnormal numbers in IIR filters
Floating point numbers are stored in a normalized format, as a number called significand or mantissa, and an exponent. Subnormal numbers are the numbers with absolute values that are smaller than the smallest value that can be expressed this way. For 64-bit float, that means values smaller than about 2.2 *10^-308 (yes that is really small!). These are then stored in a special "subnormal" format. Most CPUs get much slower when doing math with subnormal numbers. "Much slower" can mean a factor 100!
This is normally not a problem, 2.2 *10^-308 is about -6000 dB (and for 32-bit floats the limit is about -760 dB). This only becomes a problem with IIR filters that process some signal that then becomes perfectly silent. IIR means the filter remembers the history (for a Biquad this is done via two stored numbers). At each iteration, the stored numbers become smaller and smaller, until at some point (typically a few seconds after the signal goes silent) they end up in the subnormal range. And then the filtering suddenly takes a lot more CPU. This version fixes this by flushing any subnormal number to zero after processing each chunk.