CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc

Jump to Latest
#1,907
I am stuck. When I install rust using the script on a clean Debian, I can call cargo, but not sudo cargo. When installing via apt-get, I can do it, but then I have the old version of rust. I have the cargo directory in $PATH and also the $HOME/.cargo/env line in .bashrc.

What am I missing? Without sudo, it ends with 'access denied'.
 
Last edited:
#1,908
rustup installs rust and cargo under your user account, which means it's not available for root. Do you need sudo for installing like this? GitHub - HEnquist/camilladsp-config: Help for setting up CamillaDSP, example config files etc
That only works when you use the system package for rust.

To instead use the one from rustup, just do "cargo build" without sudo and with the options you want. Then manually copy the binary with:
Code: 
 sudo cp target/release/camilladsp /usr/local/bin/
 
#1,909
Quick update on my version of the project - The USBStreamer apparently doesn't behave quite right on the recording side. I suggest you don't try to copy this implementation unless you're willing to help me debug Linux and the USBStreamer...

As a note, this has nothing to do with CamillaDSP, as it's reproducible with just using "arecord" from my (known good) media player output with something like the following code:

Code: 
sudo arecord -f S32_LE -r 44100 -c 2 -D "hw:CARD=USBStreamer,DEV=0" test.wav

Here's a picture of the, audible, problem:

uGhBqK6.png

Top is the recorded waveform, bottom is the original. It just zero fills ~32 samples occasionally, and then picks up where it left off, for some reason...

This happens every 10-15 seconds or so - the emulation of somewhat clean vinyl (quiet pops/cracks) is pretty spot on. I have debugged everything in my audio chain and it's specifically the capture side of the USBStreamer with the Raspi4 (Ubuntu Server). "aplay" playback with a file works perfectly with the USBStreamer, as does the whole digital chain from source-to-speakers (including the hat), without the USBStreamer in circuit capturing.

I've tried several things to stop it, mostly Alsa buffer things, but I have no idea why it happens or what to try next, as I'm not a Linux/XMOS guru... The 32 sample length is curious...


raptorlightning said:
Well it took a while, but I finally have a solution:

...

The miniDSP USBStreamer I'm using behaves properly as a transmitter. "Properly" is defined as not doing anything to the sample rate until software control requests it. That is done through ALSA and it works quite well. The filter header is:
Click to expand...
 
#1,912
pelanj said:
I finally managed to compile. So I copy only camilladsp, not the whole content of the folder? Thanks for the advice!
Click to expand...
Just that one files yes!


raptorlightning said:
Top is the recorded waveform, bottom is the original. It just zero fills ~32 samples occasionally, and then picks up where it left off, for some reason...

This happens every 10-15 seconds or so - the emulation of somewhat clean vinyl (quiet pops/cracks) is pretty spot on.
Click to expand...
This could maybe be a two-different-clocks-problem. Are you feeding data to the USBStreamer on the spdif input? If yes, and it's not using the clock recovered from the spdif, then you could get something like this. 32 samples every 10 seconds means 32/441000 off, which is about 0.007%. The gaps would then mean that the source clock runs 0.007% slower than the USBStreamer clock.
Can you select clock source on the USBStreamer? It looks like you can on Windows. On linux it might be exposed as a mixer control.
 
#1,913
USB-audio driver in linux had problems with duplex operation and implicit async feedback. Recently that part of the driver was completely overhauled, to satisfy the standard... and the devs are still solving unexpected issues with some devices slightly deviating from the standard since then.
 
#1,914
jrubins said:
No filter where I put in a1, a2, b0, b1, b2 looks anything like I expect it to. That could be because the visualization is not working as intended
Click to expand...
I looked into this now, and there was a typo in the function that calculates the frequency response. It ignored the given value for a2, and used the a1 value for both a1 and a2. No wonder the results were nonsense!
I fixed it now, and this will be included in the next gui release.
If you want, you can fix it by patching the "filters.py" file of pycamilladsp-plot.
On line 299, it should look like this:
Code: 
class Biquad(object): 
    def __init__(self, conf, fs): 
        ftype = conf["type"] 
        if ftype == "Free": 
            a0 = 1.0 
            a1 = conf["a1"] 
            a2 = conf["a2"]
