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.So In my case as per above: will changing enable_rate_adapt = Yes imply that any re-sampling will start to happen? (I think no...)
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...two on linux
//
Henrik even quoted the relevant part of his documentation yesterday in https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-8010502 🙂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...
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.I was thinking picorePlayer. Fs switching would be nice.
- Home
- Source & Line
- PC Based
- CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc