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

I imagine websocket is also more portable between windows and linux than standard sockets anyway.

Switching to json sounds like a good idea. There are json parsers for pretty much everything and it's easy to decipher as plaintext too.

My mention of console to websocket was only in the context of maybe it would be the easy. Since you've stated that's not the case I don't see it as being very important. It sounds like you're already planning to add the useful information to the websocket.
 
Hello.

I am really enjoying CamillaDSP. Thank you.

I attempted to look through the 85 pages, quickly, and search, but I didn't find any obvious response to this.

Before I drive myself crazy, is this known or expected:

Windows 10.
Using VB-Cable
I am able to set the (Playback) CABLE Input to 5.1 by doing "configure speakers", but I am unable to get the (Recording) CABLE Output to do more than 2 channels.

From what I can tell, that means, when I try:

capture:
type: Wasapi
channels: 6
device: "CABLE Output (VB-Audio Virtual Cable)"
format: FLOAT32LE

I end up with:
Capture error: The requested stream configuration is not supported by the device.

However, I can set the capture back to 2 channel, configure my onboard sound card to 5.1, and set it to 6 speakers:

playback:
type: Wasapi
channels: 6
device: "Speakers (Realtek High Definition Audio)"
format: FLOAT32LE

and use mixers to output any of the 2 captured channels from the Cable Output to any of the 6 channels on the Realtek correctly.

Does this make sense? Is this a known limitation of VB-Cable and/or windows 10? Some research has shown that Windows XP allowed 8 channels of recording.

Thanks!
 
Last edited:
IME the VB cable has many limitations. I tested the free version for bit-perfection when trying to run my distortion-compensation tool on windows and have never attained 24bit perfection of the loopback. I would not be surprised if it supported two channels only.

Jackd + JackRouter ASIO driver are bit-perfect (and probably support any channel count you want). Just operation of the chain is more complicated because you have to start components in correct order for the whole chain to run correctly with no error messages.
 
Good luck. Windows is a P..A to do any non-standard audio setup, the OS itself lacks most of the important building blocks, "standards" change with every version, very little open source is available due to the driver/app signing craze. Only third-party proprietary tools are available, often buggy with blurr chances of improvement.

I believe a much more reliable way is building the whole chain in embedded linux running on inexpensive HW and presenting the device to windows as standard USB-audio gadget, just to use the dummy windows for GUI playback and control. The linux USB gadget supports combined mode where usb-audio and USB-network devices can run concurrently, allowing control of the linux chain via windows browser. That is a plan for my next project and CamillaDSP already has a great web interface.

As a step forward, linux has a reliable USBIP toolset and even supports hooking the USB gadgets to the USBIP driver, allowing to connect the virtual USB devices over regular network - 100m range, galvanic isolation for free. I tested USBIP some time ago, worked great Linux host - linux device while getting some bug windows host - linux devices. But the USBIP developers are working hard to iron the problems out Issues * cezanne/usbip-win * GitHub
 
Hello.

I am really enjoying CamillaDSP. Thank you.

I attempted to look through the 85 pages, quickly, and search, but I didn't find any obvious response to this.

Before I drive myself crazy, is this known or expected:

Windows 10.
Using VB-Cable
I am able to set the (Playback) CABLE Input to 5.1 by doing "configure speakers", but I am unable to get the (Recording) CABLE Output to do more than 2 channels.

From what I can tell, that means, when I try:

capture:
type: Wasapi
channels: 6
device: "CABLE Output (VB-Audio Virtual Cable)"
format: FLOAT32LE

I end up with:
Capture error: The requested stream configuration is not supported by the device.

However, I can set the capture back to 2 channel, configure my onboard sound card to 5.1, and set it to 6 speakers:

playback:
type: Wasapi
channels: 6
device: "Speakers (Realtek High Definition Audio)"
format: FLOAT32LE

and use mixers to output any of the 2 captured channels from the Cable Output to any of the 6 channels on the Realtek correctly.

Does this make sense? Is this a known limitation of VB-Cable and/or windows 10? Some research has shown that Windows XP allowed 8 channels of recording.

Thanks!
I have only tried stereo before, but I tried to record more channels now. I also can't get VB-Cable to output more than two. Seems to be a known limitation since Windows Vista: 5.1 with Virtual Cable? - VB-Audio's Forums
 
IME the VB cable has many limitations. I tested the free version for bit-perfection when trying to run my distortion-compensation tool on windows and have never attained 24bit perfection of the loopback. I would not be surprised if it supported two channels only.

Jackd + JackRouter ASIO driver are bit-perfect (and probably support any channel count you want). Just operation of the chain is more complicated because you have to start components in correct order for the whole chain to run correctly with no error messages.
The ASIO part may be a showstopper here(?).



There is ASIO support in CPAL and I have tried enabling it for CamillaDSP. It does kind of work, but with many problems. First of all it's limited to 16-bit for most hardware. And there were strange problems when closing devices which caused problems both when exiting CamillaDSP and when reloading the config. I decided to not include this in CamillaDSP yet and I haven't had time to look into it any further
 