and not a2 = conf["a1"]...
 
#1,915
phofman said:
raptorlightning: Please post output of lsusb -v when USBStreamer is connected (as an attached txt file) and your kernel version (uname -a)
Click to expand...

lsusb output file is attached and the output of uname -a is:

Code: 
Linux pidsp 5.4.0-1034-raspi #37-Ubuntu SMP PREEMPT Mon Apr 12 23:14:49 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

HenrikEnquist said:
This could maybe be a two-different-clocks-problem. Are you feeding data to the USBStreamer on the spdif input? If yes, and it's not using the clock recovered from the spdif, then you could get something like this. 32 samples every 10 seconds means 32/441000 off, which is about 0.007%. The gaps would then mean that the source clock runs 0.007% slower than the USBStreamer clock.
Can you select clock source on the USBStreamer? It looks like you can on Windows. On linux it might be exposed as a mixer control.
Click to expand...

I didn't even think that it might not be using the SPDIF recovered clock... I'm not sure how I would go about changing the clock source or checking this with terminal commands.
 

Attachments

Last edited:
#1,916
Here are the outputs of the following commands as well:

Code: 
cat /proc/asound/card1/usbmixer
cat /proc/asound/card1/stream0

It's interesting that the usbmixer file contains an instance of the "miniDSP Clock Selector Clock Source" control. I have no idea how to use this information though...

Edit: And there's this thread on alsa-devel from back in 2013 that seems to be a similar issue: [alsa-devel] M-Audio Delta 1010LT: S/PDIF clock source not working
 

Attachments

#1,917
Well it seems I have fixed it using alsamixer to select the "miniDSP TOSLINK Clock Source" instead of the "miniDSP Internal Clock Source"! Thank you Henrik for suggesting this might be the issue! And I really appreciate your willingness to help with my Linux ignorance phofman.

Unfortunately, this setting has broken my sample rate switching script. I probably need to switch it back to the internal clock, restart camillaDSP, then switch it to the toslink clock source. I will try this tomorrow (if I can figure out the alsamixer command line) and, if this doesn't break anything else 🙄, all will be perfect!

Here's the journalctl output when the script tries to switch from 44.1kHZ (playing fine) to 48kHz (errors out), then it picks up fine going back to 44.1kHz:

Code: 
Apr 21 22:40:21 pidsp python3[2330]: Frequency Changed to: 44.1kHz
Apr 21 22:40:21 pidsp python3[2331]: Apr 21 22:40:21.721 INFO Starting playback from Prepared state, module: camillalib::alsadevice
Apr 21 22:40:37 pidsp python3[2336]: Frequency Changed to: 48kHz
Apr 21 22:40:37 pidsp python3[2337]: Apr 21 22:40:37.245 ERRO Playback error: ALSA function 'snd_pcm_hw_params' failed with error 'ENXIO: No such device or address', module: camilladsp
Apr 21 22:40:37 pidsp python3[2337]: thread 'Apr 21 22:40:37.246<unnamed>' panicked at ' called `Result::unwrap()` on an `Err` value: "SendError(..)"ERRO',  src/processing.rsMessage channel error: receiving on a closed channel:, 40module::37
Apr 21 22:40:37 pidsp python3[2337]: camillalib::processingnote: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Apr 21 22:40:51 pidsp python3[2342]: Frequency Changed to: 44.1kHz
Apr 21 22:40:51 pidsp python3[2343]: Apr 21 22:40:51.188 INFO Starting playback from Prepared state, module: camillalib::alsadevice
 
You must log in or register to reply here.
Top Bottom