CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc

Jump to Latest
#1,741
It is surprising the CPAL team would not be interested in wasapi exclusive mode. E.g. the host layer was added which goes directly towards this Provide a `Host` API? (A path towards supporting alt-backends like ASIO, Windows Exclusive Mode, PulseAudio, Jack) * Issue #204 * RustAudio/cpal * GitHub -> Introduce a `Host` API by mitchmindtree * Pull Request #289 * RustAudio/cpal * GitHub. IIUC the intended way would be a new host API implementation wasapi_exclusive assigned to the windows cpal/mod.rs at master * RustAudio/cpal * GitHub
 
#1,744
Daihedz said:
If CamillaDSP does not in it's linux flavor, then at least it's not a CamillaDSP issue: The Digiface USB device does not provide class compliant mode and probably never will. Therefore chances are very small that it will ever work under Linux.

Have a look at: is DigiFace USB Class Compliant? (Page 1) — FireWire & USB series — RME User Forum
Click to expand...

Way fwd???

RME Digiface USB - Linux - Ardour

See last post... a Digiface and a Pi4 would be yummy 🙂 but I'm no programmer...

//
 
Last edited:
#1,745
gingerbeer said:
Your earlier post said it sounded really good over two days of listening yet this sounds like it clearly failed. Can you elaborate a bit more on what didn’t work and how you reached your conclusion.

Bit I’m particularly interested in is whether the USB devices stayed aligned with each other as it would really widen the options if I didn’t need a multichannel dac for my actives.
Click to expand...
For my prof of concept is used a setup like this in my little office:

Tweeters -> USB DAC 1 -> Cheap Headphones
Mids -> Macbook Integrated Speakers
Bass -> DAC 2 -> Old Subwoofer

And it works quite well - no apparent problems with sync - but then again I was not listening that detailed...
 
#1,746
TNT: Damien is very competent, no doubts. I would be a bit afraid of the two bulk output endpoints - could be some DSP firmware upload - e.g. either for upgrading a firmware in flash (good) or for uploading to SRAM/FPGA (bad).

Anyway for testing you do not need to be a programmer - just adding the code to the file Damien mentions and re-compiling kernel.
 
#1,748
OK! Recompiling requires "programming" skills ;-)
Click to expand...

Actually it's mostly copy/paste a few commands from some tutorial, e.g. Kernel/BuildYourOwnKernel - Ubuntu Wiki . The debian/ubuntu process is simple:

* download pre-configured kernel sources of the currently running kernel (apt source ...)
* compile + build packages + install them + reboot to the new kernel to test the process - this takes a while (the linked tutorial does not compile with multiple cores but that is a trivial modification)
* make changes to the files - only adding the quirk code to that file
* re-compile - this is fast as only the usb-audio module will be compiled
* overwrite the existing module file with the new one or build packages + re-install them

I don't even have the insight to grasp your concern re "upload" - hacking??
Click to expand...

I did not mean to hack/reverse-engineer the communication. I am just afraid the bulk endpoints may be used actively when configuring the device before it resorts to some (often customized) usb-audio protocol. Or maybe not. Capturing the USB communication in windows with wireshark would tell but still there would likely be a long way to learning all the details.

Do you believe it could work?
Click to expand...

Damien looked at the device USB configuration (as reported by lsusb -v) and made some very logical/experienced guesses in his quirk. But the reality can be quite different, and only testing his quirk would tell.

On the other hand, if proper support required only that simple quirk (which just hard-codes missing USB configuration options - a correct USB audio device would report them all by itself), why would RME flat refuse to do it, if some of their other soundcards have excellent (and quite complicated) alsa drivers...
 
Last edited:
#1,751
CamillaDSP + Asus Xonar U7 MKII - a winning combination

Hi All,

Now using Asus Xonar U7 MKII + CamillaDSP - and that works !

The Asus Xonar U7 MKII is a 7.1 USB "surround processor" - which actually has 8 x DAC capable of 24bit/ 192Khz - with a SINAD of 102db - not bad for a €90 box.

I have the Asus Xonar U7 MKII acting as front end to a CamillaDSP with a 3 way filter - and there are NO issues with the stereo perspective - the 8 DAC's are perfectly synchronized.

Additional info - you can use the Xonar as a 2, 4, 6 or 8 way DAC.
 
#1,752
Great! One thing, that is easy to overlook, is that the dacs and amplifiers get a much easier job when each channel only needs to handle a fraction of the frequency range. So you can get away with using cheaper dacs and amps, and the difference when upgrading to something better might not be that big.
 
#1,757
TNT: I am afraid you really need to run linux to compile linux kernel and test its module.

You could compile on RPi but it will take forever and the SD card will not be happy. Any reasonable amd64 machine with SSD drive/8GB RAM would do. You can compile & test on x86, USB device drivers use identical source code for any architecture.
 
#1,759
VB is OK for compilation, but for testing it presents another layer of complexity. VB supports redirecting USB devices to guests (e.g. How to Access USB from VirtualBox Guest OS - LinuxBabe in linux host) but if the soundcard does not work in the guest, is the problem in the patched driver or in the redirection of raw USB device to the VB guest (or both co-operation with the patched driver)? Too many degrees of freedom...

You can crosscompile for RPi in VB, but that takes much more effort than native kernel compilation + installing onto RPi ... to learn the patch does not work.
 
You must log in or register to reply here.
Top Bottom