No, but only in this very particular case of the mere 3 devices which support fine-tuning the clock (two on linux, one on MacOS). If you used a different virtual loopback device (e.g. VBA on windows), CDSP would have to use resampling for the two clock alignment (IF further enabled by Async resampler in the config). No rate adjust will by principle always sooner or later result in audible buffer issues for the non-synchronous input and output devices.
How should one think about adjust_period and target_level? I could not set the values proposed above...
//
Which are these please... as I'm soon to build a Pi based player with USB out the the same XMOS board as I now used with Mac Mini...
//
Henrik even quoted the relevant part of his documentation yesterday in https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-8010502 🙂
OK, "Alsa Loopback and USB Audio gadget devices on Linux"... I'm so unfamiliar with these items they just passes by. But I see now - thanks!
So when I use a Pi to hook up an USB DAC it will be the Alsa Loopback case, right?
//
So when I use a Pi to hook up an USB DAC it will be the Alsa Loopback case, right?
//
These virtual interfaces require some control of CDSP if you want to use multiple samplerates. What is your player software for RPi?
I was thinking picorePlayer. Fs switching would be nice. But maybe there is a better recommendation? 🙂
//
//
Then this looks interesting https://github.com/JWahle/piCoreCDSP . It uses custom CDSP alsa plugin , no loopback necessary.
OK, that's the one have tinkered with a bit. I got it to play music 🙂 - both via the Pi built in HP output as well as the DIYINHK MC board.
But I can skip Fs switching and stay 44,1 if it has any advantage... is there?
//
But I can skip Fs switching and stay 44,1 if it has any advantage... is there?
//
Hi!
This is a quite long thread... 🙂
I have some issues with CamilaDSP in a PipeWire (on latest ElementaryOS) environment.
I tried to use it this way: Chromium -> PW Sink -> CamillaDSP -> PW SoundCard
This method is described in the CamillaDSP documentation.
Somehow, the output is dead quiet. The Camilla debug log shows, that the signal is arrived, but nothing comes out.
Do anyone use CamillaDSP this way or should I use it by connected to Alsa Loopback?
This is a quite long thread... 🙂
I have some issues with CamilaDSP in a PipeWire (on latest ElementaryOS) environment.
I tried to use it this way: Chromium -> PW Sink -> CamillaDSP -> PW SoundCard
This method is described in the CamillaDSP documentation.
Somehow, the output is dead quiet. The Camilla debug log shows, that the signal is arrived, but nothing comes out.
Do anyone use CamillaDSP this way or should I use it by connected to Alsa Loopback?
Hi
since RME Digiface USB is supported in kernal 6.12 i try to use it in camliiaDSP.
I have not tested, if i get sound, but get error messages:
- camillaDSP sample rate change detected, last rate was 60682.462252098274 Hz
And using more than 256 as buffer chunksize will also end in many error messages.
It seems, that the locking on the inputs stops working properly, because, the green LED for the input on the RME starts flashing.
I am not using loopback, i am using the SPDIF Inputs.
If i run Reaper seems to run smoothly.
I am using Ubuntu if this helps.
Thx and greetings
Christian
since RME Digiface USB is supported in kernal 6.12 i try to use it in camliiaDSP.
I have not tested, if i get sound, but get error messages:
- camillaDSP sample rate change detected, last rate was 60682.462252098274 Hz
And using more than 256 as buffer chunksize will also end in many error messages.
It seems, that the locking on the inputs stops working properly, because, the green LED for the input on the RME starts flashing.
I am not using loopback, i am using the SPDIF Inputs.
If i run Reaper seems to run smoothly.
I am using Ubuntu if this helps.
Thx and greetings
Christian
In Alsamixer i can configure the inputs as ADAT or SPDIF. Ist it maybe, that camillaDSP is using ADAT instead of SPDIF?
On ADAT there are 8 chanels muxed, what could explain the behavior.
If so: is there a chance to change that in the camillaDSP config?
Running Reaper:
Running camillaDSP:
On ADAT there are 8 chanels muxed, what could explain the behavior.
If so: is there a chance to change that in the camillaDSP config?
Running Reaper:
Running camillaDSP:
Yes, but it will take a while!
Here the link to the RME Forum:
https://forum.rme-audio.de/viewtopic.php?id=40531
Here the link to the RME Forum:
https://forum.rme-audio.de/viewtopic.php?id=40531
Does it work without "plughw:", with just "hw:" instead? The plug enables automatic conversions of sample format, sample rate and channels. You are maybe not be running the device at the sample rate you have selected, it accepts anything and applies whatever conversions needed to make the device happy. With plain "hw" there are no conversions.
Will try… don‘t remember… maybe I had selected 48kHz when istnwas playing on OSX and yesterday I had just 44.1.
As far as I know, RME Devices keep last settings, so it could be, that you are right.
THX!
As far as I know, RME Devices keep last settings, so it could be, that you are right.
THX!
@chriss0212 : You can always check parameters of the actual device stream at /proc/asound/your_card_name/pcmXp/subY/hw_params. If the reported params (samplerate, sample format, channels count) differ from CDSP playback params, than the plug plugin does the conversion automatically.
Hi Henrik,
Going back to "plughw" and its playing immidiatly.
Is there any disadvantage to use "plughw" as lomg as input sr is same as output sr?