I believe a much more reliable way is building the whole chain in embedded linux running on inexpensive HW and presenting the device to windows as standard USB-audio gadget, just to use the dummy windows for GUI playback and control. The linux USB gadget supports combined mode where usb-audio and USB-network devices can run concurrently, allowing control of the linux chain via windows browser. That is a plan for my next project and CamillaDSP already has a great web interface.
Is it possible to use the audio gadget mode with windows now? I tried it with my pi4 (raspbian 10.3, kernel 4.19.97), and windows found the device but could not start it. I googled a bit and it seems the gadget is missing some stuff that windows requires. It it working with more recent kernels?
 
Is it possible to use the audio gadget mode with windows now? I tried it with my pi4 (raspbian 10.3, kernel 4.19.97), and windows found the device but could not start it. I googled a bit and it seems the gadget is missing some stuff that windows requires. It it working with more recent kernels?

Ruslan sent a bugfix for windows recently, I would recommend compiling the latest version 5.9 from RPi repo with the latest commit linux/f_uac2.c at rpi-5.9.y * raspberrypi/linux * GitHub . Before compiling also change the EP OUT from asynchronous to adaptive usb:gadget:f_uac2: EP OUT is adaptive instead of async - Pavel Hofman so that windows does not fail on missing feedback EP for async EP OUT.
 
In the GUI I cannot change to PulseAudio:
020-09-22T19:20:17Z ERROR camillalib::socketserver] Config error: devices.capture.type: unknown variant `PulseAudio`, expected one of `Alsa`, `Pulse`, `File`, `Stdin` at line 7 column 11
Oops sorry! I'll fix that tomorrow.

Ruslan sent a bugfix for windows recently, I would recommend compiling the latest version 5.9 from RPi repo with the latest commit linux/f_uac2.c at rpi-5.9.y * raspberrypi/linux * GitHub . Before compiling also change the EP OUT from asynchronous to adaptive usb:gadget:f_uac2: EP OUT is adaptive instead of async - Pavel Hofman so that windows does not fail on missing feedback EP for async EP OUT.
This is good news, thanks! I'll try it :)
 
Fixed and a newly built beta5 is available.




Sure, I'm always interested in new ideas! Providing the logger output on the websocket would be possible but it would add a fair bit of complexity. You would also need to do a lot of parsing of the messages to get what you want.

What info are you missing on the websocket as it is? It's probably easier to just add the missing bits there.




I have picked what seems to be the most common way. If the coefficients are one of the integer formats, the value range is the full range of the integer type, -2^31 to (2^31-1) for S32LE for example. For Float, the range is -1.0 to +1.0. I will add something in the readme about this.





My intention with the websocket server was that it should be used locally with for example a python client. That it could be used directly from a browser is just a bonus, but I see how it can be useful. I'll take a look to see how difficult it would be to add wss.

I second the request for a clip indicator. Perhaps a bit like a min/max thermometer which shows max level until cleared? Or clipping events since last boot?
 
I am consistently seeing CamillaDSP at 100% CPU after about 12 hours of inactivity (i.e. no music inbound to process). I am using the latest 3.2 beta5 ARMV7 build. Web GUI still responds but a reboot is required to get it to process music again.
 

Attachments

  • 100pc.png
    100pc.png
    189.4 KB · Views: 265
Last edited:
I am consistently seeing CamillaDSP at 100% CPU after about 12 hours of inactivity (i.e. no music inbound to process). I am using the latest 3.2 beta5 ARMV7 build. Web GUI still responds but a reboot is required to get it to process music again.
This is probably caused by some error in the capture or playback threads that causes the thread to panic and exit. Could you see if you can catch that in the log, and post the message here?
 
Ok dumb question where can I find the log? I already checked dmesg and couldn't see anything relevant. Camilla is being started at startup using jespers script.
The easiest is to start it manually in a terminal, then you get all the log messages printed there. You can also redirect to a file (probably a better idea since it will need to run for a long time before this happens). The log messages are printed to stderr. To store them in a file do this:
Code:
camilladsp -p 1234 some_config.yml 2>logdump.txt

The "2" is to redirect stderr and not stdout. You should not need to run it in verbose mode with -v since this error should be printed in any case.
 
I have now released version 0.3.2, and 0.4.0-beta1.


The changes of 0.4.0 are:
New features:
- New commands to get more playback information from the websocket server.
- Changed all websocket commands to use Json input and output.
- Added support for secure websocket connections (wss)

Bugfixes:
- Better handling of input device errors, fixes 100% cpu usage after panic.



0.4.x introduces a new format of the websocket commands where both commands and responses are in json format. Because of this, it also requires a new version of pyCamillaDSP, which is also version 0.4.0. This is the version currently in the develop branch of pyCamillaDSP.


For the gui, there is a new version as well with various fixes. It also displays the current buffer level and number of clipped samples since the processing started. I will replace this ina later version with a Clipping indicator and some kind of VU meter instead of showing the signal level just as a number.
 
A ready made, installable web interface please. Pretty please? :-D

//

I'm thinking about ways to make the gui easier to set up.
The idea so far is to make scripts for a few common systems.
The systems could be for example:
- Stock Raspbian
- Stock Fedora
- macOS with Anaconda already installed
- Windows with Anaconda already installed

Those are good starting points since from there everything can be installed by a script.
I'll start on this once the gui feels a little more ready.