I've been experimenting with CamillaDSP (1.0.1) on a Pi4 using a MOTU M4 (with latest firmware) for USB output. I'm using 64-bit Raspberry Pi OS and compiled the latest kernel (5.19) for it, but have otherwise mostly followed the tutorial here. Thanks
@mdsimon2 for your effort in putting this together.
I primarily intend to use Squeezelite to stream to the Pi4 from my LMS server, but would also like to use the analogue inputs on the MOTU for a record player and eventually like to add other inputs such as a S/PDIF interface for a CD player. My aim is to use the system as a streamer with DSP for room EQ and to do the crossover between stereo speakers and a pair of subwoofers while achieving the highest audio quality possible. I haven't implemented any EQ filters yet.
As I've been going I've run into a number of questions and issues about CamillaDSP, the MOTU M4, and DSP in general that I would like to get to the bottom of, and wonder if anyone here knows the answers or knows where to find them. Any information or advice would be much appreciated.
- When I try to use "hw:M4" (or any equivalent) for bit perfect output to the M4 without ALSA resampling it I get no audio output and get this error in the Squeezelite log:
[18:22:12.718934] alsa_open:465 channel count not available: Invalid argument
. This appears to be the case for any ALSA audio tool such as aplay or Squeezelite itself. I have to use "plughw:M4", which uses poor sounding resampling via ALSA itself. The exception to this is when CamillaDSP is configured to use hw:M4 as the playback device. Obviously this is what I want to do anyway, but would like to be able to test and compare audio output directly from audio player to M4 without using CamillaDSP. The direct output works in CamillaDSP regardless of whether I enable resampling or not.
- Is this because CamillaDSP is mixing the source stereo channels and outputting to all four channels of the M4, or because it's increasing the bit depth from 16 or 24 bits to 32?
- Is this expected behaviour for the M4 when using ALSA? It works fine when using WASAPI Windows and Coreaudio in OSX. I haven't tried Jack or Pulse etc. This was the case for the stock kernel and also when I tested Ubuntu 22.04 on it. It's the main reason why I tried updating the kernel to 5.19.
- I am quite inexperienced with EQ in general, but as I understand it you need a higher bit depth when using DSP for EQ and not necessarily a higher bit rate. If that's the case then is it ideal, audio quality wise, to maintain the original sample rate without resampling when using DSP, and only increase the bit rate then let the DAC do its own internal upsampling?
- Will CamillaDSP 1.1 enable the capture of multiple sample rates without requiring resampling to a consistent sampling rate prior to capture? From reading this thread it seems that gadget mode will enable this when using an external audio interface but I'm not sure whether this will be the case for the ALSA loopback interface with Squeezelite etc.
- Will CamillaDSP 1.1 enable the automatic resampling to integer multiples of the source sample rate? Eg 44.1KHz to 88.2KHz or 176.4KHz.
- Does resampling to non-integer multiples like 44.1KHz to 96KHz or 192KHz increase the aliasing artefacts and thus noise from resampling?
- The tutorial uses 96KHz sample rate for resampling. Would 192KHz be a better option given the processing power of the Pi4? This is related to the question above.
- Does the M4 do any internal upsampling of its own?
- The MOTU M4 config file in this tutorial is configured to use asynchronous resampling, but I've read that synchronous is better if possible. Should I use synchronous with the M4?
- The logfile says:
2022-08-17 06:45:13.765307 WARN [src/alsadevice.rs:592] Async resampler not needed since capture device supports rate adjust. Switch to Sync type to save CPU time.
- When I've tested synchronous resampling the CPU consumption is about 5% lower than BalancedAsync.
- Would it be better to do any necessary resampling in Squeezelite (which uses Sox) prior to output to the loopback interface and leave CamillaDSP resampling off?
- The CamillaDSP logfile says:
2022-08-17 06:45:13.765231 INFO [src/alsadevice.rs:588] Capture device supports rate adjust
. Does this mean that I should turn it off rate adjust in CamillaDSP and let the M4 handle it?
- I'm getting some annoying popping/clicking when playing audio. This appears to be regardless of any combination of prior resampling or not with Squeezelite, outputting directly to the loopback interface using aplay, turning rate adjust on or off, configuring synchronous/asynchronous/no resampling in CamillaDSP, and increasing chunk size in CamillaDSP. I've previously seen this on the Topping E50 when using an inadequate power supply. Could this be due to inadequate power output from the Pi4 to the M4? The Pi4 is supposed to output 1.2A max on the USB ports and the M4 is supposed to only require 500mA. I'm using the official Raspberry Pi USB-C power supply that outputs 3.0A, which should be plenty. Otherwise, would an OTG adapter help?
1. Can you share your configuration file? I imagine you do not have 4 channels specified under "playback" in your CamillaDSP configuration. Or you are not using the correct S32LE format.
2. I mention my rational for running at 96 kHz in the tutorial:
These configuration files are designed to run at 96 kHz. I like 96 kHz as a DSP sample rate as it avoids high frequency warping and it is not too demanding from a resource standpoint.
This post ->
https://www.audiosciencereview.com/forum/index.php?threads/minidsp-flex.28660/post-1037905, shows a comparison of high frequency warping for 48 kHz and 96 kHz sample rates. Not a huge difference but given the RPi4 has plenty of power to run at 96 kHz and avoid warping in the audible frequency range, why not? I haven't tested it extensively but all of the CamillaDSP resampling options seem very high quality and will be nowhere close to limiting from an audibility standpoint.
3. Yes, gadget mode using gaudio_ctl will automatically switch rates. There is a way to switch rates with a loopback as well ->
https://github.com/scripple/alsa_cdsp. I do not use either of these approaches because they make it difficult to modify / change configurations in the GUI. I do not believe there are any concrete plans to change rate changing behavior within CamillaDSP itself but I could be wrong.
4. No, Henrik has indicated the resampler needs to restart if there are large changes in sample rate. See this post and subsequent discussion for more info ->
https://www.audiosciencereview.com/...s/rpi4-camilladsp-tutorial.29656/post-1195832.
5. I haven't seen anything noticeable, it doesn't affect 1 kHz or multitone test results at the DAC output. I could do some more testing to evaluate but everything I've seen so far indicates that it would be wasted effort to do so. You can read more about the technical aspects of asynchronous sample rate conversion here ->
https://www.diyaudio.com/community/threads/asynchronous-sample-rate-conversion.28814/v.
6. High frequency warping is only an issue if you are applying DSP near the Nyquist frequency. 96 kHz solves this for any EQ in the audible range (20-20K) so I see no advantage to using 192 kHz as it is a waste of resources.
7. I do not know anything about the specific implementation of the M4 but in general ES90XX DACs are oversampling DACs.
8. Yes, for loopback configurations or configurations where your capture and playback device share a clock you can use synchronous. I've been meaning to update the configurations in the tutorial to reflect. Asynchronous is only required if you have your capture and playback devices have two different clocks.
9. I don't think it will be audibly any different. The reason I resample in squeezelite to 44.1 kHz is so that I can switch between shairport-sync (which always runs at 44.1 kHz) and squeezelite without changing configurations. If you only use squeezelite I would consider implementing rate switching in CamillaDSP or just resample in squeezelite.
10. By capture device it means ALSA loopback, not the M4. You need rate adjust otherwise you will have buffer over / under runs. The only time rate adjust is not needed is if your capture and playback devices share the same clock.
11. I have not experienced any such issues on my M4 powered directly by my RPi4. Can you increase verbosity of your log (see tutorial) and share it for times of when these drop outs occur?
Michael