I'm attempting to use CamillaDSP for the first time, as an active 3-way crossover and probably to smooth & flatten the frequency response. I shall also be using it on Linux, with which I'm a relative novice. My starting point is (current) Debian, set up as a virtual machine (KVM/QEMU) with USB pass-through to a Topping DM7 8-way DAC (this works fine, simply playing direct to the DAC). The source will be any application (browser, player etc) that is running on the PC.
There is lots of useful info on Henrik's github site. I also found a tutorial on audiosciencereview for setting up a raspberry pi, which I had a go at adapting, but that might be out of date as CamillaDSP objected to some terms in the example config files. But anyway, I gather the process would be to install any dependencies, set up a loopback as a source, and make a config file for Camilladsp to call.
My initial uncertainties are:
Thanks!
Kev
There is lots of useful info on Henrik's github site. I also found a tutorial on audiosciencereview for setting up a raspberry pi, which I had a go at adapting, but that might be out of date as CamillaDSP objected to some terms in the example config files. But anyway, I gather the process would be to install any dependencies, set up a loopback as a source, and make a config file for Camilladsp to call.
My initial uncertainties are:
- If I use the pre-built executable (camilladsp-linux-amd64.tar.gz), which dependencies and prerequisites are needed?
- Henrik is doing great things developing a new version; if I'm to learn how to use CamillaDSP, would it be better to use this new version even though it is still in alpha release?
- The gitub config page involves setting things up as a systemd service, I've not seen this mentioned by many people using CamillaDSP; is it a necessary step?
Thanks!
Kev
Hi, before you go any further have you confirmed that you can get audio from software on the host to the VM? Or will you be running your browser etc from within the VM as well?
For your questions:
1. On latest Ubuntu and Fedora I don't think I needed to install anything extra to get the pre-built executable running with ALSA, Pulseaudio or Pipewire. The GUI does need extra dependencies installed. There's an install script listed in the main thread here recently.
2. Yeah just start with the new version
3. Running as a service isn't necessary, it's just one way of having it automatically run at system start
For your questions:
1. On latest Ubuntu and Fedora I don't think I needed to install anything extra to get the pre-built executable running with ALSA, Pulseaudio or Pipewire. The GUI does need extra dependencies installed. There's an install script listed in the main thread here recently.
2. Yeah just start with the new version
3. Running as a service isn't necessary, it's just one way of having it automatically run at system start
Hi, thanks for the reply! That helps; there is lots of detailed info provided, but I lacked a mental overview so wasn't fully clear on what parts of it were necessary etc.
Yes, all the audio will be coming from within the VM. It is essentially a virtual alternative to having a dedicated media machine; I can still play around within it whilst not affecting the host machine.
That install script could be helpful, too. I probably don't need a GUI but it might be nice to have, especially if I have any issues understanding, or checking, what is going on.
Thanks again,
Kev
Yes, all the audio will be coming from within the VM. It is essentially a virtual alternative to having a dedicated media machine; I can still play around within it whilst not affecting the host machine.
That install script could be helpful, too. I probably don't need a GUI but it might be nice to have, especially if I have any issues understanding, or checking, what is going on.
Thanks again,
Kev
I have had some issues with the alsa loopback running inside VMs. It works but behaves a bit strange. I think it's some issue with timing that gives unexpected buffer underruns. I haven't spent any time on investigating so can't say more than this, just be aware that it may not be smooth sailing. @phofman maybe knows more?
I only use VMs running windows, for developing some win-only audio stack and running some win-only sw, no experience with VMs running linux (on my servers I use linux containers, not full-stack virtualization). But I also keep getting random delay peaks in VMware Player, it is unreliable for time-critical tasks. I agree with @HenrikEnquist that it may be a major hassle to get rid of xruns, if at all.
@Kev06 : Is the virtualization really necessary in your case?
@Kev06 : Is the virtualization really necessary in your case?
Thanks @HenrikEnquist and @phofman , that is very useful to know. The VM's virtual sound-card certainly had a lot of lag (which was solved with a USB pass-through to a real DAC), but I hadn't anticipated that loop-backs might also behave differently within a VM. I suppose conceptually these are a pseudo hardware device for ALSA, maybe there is something that doesn't play nicely with other hardware virtualisation (but that is just a wild guess).
Unfortunately I don't want my audio-related stuff running directly on the main host. The audio side of things involves running less secure protocols and software which isn't always very professional or robust. It needs a place to tinker and have fun without risk to more important things, hence the VM.
But maybe one could have just camilladsp on the host, and 'somehow' stream to it from within the existing VM. Or an additional low powered machine for camilladsp to make a dedicated crossover (and DSP etc) box - more complication and hardware needed, but in some ways also more flexible.
Unfortunately I don't want my audio-related stuff running directly on the main host. The audio side of things involves running less secure protocols and software which isn't always very professional or robust. It needs a place to tinker and have fun without risk to more important things, hence the VM.
But maybe one could have just camilladsp on the host, and 'somehow' stream to it from within the existing VM. Or an additional low powered machine for camilladsp to make a dedicated crossover (and DSP etc) box - more complication and hardware needed, but in some ways also more flexible.
The thing is alsa loopback needs a precise SW timer (to substitute for hw clock of a real soundcard) which may not run precisely and nicely in the virtualized kernel. Maybe if you choose the right virtualization engine and adjust your HW to use as much of HW resources as possible (all the CPU virtualization support etc.), it will work OK on your HW. But it will take some deep digging into virtualization know-how, IMO.
Ah, that makes sense, I understand a little better now; thank you. Well, it 'might' work on my machine (it is a reasonably capable thing, as is QEMU/KVM). But it looks to be uncertain, unreliable and potentially difficult - none of which are very appealing.
Perhaps I could replace the software loop-back with an actual hardware equivalent. So an audio output device connected to an audio input/capture-device on the same VM.
Or have the input/receiving device on a different 'camilladsp' VM, or even separate mini-PC for camilladsp; there seem to be a few more options with a hardware link.
Perhaps I could replace the software loop-back with an actual hardware equivalent. So an audio output device connected to an audio input/capture-device on the same VM.
Or have the input/receiving device on a different 'camilladsp' VM, or even separate mini-PC for camilladsp; there seem to be a few more options with a hardware link.
Well there has been a small delay, because the helpful advice above resulted in me looking for better alternatives. Just to summerise (partly so that I don't forget, myself):
As loopbacks in a VM are less reliable, I instead tried using a USB pass-through to external hardware. Specifically, a raspberry Pi, set up as a USB audio gadget and running CamillaDSP. The pi, audio-gadget and CDSP worked fine but unfortunately there were still VM issues; opening a completely different VM would make my audio-playing VM forget its volume settings, for example. Presumably something to do with how qemu/kvm juggles resources for the VMs, but that is just a guess. So I have given up on VMs for the purpose, as they're more complex and annoying than I'd expected and I lack the abilities needed to solve this.
I considered a separate, dedicated machine, but in the end have decided to just set up CamillaDSP on the host OS. This is a fairly important machine for me, but it is very capable and I don't think CDSP or an alsa-loopback poses much of a security or reliability threat to it, so IMO should be fine. Ditto for local music-playing applications. Probably internet/browser based streaming would be fine too; I will test audio from firejailed browsers for an extra layer of safety, but don't envisage any problem. I'll simply avoid running more complicated/risky protocols and services (such as uPNP combined with serving or remote access over the internet). Possibly these could be treated as a separate case, and still be run in a separate VM (the network seems to run ok via the VMs).
There was another slight delay due to my ignorance of how alsa-loopbacks work and that the OS (current Debian) now uses pipewire (here) but I'm new to all this (especially with linux); others might well find it obvious. Anyway, I'm very pleased now to be listening to music played to a pipewire sink which feeds an alsa-loopback as capture-device for CamillaDSP, which is providing a software crossover and playing to a multiway-USB DAC. So the next step is to look at things like frequency-response tweaking and possibly also room corrections. Happy days! Mostly made possible by the selfless work put in by people (who participate actively on this forum) in creating these amazing things, which I can barely grasp the edges of.
As loopbacks in a VM are less reliable, I instead tried using a USB pass-through to external hardware. Specifically, a raspberry Pi, set up as a USB audio gadget and running CamillaDSP. The pi, audio-gadget and CDSP worked fine but unfortunately there were still VM issues; opening a completely different VM would make my audio-playing VM forget its volume settings, for example. Presumably something to do with how qemu/kvm juggles resources for the VMs, but that is just a guess. So I have given up on VMs for the purpose, as they're more complex and annoying than I'd expected and I lack the abilities needed to solve this.
I considered a separate, dedicated machine, but in the end have decided to just set up CamillaDSP on the host OS. This is a fairly important machine for me, but it is very capable and I don't think CDSP or an alsa-loopback poses much of a security or reliability threat to it, so IMO should be fine. Ditto for local music-playing applications. Probably internet/browser based streaming would be fine too; I will test audio from firejailed browsers for an extra layer of safety, but don't envisage any problem. I'll simply avoid running more complicated/risky protocols and services (such as uPNP combined with serving or remote access over the internet). Possibly these could be treated as a separate case, and still be run in a separate VM (the network seems to run ok via the VMs).
There was another slight delay due to my ignorance of how alsa-loopbacks work and that the OS (current Debian) now uses pipewire (here) but I'm new to all this (especially with linux); others might well find it obvious. Anyway, I'm very pleased now to be listening to music played to a pipewire sink which feeds an alsa-loopback as capture-device for CamillaDSP, which is providing a software crossover and playing to a multiway-USB DAC. So the next step is to look at things like frequency-response tweaking and possibly also room corrections. Happy days! Mostly made possible by the selfless work put in by people (who participate actively on this forum) in creating these amazing things, which I can barely grasp the edges of.
Can anyone tell me what this line is indicating?
2023-12-29 16:39:13.528360 DEBUG [src/countertimer.rs:42] Pausing processing
When streaming internet/browser music to an alsa loopback and then camilladsp, the (linux) PC loses internet, on occasion. I don't yet know why, but the above line is always the last that CamillaDSP offers; so it may provide an insight if I knew what it meant. (Turning the LAN connection off and on again allows the connection to be regained, though sometimes it takes a few attempts).
Thanks,
Kev
2023-12-29 16:39:13.528360 DEBUG [src/countertimer.rs:42] Pausing processing
When streaming internet/browser music to an alsa loopback and then camilladsp, the (linux) PC loses internet, on occasion. I don't yet know why, but the above line is always the last that CamillaDSP offers; so it may provide an insight if I knew what it meant. (Turning the LAN connection off and on again allows the connection to be regained, though sometimes it takes a few attempts).
Thanks,
Kev
Thank you, Henrik. Yes I have "silence_timeout: 3.0" in the config so that makes sense. It seems likely the problem will be upstream then, with CamillaDSP simply acting as expected when the network freezes; it doesn't resume because there is never any more audio.
So more investigation needed. It seems a little strange, as the individual components appear to work. Browser/internet streaming direct to the DAC doesn't have a problem, and nor does playing local files to the loopback (then CamillaDSP). It only happens when browser/internet streaming to the loopback (either with chromium or firefox).
Perhaps the loopback isn't gracefully handling interruptions in the audio stream, which will happen occasionally over the internet (even with decent buffers) but not when playing local files. Somehow causing the network to hang, instead of simply waiting for the stream to resume. I'll have a look at Pipewire's alsa-loopback config, in case there is anything obvious to me.
So more investigation needed. It seems a little strange, as the individual components appear to work. Browser/internet streaming direct to the DAC doesn't have a problem, and nor does playing local files to the loopback (then CamillaDSP). It only happens when browser/internet streaming to the loopback (either with chromium or firefox).
Perhaps the loopback isn't gracefully handling interruptions in the audio stream, which will happen occasionally over the internet (even with decent buffers) but not when playing local files. Somehow causing the network to hang, instead of simply waiting for the stream to resume. I'll have a look at Pipewire's alsa-loopback config, in case there is anything obvious to me.
Yes CamillaDSP could be set up to capture from a pulse audio null sink (also with pipewire via the PA api). But going via an Alsa loopback instead gives lower CPU usage, and also provides the adjustable clock needed for rate adjust. With PA/pipewire only, the resampler is needed for that.
phofman, the chain is: Browser -> Audio-Loopback -> CamillaDSP -> USB-multichannel-DAC
The alsa loopback is created in pipewire's config, following Henrik's helpful instructions at section 6 here - I very much like the ability to select the loopback like any other output device, via the desktop's GUI. But I'm 'very' new to pipewire so my implementation of it is a point of suspicion. If this issue becomes hard to trace, I could try reverting to editing either etc/modprobe.d/alsa-base.conf or /etc/modules
Thanks for the pointer on dmesg, I'll have a dig around next time it happens. I'm not hugely familiar with linux and have depressingly little time outside work over this busy season, so have only just started to think about trying to track it down. I appreciate your help, and will certainly investigate further!
Thanks again,
Kev
The alsa loopback is created in pipewire's config, following Henrik's helpful instructions at section 6 here - I very much like the ability to select the loopback like any other output device, via the desktop's GUI. But I'm 'very' new to pipewire so my implementation of it is a point of suspicion. If this issue becomes hard to trace, I could try reverting to editing either etc/modprobe.d/alsa-base.conf or /etc/modules
All internet access by the PC is lost, until the LAN connection is turned off and on again - but I haven't actually checked to see if the local network is still available; good point. This has only so far happened when streaming audio to the loopback, I've not noticed it at any other time, so there 'seems' a likely correlation - but it might still be coincidence, or both might be effects of something else.
Thanks for the pointer on dmesg, I'll have a dig around next time it happens. I'm not hugely familiar with linux and have depressingly little time outside work over this busy season, so have only just started to think about trying to track it down. I appreciate your help, and will certainly investigate further!
Thanks again,
Kev
As was expected, I can now absolutely confirm that CamillaDSP and/or the loopback are not the cause of this issue. For some reason it mostly occurs when they're in use, but it has (at last) also occurred a couple of times when they have not been; it is more intermittent then, and the logs don't show anything helpful, so took me a while to verify.
Anyway, it is almost certainly related to the motherboard's Realtek 2.5gig NIC (since use of a borrowed usb-lan dongle solves it). I've found a few suggestions that the drivers in the linux kernel may be problematic for some users. I don't want to manually install direct from the manufacturer because kernel updates won't respect that. But I shall try turning off the EEE option, maybe try Fedora in case a newer kernel has better drivers, or failing that just get a PCIe NIC card that is known to work with kernel drivers.
Anyway, it is almost certainly related to the motherboard's Realtek 2.5gig NIC (since use of a borrowed usb-lan dongle solves it). I've found a few suggestions that the drivers in the linux kernel may be problematic for some users. I don't want to manually install direct from the manufacturer because kernel updates won't respect that. But I shall try turning off the EEE option, maybe try Fedora in case a newer kernel has better drivers, or failing that just get a PCIe NIC card that is known to work with kernel drivers.