Is this rate measurement used for the asynchronous resampler or is there a more accurate/sophisticated rate measurement used for that? It makes me wonder about the jitter/wander in the asychronous resampling rate.
That is true, unless you are recalculating samples, which is what the async resampling does. If the resampling deviates its ratio, and the output clock is stable, the converted signal will be distorted.
But the jitter frequency will equal to changes of the resampling ratio which would happen every 10 secs by default in CDSP (parameter adjust_period) => jitter frequency 0.1Hz max.
Nevertheless, IIUC that measured rate in the coreaudio plugin is not used for async resampling, but just for checking whether the incoming rate has changed - that's what Henrik explained.
The async resampling ratio is adjusted by monitoring buffer levels. This gives more stable values than the sample rate measurement. And the control loop is set up to be quite slow, in order to keep the applied adjustments small.
New version: v1.0.2
The pre-built binary of v1.0.1 for macOS has a small memory leak that was probably caused by a compiler bug (it was built with a pre-release compiler). Thanks to @TNT for finding and reporting!
I cleaned up the inefficient code that triggered the bug, and switched to the stable compiler for the binary builds.
New release v1.0.2 is here: https://github.com/HEnquist/camilladsp/releases/tag/v1.0.2
The pre-built binary of v1.0.1 for macOS has a small memory leak that was probably caused by a compiler bug (it was built with a pre-release compiler). Thanks to @TNT for finding and reporting!
I cleaned up the inefficient code that triggered the bug, and switched to the stable compiler for the binary builds.
New release v1.0.2 is here: https://github.com/HEnquist/camilladsp/releases/tag/v1.0.2
I'm looking for some more information/clarity around rate resampling and matching capture & playback devices.
I'm using https://github.com/hzeller/gmrender-resurrect as a UPnP render on the same rpi as camilla. I have an ALSA loopback device setup
gmrender => hw:0,1 - loopback - hw:0,0 <= camilladsp => USB DAC
in camilla when I use:
I'm wondering what your recommendation is for playing back mixed sampling rate content - I'm assuming camilla's AccurateSync might be better than whatever upstream is using?
Apologies for the wordy questions 🙂
I'm using https://github.com/hzeller/gmrender-resurrect as a UPnP render on the same rpi as camilla. I have an ALSA loopback device setup
gmrender => hw:0,1 - loopback - hw:0,0 <= camilladsp => USB DAC
in camilla when I use:
I can play back 44.1khz, 48khz and 96khz content just fine and camilla logs:
I notice that gmrender's CPU usage picks up a bit. In this case:
- who does the resampling? I assume it's gmediarender or is it actually the loopback device? if the latter, does that happen in kernel space?
- does the capture side of the ALSA loopback device set the sample rate on both sides or how does whatever is doing the resampling know which rate to use?
With this configuration I receive the following warning:
I can also play back content with different sampling rates with this configuration but I assume again something upstream is now resampling the content to match 44.1khz to match the loopback playback side (presumably dictated by the capture side from camilla).
I'm wondering what your recommendation is for playing back mixed sampling rate content - I'm assuming camilla's AccurateSync might be better than whatever upstream is using?
Apologies for the wordy questions 🙂
Are you sure it's hw:0,1 and not plughw:0,1? Did you specify that in the gstreamer output sink?
Almost no HW device is capable of resampling in HW, no drivers resample in kernel. IMO the increased CPU load for gmeadiarender suggests the resampling is done by gstreamer or alsa-lib (plug plugin).
The loopback device rate is decided by the process which opens the playback or capture first - the other side becomes slaved to that samplerate.
Since gmrender is kept running, it keeps its loopback side open, and camilladsp cannot change the samplerate of the loopback.
IMO either gstreamer output sink (not sure if it supporst auto resamplilng) or the plug plugin on the capture side.
For now no simple solution is available for using alsa loopback at various samplerates if the other side is not restarted at the new samplerate.
As of that async message - loopback supports rate adjust (adjusting its internal "clock"), so no async resampler is needed. But you still need a resampler (44.100 -> 192000) but it can be of the sync type (less CPU) + rate adjust to the loopback.
yes indeed, I use: gmediarender --gstout-audiosink=alsasink --gstout-audiodevice=hw:0,1
I haven't set up a /etc/asound.conf or ~/.asoundrc
I did find that BubbleUPnPServer will decode content not supported by the renderer but I don't think it's upsampling, looking a bit more into that
During digging in for ^ I've come across this incredible resource: http://src.infinitewave.ca/ - how about getting CamillaDSP submitted? 🙌
What is the gstreamer pipeline? IIUC it uses the standard playbin element https://github.com/hzeller/gmrender-resurrect/blob/master/src/output_gstreamer.c#L509 which is very complex, something like https://coaxion.net/blog/wp-content/uploads/2014/05/hls-av.png . My 2 cents it auto resamples to a rate allowed by the audio sink.
You could ask gst to chart the current pipeline https://embeddedartistry.com/blog/2018/02/22/generating-gstreamer-pipeline-graphs/ but it may require some minor touches to gmediarender to pass the params.
Not needed if you do not use any custom PCM devices.
I've looked thru a good bit of the thread and don't see an answer, so apologies if it has already been answered. I currently use a pair of dcx as a crossover for a 4-way stereo system. I'd like to upgrade to the motu mkV as the output using Camilla switching between digital sources and analog sources digitized by the motu. I have several spare Pi-3's.
Does the pi-3 have enough horsepower to handle a 4 way system?
I'll probably start with IIR filters like the dcx uses, although it would be nice to have the option for FIR. I've looked for quite awhile and I just have not seen availability of the pi-4(or for that matter any pi) for months/going on years now. if the pi-3 is insufficient, I'll just wait to get the motu until I can get a pi-4. Or by then, maybe something better for the same kind of money will be available.
Does the pi-3 have enough horsepower to handle a 4 way system?
I'll probably start with IIR filters like the dcx uses, although it would be nice to have the option for FIR. I've looked for quite awhile and I just have not seen availability of the pi-4(or for that matter any pi) for months/going on years now. if the pi-3 is insufficient, I'll just wait to get the motu until I can get a pi-4. Or by then, maybe something better for the same kind of money will be available.
I have used VB-cable on Windows in the past to do the same thing CamillaDSP aims to do (as far as I can tell) in my car audio system. I have experienced weird noise that seems to have been coming somewhere from the loopback itself. It was low in amplitude, but not low enough to not care at all, and easily reproducible on every Win 10 PC. Has any of you guys noticed this problem? Is it no longer an issue?
It should handle 4-way with iir very easily. With FIR it depends on what sample rate and filter length you want to use. A pi4 can do 8 channels with 262k taps per channel at 192k with 55% load. If we assume the pi3 is half as fast it can still do quite a lot 🙂
Not sure I get what you are asking. You can use an Alsa multi plugin to build a multichannel device from several stereo devices. I can't recommend it though, a proper multichannel device is a far better choice for several reasons.
As of the RPi3 - the older models featured only the internal dwc2 USB controller with reportedly unstable performance - people report random glitches in the isochronous stream.
x2
RPi3 and MOTU UL Mk5 do not play well together. With default settings I get no audio and very loud pops. Using dwc_otg instead of dwc2 works a bit better (actually have some audio output) but there are still audible pops.
I've had good luck buying RPi4s from digikey this year. Even though they do not show in stock they seem to get them in and will ship them when they have them, usually within 1-2 months of ordering.
Michael
In my experience, a HP thin client like e.g. HP T620 is much more powerful than a PI3 and can be had for the same or less money than a PI3. I use them for CNC control and multiple 3D printer control and also made CDSP work on a very old T510, which is still better hardware (according to benchmarks found on the web) than a PI3. I also did some experiments with small Dell thin clients, but these do not allow installation of a larger drive and the 8 GB storage is limiting. Today, I would go for a 4 core NUC, I have one ready, I just need to install everything and create the filters.