If that is the case, then there should be some trace messages about flushing denormals. @spfenwick could you try a quick run with trace level logging and check for any "flushing subnormal" messages?
In case it's helpful, in my LADSPA plugins I modeled what was done by Richard Taylor in his code to "kill" denormals.
He/we add into all incoming data a square wave signal at the sample rate that has a very low float value, like 1E-15 (-300dB WRT a signal level of 1.0). It's way too low to result in any audible effect but it prevents denormals from occurring and slowing things down.
To do this you add +1E-15 to one sample, -1E15 to the next one, and repeat for all incoming samples.
He/we add into all incoming data a square wave signal at the sample rate that has a very low float value, like 1E-15 (-300dB WRT a signal level of 1.0). It's way too low to result in any audible effect but it prevents denormals from occurring and slowing things down.
To do this you add +1E-15 to one sample, -1E15 to the next one, and repeat for all incoming samples.
Thanks @CharlieLaub, I have seen that (of course I have looked at your biquad code 😁) and I considered to use denormal killers the same way, but I decided to try with just flushing denormals after each chunk. That runs a bit faster, and it just feels a little sad to spend CPU time on adding a dummy signal.
Did you ever see any issues while a signal is playing?
Did you ever see any issues while a signal is playing?
@HenrikEnquist The overhead for adding the denormal killer is just one extra addition and multiplication per sample. The addition adds the value of the denormal killer and the multiplication flips the sign of it in preparation for the addition to the next sample. You can run a frame of data through this process in a single loop and probably gain some speed via optimization. I didn't do anything special IIRC.
I have never encountered any sort of issue related to denormals or the slowing down of audio processing when using my LADSPA plugins.
I have never encountered any sort of issue related to denormals or the slowing down of audio processing when using my LADSPA plugins.
It looks as maybe the compiler generates some strange combination of SSE instructions. Not sure about this yet but it looks dodgy. There is an SSE multiplication that only uses one of the two lanes, but doesn't seem to clear or load anything into the unused lane. If the unused lane contains some rubbish from before, it could explain how it's possible to stumble on denormals that should not exist.
That would also explain why choosing a different target CPU helps, since that likely generates a different instruction sequence.
That would also explain why choosing a different target CPU helps, since that likely generates a different instruction sequence.
@HenrikEnquist : Now that's a pretty deep-level analysis! Please could you post a bit of the details, I (and maybe more guys here) would love to learn more 
Has anyone else seen that their log is populated with "Prepare playback after buffer underrun" warnings when CamillaDSP goes from PAUSED to RUNNING, but only with certain devices?
I have two CamillaDSP setups, both use RPi's running Ubuntu Server. Both setups use an AppleTV as a source and are clocked via the AppleTV digital output.
On my Okto dac8 pro setup, CamillaDSP goes in and out of the PAUSED / RUNNING states without any issue. Because I use default verbosity my log shows nothing other than initial start.
On my MOTU Ultralite Mk5 setup, CamillaDSP gives a warning every time it goes from PAUSED to RUNNING. I don't notice any audible issues when starting to play to CamillaDSP and I never see any other buffer underruns in the log.
If I remove silence timeout and CamillaDSP stays in the RUNNING state, then I no longer get these warnings in the log.
This isn't a huge issue but it would be nice if the log wasn't full of these warnings. Any thoughts?
Michael
I have two CamillaDSP setups, both use RPi's running Ubuntu Server. Both setups use an AppleTV as a source and are clocked via the AppleTV digital output.
On my Okto dac8 pro setup, CamillaDSP goes in and out of the PAUSED / RUNNING states without any issue. Because I use default verbosity my log shows nothing other than initial start.
Code:
2023-08-24 10:19:47.933848 INFO [src/bin.rs:711] CamillaDSP version 1.0.2
2023-08-24 10:19:47.934037 INFO [src/bin.rs:712] Running on linux, aarch64
2023-08-24 10:19:48.337255 INFO [src/alsadevice.rs:161] Starting playback from Prepared stateOn my MOTU Ultralite Mk5 setup, CamillaDSP gives a warning every time it goes from PAUSED to RUNNING. I don't notice any audible issues when starting to play to CamillaDSP and I never see any other buffer underruns in the log.
Code:
2023-10-02 15:59:17.700734 INFO [src/bin.rs:690] CamillaDSP version 2.0.0-alpha2
2023-10-02 15:59:17.700912 INFO [src/bin.rs:691] Running on linux, aarch64
2023-10-02 15:59:17.736711 INFO [src/alsadevice.rs:142] PB: Starting playback from Prepared state
2023-10-02 16:00:39.804442 WARN [src/alsadevice.rs:138] PB: Prepare playback after buffer underrun
2023-10-02 16:09:01.699873 WARN [src/alsadevice.rs:138] PB: Prepare playback after buffer underrun
2023-10-02 16:12:16.447745 WARN [src/alsadevice.rs:138] PB: Prepare playback after buffer underrunIf I remove silence timeout and CamillaDSP stays in the RUNNING state, then I no longer get these warnings in the log.
This isn't a huge issue but it would be nice if the log wasn't full of these warnings. Any thoughts?
Michael
It's mostly work by @spfenwick, see the thread here:
https://users.rust-lang.org/t/unexplained-order-of-magnitude-drop-in-performance
Once the troublesome section was found, and it was confirmed that subnormals were involved, then it was time to look at each instruction, check the documentation for them, and follow what goes on in the cpu registers. And that shows that there is likely a bug in llvm. It uses sse instructions for all the math, such as "mulpd" for doing two f64 multiplications in parallel. Likely because it's faster to do everything with sse instead of mixing sse and normal fpu instructions. When it uses that mulpd to do a single multiplication, then it doesn't take care of what values happen to be in the other lane of the registers. That will often work out ok, but here we have a bad value in one register (a uint64 value of 2) which becomes a very small subnormal number when it's interpreted as a float.
I have copied a little code from camilladsp to make a small example that shows the issue, and I'll submit a bug report to the rust team. Then it will probably be passed on to llvm.
https://users.rust-lang.org/t/unexplained-order-of-magnitude-drop-in-performance
Once the troublesome section was found, and it was confirmed that subnormals were involved, then it was time to look at each instruction, check the documentation for them, and follow what goes on in the cpu registers. And that shows that there is likely a bug in llvm. It uses sse instructions for all the math, such as "mulpd" for doing two f64 multiplications in parallel. Likely because it's faster to do everything with sse instead of mixing sse and normal fpu instructions. When it uses that mulpd to do a single multiplication, then it doesn't take care of what values happen to be in the other lane of the registers. That will often work out ok, but here we have a bad value in one register (a uint64 value of 2) which becomes a very small subnormal number when it's interpreted as a float.
I have copied a little code from camilladsp to make a small example that shows the issue, and I'll submit a bug report to the rust team. Then it will probably be passed on to llvm.
How many of those warnings do you typically get on a paused-running transition? It could be some quirk of that device, that makes it consume some samples very quickly at first, maybe to fill some buffer or something.
I get a single warning for every time it goes from paused to running.
There does seem to be a difference in the two devices in terms of buffer treatment. Both setups run at 48 kHz with 1024 chunk size and no rate adjust. In CamillaDSP the buffer level for the Okto is ~100 and for the MOTU it is ~1100.
Michael
Wow, your project leading to uncovering a bug in LLVM, who would have thought! Big props to you and @spfenwick on your tenacity here.
HI
I am new on this topic. I use Qobuz on Volumio /RPI 3.
I am quite Happy with the rendering.
Having Camilla DSP embedded to Volumio I am searching best practices to use it for room correction.
In other hand is there any benchmark, measures, studies done on DSPCamilla on its capabilities/limits, what consequence to use it on the quality on the song. I assume when do correction we do not just change the level of the frequency but affect phase, track itself etc.
The doc on Github is to technical, I am not interrested on the codes
Your feedback and guidelines would be appreciated
Georges
I am new on this topic. I use Qobuz on Volumio /RPI 3.
I am quite Happy with the rendering.
Having Camilla DSP embedded to Volumio I am searching best practices to use it for room correction.
In other hand is there any benchmark, measures, studies done on DSPCamilla on its capabilities/limits, what consequence to use it on the quality on the song. I assume when do correction we do not just change the level of the frequency but affect phase, track itself etc.
The doc on Github is to technical, I am not interrested on the codes
Your feedback and guidelines would be appreciated
Georges
IIUC the pause just results in no chunks being delivered => no play_buffer() calls, no explicit pause of the alsa device is issued. Then IMO it's logical that upon resuming delivery of chunks the initial status of the device will be xrun - the already delivered samples were already consumed and no new samples arrived.
The IMO interesting outcome is when no xrun occurs after the pause. How is that the samples were not consumed by the running soundcard during the pause? If it's really the case, maybe the USB packet size vs. URB count (packets filled in one alsa period) play a role.
But this seems only for the sake of completely understanding why it happens (which I find useful for myself), the practical effect is likely none.
Last edited:
CamillaDSP on RPi to Motu MK5 Ultralite -
2023-10-03 20:28:23.917925 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2023-10-03 20:28:23.918084 INFO [src/bin.rs:712] Running on linux, aarch64
2023-10-03 20:28:23.944072 INFO [src/alsadevice.rs:592] Capture device supports rate adjust
2023-10-03 20:28:23.982124 INFO [src/alsadevice.rs:161] Starting playback from Prepared state
2023-10-03 20:32:13.773566 WARN [src/alsadevice.rs:157] Prepare playback after buffer underrun
This is going from Mute to unMute.
Just noticed I haven't set the timezone to GMT +10 for Australia.