There seems to be something strange with the loopback on the current Raspberry OS. The capture seems to be affected by what happens on the playback side. When playback stops, the it appears that the capture side stops providing data. That causes weird stuff like the very slow exit on ctrl-c.
It doesn't happen on my fedora laptop (kernel 5.13) and I haven't had time to investigate further than that yet.
It doesn't happen on my fedora laptop (kernel 5.13) and I haven't had time to investigate further than that yet.
Update on the previous post. I have been trying to reproduce this problem on a Pi, but haven't managed. I tried Raspberry Pi OS, 64-bit with kernel 5.14 rc5, and 32-bit with kernel 5.10.52-v7l+.
I can't trigger any buffer underruns ("WARN Prepare capture device, module: camillalib::alsadevice" as shown in the log posted by @johnanon) by starting and stopping playback through the alsa loopback. I got a report of the same problem as an issue: Buffer Underrun, Broken Pipe, Service Restart when Pausing Raspotify * Issue #131 * HEnquist/camilladsp * GitHub
There seems to be very little in common between the two systems.
Did anyone else see something like this?
I can't trigger any buffer underruns ("WARN Prepare capture device, module: camillalib::alsadevice" as shown in the log posted by @johnanon) by starting and stopping playback through the alsa loopback. I got a report of the same problem as an issue: Buffer Underrun, Broken Pipe, Service Restart when Pausing Raspotify * Issue #131 * HEnquist/camilladsp * GitHub
There seems to be very little in common between the two systems.
Did anyone else see something like this?
If you run all the systems as daemons (services) I find the 64 bit ARM system with all latest upgrades has no stability problems you describe and no glitches in the playback stream (buffer underruns).
(Raspberry Pi OS, aka debian buster).
I am using it as an automated radio player, which comes up with a playlist on VLC on boot.
It's very successful and completely bug free after our huge effort of this spring.
I can suspend the player, shut down camilla, and restart it as well.
Loopback has never caused a problem and starts on boot.
In the system log, the only thing I ever get is "clipping detected" at level...whatever, when I start overloading it.
I am currently using the OEM headphone output (HDMI) and it works fine.
Last edited:
I think the universe is trying to tell me something ...
I took a break from bashing my ahead against the loopback wall, and thought I'd try your suggestion. How hard could that be?
Well, I had a device to hand, so I went ahead and plugged my Chromecast Audio TOSLINK directly into the UltraLite. I disconnected the UL from the Pi and plugged it in directly to my MAC to run CueMix 5 to see what was going on inside the UL. I discovered that this combination works at 44.1 and 48kHz, but not at 88.2 or 96kHz. The two lower frequencies play fine with the UL clock set either to Optical (as expected) or Internal (which I did not expect). However, with the two higher frequencies, the UL is unable to lock on to the CCA clock when setting the clock to Optical - the LOCK message flashes on front panel. Using the Internal clock setting (which I wouldn't expect to work at all) does actually get some sound out, but largely masked by a high frequency crackle (caused by the clocks being misaligned I guess).
So I did a factory reset on the CCA, but that made no difference to the interaction with the UltraLite. So no point trying to feed in to CamillaDSP through this route since it fails at the first step.
So I now have another potential problem to solve - do I try the CCA TOSLINK connection into another audio device ... or do I try again on the loopback approach, maybe with a different distro/kernel ...
I know that TOSLINK can be unreliable at higher sample rates, I can do rates up to 96 kHz on the Ultralite but anything higher does not work. If you have another TOSLINK cable you might give that a try and see if it does any better.
For the loopback, can you describe a bit more about how your player is configured / implemented?
Michael
For the loopback, can you describe a bit more about how your player is configured / implemented?
Michael
Thanks for sticking with me Mike. Yes, I know the UltraLite maxes out at 96kHz for TOSLINK. I only have the one cable that goes from a 3.5mm jack but I'll try plugging the other end into another DAC and check that I get something out there.
So I'm using an Allo USBridge Signature which is based on the CM3+ version of the Pi. I'm beginning to wonder if that's part of the problem.
I downloaded the Ubuntu Server 21.04 and updated/upgraded everything. I had an issue getting the system to enable the ethernet adapter automatically at boot, but @chili555 helped me on the ubuntu forums to get that sorted.
I installed RoonBridge manually by following the instructions at https://help.roonlabs.com/portal/en/kb/articles/linux-install for Roon Bridge armv8:
Code:
$ curl -O [url]http://download.roonlabs.com/builds/roonbridge-installer-linuxarmv8.sh[/url]
$ chmod +x roonbridge-installer-linuxarmv8.sh
$ sudo ./roonbridge-installer-linuxarmv8.shI can't see anything in the RoonBridge logs to indicate that anything's gone awry with that installation, but maybe I wouldn't.
Installing CamillaDSP seemed to go straightforwardly. I downloaded camilladsp-linux-amd64.tar.gz and then also installed pkg-config, libasound2-dev, libpulse-dev, openssl and libssl-dev.
The UltraLite is connected to the AlloUSBridge Signature by USB.
Does that give you the information you're after?
Cheers
John
I do wonder about the CM3+ Pi. I was unable to use the Ultralite with a RPi 3B+ but it works fine with a RPi 4.
Does the Ultralite work if you play directly to that instead of the loopback? That would at least eliminate CamillaDSP as a variable.
I assume that you actually used the aarch64 version of CamillaDSP and not the amd64 version? I built mine using Cargo but I assume the aarch64 pre-built binary would work fine as well.
Michael
Does the Ultralite work if you play directly to that instead of the loopback? That would at least eliminate CamillaDSP as a variable.
I assume that you actually used the aarch64 version of CamillaDSP and not the amd64 version? I built mine using Cargo but I assume the aarch64 pre-built binary would work fine as well.
Michael
The new gui is ready!
Get it from here: Release v0.8.0 * HEnquist/camillagui-backend * GitHub
This works with CamillaDSP v0.6.x, and requires pycamilladsp and pycamilladsp-plot to both be updated to v0.6.0.
Get it from here: Release v0.8.0 * HEnquist/camillagui-backend * GitHub
This works with CamillaDSP v0.6.x, and requires pycamilladsp and pycamilladsp-plot to both be updated to v0.6.0.
Success! So I installed CamillaDSP on a new RPi4 running Ubuntu 21.04 (GNU/Linux 5.11.0-1016-raspi aarch64), plugged in my UltraLite-mk5, and set up the virtual loopback soundcard with sudo modprobe snd-aloop. Now I'm able to stream from Roon to either of the two loopback devices is sees, and by choosing the right device in device: "hw:CARD=Loopback,DEV=<0 or 1>", the sound emerges from my UltraLite. Hurrah! I'm now looking forward to getting on with the interesting stuff, like convolution and bass management for Roon and other sources.
CamillaDSP now exits immediately in response to <Control-C>. From here it looks like the issues I was grappling with before relate to some incompatibility with CM3+.
Thanks for all the help.
Hi Henrik,
I got some time in the last few days to continue work on my crossover software port that will use camilla dsp.
One question: I have a five band parametric eq block in there which I would like to keep because it's so versatile.
I can either implement it internally as a chain fo low- and high shelf and 3 parametric eqs - then there's the question if you have optimizations in place that simply passes along data unmodified if gain of a block is 0dB?
Or would you care to implement a 5band-peq with shelves for me - that thing would have 15 parameters then, 5x f, 5x gain, 5x Q...
I got some time in the last few days to continue work on my crossover software port that will use camilla dsp.
One question: I have a five band parametric eq block in there which I would like to keep because it's so versatile.
I can either implement it internally as a chain fo low- and high shelf and 3 parametric eqs - then there's the question if you have optimizations in place that simply passes along data unmodified if gain of a block is 0dB?
Or would you care to implement a 5band-peq with shelves for me - that thing would have 15 parameters then, 5x f, 5x gain, 5x Q...
There are no optimizations for when gain is 0dB. I didn't include that mostly because the the cost of having one with 0 dB gain is very small. I have also assumed that most filters in the pipeline are added to do something, so that 0dB filters won't be a common thing.
I can see that adding and keeping track of 5 individual filters in the config would be a challenge. I can add a PEQ combo filter to make it a single unit.
That goes in here: camilladsp/biquadcombo.rs at master * HEnquist/camilladsp * GitHub
It would be easy to make it skip creating the filters that have zero gain.
OK, that would be sweet if you could create that combo for me. No rush needed, it will probably be a few weeks before a public version is to be released.
And I think you should skip the optimization because
a) you say it's cheap, i believe you
b) the gain might be set to anything other than 0dB by accessing the webservice after starting camilladsp anyways. then you would have to modify the chain after having started it. probably not a good idea...
And I think you should skip the optimization because
a) you say it's cheap, i believe you
b) the gain might be set to anything other than 0dB by accessing the webservice after starting camilladsp anyways. then you would have to modify the chain after having started it. probably not a good idea...
Last edited:
The chain for a combos is always recreated on parameter update, the optimization would simply be that it would skip creating the filters that have zero gain. So no problem to update via websocket.
Updated!Am I ready to just run this or do I need an install script?
//
GitHub - HEnquist/camilladsp-setupscripts: Scripts for setting up CamillaDSP on different platforms.
It went a little faster than I thought it would. (I had forgotten about that I had already made the simplifications)
I should really make scripts for linux and windows too..