I've been testing CamillaDSP with my B&C 15CXN76 coaxial project. I'm using REW-RePhase toolchain to produce FIR based linear phase crossover and EQ filters. I'm currently running these tools and CamillaDSP on Windows 10 Intel NUC with Asus Xonar U7 MKII. Eventually I would run CamillaDSP on Linux. I'm using the recommended VB-CABLE virtual sound card as the Windows playback device.
Beside the few issues below CamillaDSP has been wonderful; I was able to implement a fully functional linear phase active crossover + EQ in a matter of hours. So thank you for creating this great piece of software!
Few questions:
1. I'm seeing a level drop of about 10dB when using the VB-CABLE virtual sound card -> CamillaDSP -> Xonar compared to using MiniDSP 2x4HD USB-audio. I have triple checked all the device levels to be 100. Any ideas what could be causing this?
2. Quite often CamillaDSP enters a continuous buffer underrun loop. CPU utilisation is hovering around 5%. I've experimented with different chunksizes but no real difference. Otherwise I'm running pretty much recommended settings found in Wiki. The only thing which seems to solve the issue is to raise the priority of the CamillaDSP process from normal to high. Is this something to do with Windows (most people running Linux distros)?
3. What are the recommended settings when producing FIR filters with REW-RePhase? Especially the RePhase "Impulse settings" to generate the actual FIR filter for CamillaDSP. Also should I use the same sampling frequency across UMIK-1 -> REW -> RePhase -> CamillaDSP -> sound devices chain? RePhase seems to be 96kHz so should I use that everywhere?
Beside the few issues below CamillaDSP has been wonderful; I was able to implement a fully functional linear phase active crossover + EQ in a matter of hours. So thank you for creating this great piece of software!
Few questions:
1. I'm seeing a level drop of about 10dB when using the VB-CABLE virtual sound card -> CamillaDSP -> Xonar compared to using MiniDSP 2x4HD USB-audio. I have triple checked all the device levels to be 100. Any ideas what could be causing this?
2. Quite often CamillaDSP enters a continuous buffer underrun loop. CPU utilisation is hovering around 5%. I've experimented with different chunksizes but no real difference. Otherwise I'm running pretty much recommended settings found in Wiki. The only thing which seems to solve the issue is to raise the priority of the CamillaDSP process from normal to high. Is this something to do with Windows (most people running Linux distros)?
3. What are the recommended settings when producing FIR filters with REW-RePhase? Especially the RePhase "Impulse settings" to generate the actual FIR filter for CamillaDSP. Also should I use the same sampling frequency across UMIK-1 -> REW -> RePhase -> CamillaDSP -> sound devices chain? RePhase seems to be 96kHz so should I use that everywhere?
That could just be Microsoft's scheduling and latency issues. I switched to Linux for multiple reasons including writing straight to ALSA and being able to control latencies by using low latency and/or PREEMPT_RT kernels.
Try running Latency Monitor during playback.
Resplendence Software - LatencyMon: suitability checker for real-time audio and other tasks
Thesycon's DPC Latency Checker is another app to try, but Latency Monitor is probably more detailed.
Last edited:
Attached are config and the two debug logs (zip file). On the first run I just first waited with Spotify playing and nothing else going on. Got tired of waiting, tried opening diyaudio on Chrome and almost immediately buffer underrun. Playback never recovered.
At this time I also noticed the post related to LatencyMon and installed it. First image is with the playback restarted and everything playing nicely.
On the second run I did not wait but opened the diyaudio web page again and got buffer underrun. LatencyMon did not seem to indicate any problems during the playback or at the failure (second image).
Normally the buffer underruns have occurred during background playback with no user interaction taking place. But of course Windows could be doing whatever it thinks is important at any time.
I will make additional tests with CamillaDSP having higher priority.
At this time I also noticed the post related to LatencyMon and installed it. First image is with the playback restarted and everything playing nicely.
On the second run I did not wait but opened the diyaudio web page again and got buffer underrun. LatencyMon did not seem to indicate any problems during the playback or at the failure (second image).
Normally the buffer underruns have occurred during background playback with no user interaction taking place. But of course Windows could be doing whatever it thinks is important at any time.
I will make additional tests with CamillaDSP having higher priority.
Attachments
I think this is all Xonar U7 MKII. The output levels from the analog connectors are just so low. Unfortunately I did not understand the meaning of this when reading Amir's review: Review and Measurements of Asus Xonar U7 MKII ADC/DAC/HP | Audio Science Review (ASR) Forum
And the digital output is limited to stereo only. But it is providing the full levels. Don't understand why this card has been recommended to this kind of usage at all.
The longest latency in the 2nd run did triple over the 1st run. You might want to let LatencyMon run for a few minutes (across multiple runs) to catch distributed transients. Latencies don't always get caught on a single short run. With extended runs on my Windows laptop, the Microsoft i8042 Port Driver and the Microsoft TCP/IP driver causes undesirable issues.
If changing the priority fixes the problem, it is most likely a scheduling related issue.
FWIW, I added "NICE" commands to my Linux run scripts to increase their priorities for good measure. I also don't have transient anti-virus and automatic update/update check apps running in the background in Linux. Anti-virus is pretty much integral/ubiquitous to Windows.
I think I solved the mystery of Xonar U7 MKII low output levels. Last night I realised where I had seen ~10dB values related Xonar. It was in the Sonar Studio application installed by the Asus driver. It has a built-in EQ which of course I had disabled as well as all the other "features". But the EQ has a scale of -12dB to +12dB 0dB being the default. So how can they boost +12dB without clipping taking place? Perhaps by first attenuating the level by 12dB...
So I needed a way to get rid of the Sonar Studio while maintaining the driver part. Fortunately found this driver extraction method and was able to install just the audio driver.
And the levels were restored! I did have to first run the speaker configurator to have all the speakers full bandwidth but that was it. I had gained 12dB.
Somehow the whole sound was different, better, clearer but it could be just my imagination. I know for sure the Sonar Studio crap was previously in the pipeline doing stuff even though everything should have been disabled.
Yes, the version is 0.6.3. I will try this on 1.0.0 preview. Do note that running CamillaDSP with High priority solved the issue for me. But I can definitely test it out with 1.0.0 Preview and Normal priority and report back here.
I think I found a reliable way to catch and recover from this problem.
New preview published here: Release v1.0.0-alpha3 * HEnquist/camilladsp * GitHub
This contains fixes for the Wasapi and CoreAudio backends. Unfortunately the changes broke Wasapi shared mode playback, so only exclusive works in this version. I'll fix and make a new release asap!
New preview published here: Release v1.0.0-alpha3 * HEnquist/camilladsp * GitHub
This contains fixes for the Wasapi and CoreAudio backends. Unfortunately the changes broke Wasapi shared mode playback, so only exclusive works in this version. I'll fix and make a new release asap!
Another preview: Release v1.0.0-alpha4 * HEnquist/camilladsp * GitHub
This should fix shared mode. It seems that this was a specific issue when capturing from the VB-AUDIO Cable in shared mode, probably because of some bug in that device. It doesn't work well with event-based timing. It's not a new issue (previous versions like 0.6.x are also affected), just strange that I haven't noticed before. I have implemented a workaround for it that has been running reliably here for several hours.
The other issue, that was solved in the previous preview, was that exclusive mode playback with event-based timing can end up in a strange state if the thread handling the playback gets delayed. Strangely wasapi doesn't provide any way of notifying that a buffer underrun has occured, it just starts acting strange and plays the stream at 2/3 of the rate it should (where the last 1/3 is made up of short gaps of silence, that's where the stuttering comes from). I could check for the reduced rate, but then it takes some time to detect. I implemented another solution where I'm looking for a glitch in the timestamps that the wasapi driver provides. This seems to work every time and detects the problem immediately. Then it resets the stream and the buffer underrun becomes just a small gap in the sound.
This should fix shared mode. It seems that this was a specific issue when capturing from the VB-AUDIO Cable in shared mode, probably because of some bug in that device. It doesn't work well with event-based timing. It's not a new issue (previous versions like 0.6.x are also affected), just strange that I haven't noticed before. I have implemented a workaround for it that has been running reliably here for several hours.
The other issue, that was solved in the previous preview, was that exclusive mode playback with event-based timing can end up in a strange state if the thread handling the playback gets delayed. Strangely wasapi doesn't provide any way of notifying that a buffer underrun has occured, it just starts acting strange and plays the stream at 2/3 of the rate it should (where the last 1/3 is made up of short gaps of silence, that's where the stuttering comes from). I could check for the reduced rate, but then it takes some time to detect. I implemented another solution where I'm looking for a glitch in the timestamps that the wasapi driver provides. This seems to work every time and detects the problem immediately. Then it resets the stream and the buffer underrun becomes just a small gap in the sound.
Hi Henrik,
The ability to use multiple cores and achieve low latency is one of the key strengths for BruteFIR. Could you tell me something about multi-core performance of CamillaDSP for FIR-filters? I.e. could one run a 2-ch in, 8-ch out FIR filter with low latency on e.g. a Raspberry Pi or low power CPU like Intel Gemini Lake?
Best regards!
The ability to use multiple cores and achieve low latency is one of the key strengths for BruteFIR. Could you tell me something about multi-core performance of CamillaDSP for FIR-filters? I.e. could one run a 2-ch in, 8-ch out FIR filter with low latency on e.g. a Raspberry Pi or low power CPU like Intel Gemini Lake?
Best regards!
CamillaDSP runs all filters in a single thread. This is because the filtering pipeline can be build very freely, and it's difficult to figure out what can be run in parallel with what. I am thinking about ways of splitting it in several threads but it won't be easy. And the splitting into more threads is likely to increase the minimum possible latency because of the overhead of shuffling data between threads.
However already a weak cpu today is quite powerful. For example a Raspberry Pi 4 can do FIR-filtering of 8 channels, with 262k taps per channel at 192 kHz, while using just over half a core. A Gemini Lake should be in the same ballpark.
Hi, Getting close to moving out of the setup phase with this marvellous software, but I've just found another issue and workaround. But maybe there's a better solution.
I'm now using a different soundcard (RME ADI-2 Pro FS R) that being oriented towards hifi rather than studio use includes a remote control and soft power off and on, so unlike with previous soundcards, it becomes attractive to power off when not in use.
Doing so causes the soundcard to disappear from Linux and then reappear for the next listening session. Whilst CamillaDSP has been left running the whole time since the previous session, it fails to resume processing.
So as expected, if I stop and restart the CamillaDSP process, then we're back in business. However, that's a CLI that I currently don't have an automation for. Nor am I aware of any other instruction to restart the process. But I do have an automation through Node-RED and the CamillaDSP websocket to reload the configuration file. Would that work?
Well, yes and no. If I simply reload the same configuration, CamillaDSP recognises that there's been no change to the config file (as it reports in the log file), and whatever it does subsequently fails to reset the programme, resulting in a deafening silence.
However, if I send it a different configuration file, then the debug level log reports that "Devices changed, restart required." and obliges with a restart, fixing the issue. Result, wonderful music resumes.
Is this how things are supposed to work? Or is there a better shortcut that I've missed. Thanks
I'm now using a different soundcard (RME ADI-2 Pro FS R) that being oriented towards hifi rather than studio use includes a remote control and soft power off and on, so unlike with previous soundcards, it becomes attractive to power off when not in use.
Doing so causes the soundcard to disappear from Linux and then reappear for the next listening session. Whilst CamillaDSP has been left running the whole time since the previous session, it fails to resume processing.
So as expected, if I stop and restart the CamillaDSP process, then we're back in business. However, that's a CLI that I currently don't have an automation for. Nor am I aware of any other instruction to restart the process. But I do have an automation through Node-RED and the CamillaDSP websocket to reload the configuration file. Would that work?
Well, yes and no. If I simply reload the same configuration, CamillaDSP recognises that there's been no change to the config file (as it reports in the log file), and whatever it does subsequently fails to reset the programme, resulting in a deafening silence.
However, if I send it a different configuration file, then the debug level log reports that "Devices changed, restart required." and obliges with a restart, fixing the issue. Result, wonderful music resumes.
Is this how things are supposed to work? Or is there a better shortcut that I've missed. Thanks