Support for ASIO

[siraaris]

Devices on Windows with more than 8 ch are presented as multiple WDM devices with 8 ch each.

In contrast the ASIO driver presents the whole channel count.

For these devices, CamillaDSP can't be used on Windows.

Would it be possible to add a build option ASIO backend?

I understand that ASIO and GPLv3 licensing does not support distribution of a binary, but a self-build option would work for people who need it.

I had a brief search for Rust ASIO libraries, some seem reasonable.

[HEnquist]

Devices on Windows with more than 8 ch are presented as multiple WDM devices with 8 ch each.

This is not determined by WDM, there is no 8 channel limit. The manufacturer has simply chosen to present the device like this. This is quite common (and also quite annoying). The Motu M4 for example is presented as two stereo devices.

Would it be possible to add a build option ASIO backend?

I understand that ASIO and GPLv3 licensing does not support distribution of a binary, but a self-build option would work for people who need it.

I had a brief search for Rust ASIO libraries, some seem reasonable.

ASIO has a number of problems in addition to the license. See for example here: https://www.diyaudio.com/community/threads/camilladsp-cross-platform-iir-and-fir-engine-for-crossovers-room-correction-etc.349818/post-6813205
and
https://www.diyaudio.com/community/threads/camilladsp-cross-platform-iir-and-fir-engine-for-crossovers-room-correction-etc.349818/post-6264227
There are supposedly ways to work around these problems but implementing a new backend is already a lot of work without having to deal with such stuff. The only asio binding I'm aware of is the low level asio-sys that is used in the CPAL library. I don't really have the time to implement and maintain an asio backend.

Then one reasonable path I see is to use the asio support of CPAL. This would be quite straightforward since CPAL is already used by the jack backend. Unfortunately this worked very poorly last time I tried it. I'm following the development there, but asio doesn't seem to be a priority so not much happens.

[siraaris]

My device is a RME Digiface AVB, and inherently has a large channel count, and I use it to access a M32-DA Pro DAC which has 32 ch analog output.

I can't use CamillaDSP for this on Linux yet but am hopeful that AVB support in Pipewire will eventuate fully in the future.

On macOS I observe glitches - restarts and buffer issue that I've not managed to eliminate.

On Windows, WDM isn't an option with CamillaDSP as the 32 channels I need are presented as 4x8ch.

I've tried another convolver on Windows with ASIO and I observe very solid performance. No evidence of glitches seen on macOS.

So, I do have a workable solution, of course would prefer to use CamillaDSP.

I'll watch this issue and the repo generally if the ASIO CPAL backend becomes an option in the future!

[HEnquist]

On macOS I observe glitches - restarts and buffer issue that I've not managed to eliminate.

This doesn't usually happen on macOS, it's normally very reliable there. Is it easy for you to switch to macOS to run some tests? I would be interested in what the camilladsp logs say when there are problems.

[HEnquist]

I updated the old experimental ASIO branch to try. Things are somewhat improved since my last try, but it's not bug free and there are some quite severe limitations.

This is in the next30-asio branch here: https://github.com/HEnquist/camilladsp/tree/next30-asio

The ASIO api does not like the way that CamillaDSP accesses devices from different threads, meaning that it's only possible to use ASIO for capture or playback, not both at the same time.
See the readme section here: https://github.com/HEnquist/camilladsp/tree/next30-asio?tab=readme-ov-file#experimental-asio-support

In short I don't think that this works very well currently and I'm hesitant to include it. But maybe it's still useful for someone.

[siraaris]

Thank you, and sorry, I missed this update. I've got a dev environment on Windows now, so will give this a try.

[siraaris]

On macOS I observe glitches - restarts and buffer issue that I've not managed to eliminate.

This doesn't usually happen on macOS, it's normally very reliable there. Is it easy for you to switch to macOS to run some tests? I would be interested in what the camilladsp logs say when there are problems.

I have to setup my laptop a bit, but shouldn't be difficult. Will send logs over.

[siraaris]

Compiled next30-asio branch, including the dependency requirements. I modified the .YML file from the version I was using on macOS, and get the following - seems to be stuck on a particular filter (KS-T).

camilladsp-asio-log.txt

[siraaris]

Config file attached.
cexe.yml.txt

[siraaris]

Ok, this is very weird. After navigating to the directory where the filter files are (File Explorer), and started CamillaDSP again, it works (or at least progresses) further now. I really don't understand why this would be happen, but happy that things are progressing, but still weird.

... actually no. Restarted camilladsp, and now get this error:

memory allocation of 1248 bytes failed

Confused.

[siraaris]

Another error:

fatal runtime error: Rust cannot catch foreign exceptions

Something is definitely not right.

Attaching another trace when it starts, but something's not right with the rate (I've set it to 96k but reporting 16k, 48k etc).

Uploading camilladsp-asio-log-sort-of-working.txt…

[siraaris]

Thanks for creating the branch! That was fun. Tantalisingly close, but not quite :-)

[siraaris]

I should have read the readme sorry, clearly I need to use a virtual device not capture and playback on the same.

[HEnquist]

I should have read the readme sorry, clearly I need to use a virtual device not capture and playback on the same.

Yeah this is a pretty significant limitation, and it's really not an easy one to get around. Capture and playback needs to be done in the same thread, not separate threads like camilladsp does it now (which works fine for all the other audio APIs).

[siraaris]

I used a Windows loopback program (https://www.nerds.de/en/loopbeaudio.html) to handle 2ch input via Roon to bring into Camilla as a 2ch (Wasapi) capture, and using Asio as the (32ch) playback.

Now the app runs, and processes but I notice:

• Lots of dropped frames from Wasapi
• Variable rates from Wasapi

Both of these are weird as the rate is fixed in Windows sound control panel and Roon resamples to the chosen rate (96khz).

Hope the logs provide some indication of what's going on or potential hint at ways to fix.

camilla-asio-wasapi.log.txt

[HEnquist]

This is a problem:

Processing load: 613.6589%

This basically means that the CPU is overloaded by more than 6x. I see you have a lot of FIR filters, but not so many that I would expect that huge load. The reason is probably that you are using an unusual chunksize of 19200. Try with a power of two instead, for example 16384. That should make the convolution run much faster.