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

Jump to Latest
#3,621
With both settings enabled which method is actualy used on Linux?
Backend 1.0.0 on RPi-OS (Debian)

Only enabling 'update_config_symlink' button on the GUI won't let us select an active config.
Code: 
pi@RPi:~/camilladsp/gui/config $ nano camillagui.yml
update_config_symlink: true
update_config_txt: false
sudo systemctl restart camillagui
1666116752638.png

To enable the button 'update_config_txt' need to be active.
Code: 
pi@RPi:~/camilladsp/gui/config $ nano camillagui.yml
update_config_symlink: true
update_config_txt: true
sudo systemctl restart camillagui


When I'm on this topic. Text below had me check file permission on the config directory. Reason being the wording: "not able to" rather than deactivated. With my interpretation implying there is something wrong with the setup. With manual saying symlink are preferd on linux and I already had it activated it I had me spinning the wheel for some time 😉
1666117673908.png


Great stuff @HenrikEnquist. Still blow my mind by how much can be done with clever & efficient code on the RPi.
 
#3,622
DEQ+TheEnd said:
Would it be possible on the main directory have a page named something like 'currentstableversion.md'. Only contaning the revision number where all the bits and pieces fit?
Click to expand...
I will add something like that to the setup scripts repo. I want to have a single source for this, and use it in all scripts. At the moment there is only a macOS script that has the versions hardcoded, but more are planned.

DEQ+TheEnd said:
When this is written most current files not to be considered compatible?
Bash: 
wget https://github.com/HEnquist/camilladsp/releases/download/v1.0.2/camilladsp-linux-aarch64.tar.gz -P ~/camilladsp/
pip3 install git+https://github.com/HEnquist/pycamilladsp.git@v1.0.0
pip3 install git+https://github.com/HEnquist/pycamilladsp-plot.git@v1.0.2
wget https://github.com/HEnquist/camillagui-backend/releases/download/v1.0.0/camillagui.zip -P ~/camilladsp/
Click to expand...
Yes those are the latest versions. There may be a few updates (the fewer the better) of the patch level, like 1.0.2 --> 1.0.3 for fixing bugs without adding any new functionality. Then the next full set will when everything is updated to 1.1.x, but that is likely several months away.
 
  • Like
Reactions: DEQ+TheEnd
#3,623
DEQ+TheEnd said:
When I'm on this topic. Text below had me check file permission on the config directory. Reason being the wording: "not able to" rather than deactivated. With my interpretation implying there is something wrong with the setup. With manual saying symlink are preferd on linux and I already had it activated it I had me spinning the wheel for some time 😉
View attachment 1100935
Click to expand...
If both are enabled, it will update both symlink and text file. When reading it will go for the symlink.
The message means that there is something wrong with the symlink setting. Is there perhaps already a regular file with the same name? The backend should print a warning with more info when it starts.
 
  • Like
Reactions: DEQ+TheEnd
#3,624
HenrikEnquist said:
The message means that there is something wrong with the symlink setting. Is there perhaps already a regular file with the same name?
Click to expand...
Thank you! Yes I can confirm this where true at some point 😉 Had it sortet already but didn't check the hover text after.
When I figured out the logic my script now create a symlink that CDSP can write over. And camilladsp.service now use this symlink at statup.

btw: I like having the syslog in the 'Show log file'. Works great on RPi-OS and I can see if alsa or Squeezelite complain.
Code: 
nano ~/camilladsp/gui/config/camillagui.yml
log_file: "/var/log/syslog"

One thing I've experianced. Bit depth for the playback device are not altered as long as CDSP has the card loaded. i.e. user can be fooled to belive the output device support higher bit depth course after GUI or local file edits output device still plays. It seams bit depth (sample format) change only take place when the card is opened. i.e. when CDSP start from a complete stop, not a quick restart.
Luckely one can still change the configuration back from the GUI, but stopping the service consol window is needed. Not really a problem, but something to be aware of when you experiance your configuration stop working after reboot.
 
#3,625
DEQ+TheEnd said:
One thing I've experianced. Bit depth for the playback device are not altered as long as CDSP has the card loaded. i.e. user can be fooled to belive the output device support higher bit depth course after GUI or local file edits output device still plays. It seams bit depth (sample format) change only take place when the card is opened. i.e. when CDSP start from a complete stop, not a quick restart.
Luckely one can still change the configuration back from the GUI, but stopping the service consol window is needed. Not really a problem, but something to be aware of when you experiance your configuration stop working after reboot.
Click to expand...
I don't really get what the problem is. You are supposed to be able to change sample format with a config reload. If you can't there is a new bug.
Can you write down the steps needed to see the issue you describe?
 
#3,626
HenrikEnquist said:
Can you write down the steps needed to see the issue you describe?
Click to expand...
Sure. But its not a problem if user know why it happens and how to handle it. I figured out while writing this the GUI will still start and let user edit and save the parameter preventing CDSP from starting. Those in fear of console windows can then get it running with a reboot.

Here I use RPi Headphone output to demonstrate
Code: 
devices:
  adjust_period: 10
  capture:
    channels: 2
    device: hw:Loopback,0,0
    format: S32LE
    type: Alsa
  capture_samplerate: 0
  chunksize: 4096
  enable_rate_adjust: false
  enable_resampling: false
  playback:
    channels: 2
    device: hw:Headphones,0,0
    format: S16LE
    type: Alsa
  queuelimit: 4
  rate_measure_interval: 1
  resampler_type: Synchronous
  samplerate: 44100
  silence_threshold: -60
  silence_timeout: 2.8
  stop_on_rate_change: false
  target_level: 0
filters:
  Vol:
    parameters:
      ramp_time: 200
    type: Volume
mixers: {}
pipeline:
- channel: 0
  names:
  - Vol
  type: Filter
- channel: 1
  names:
  - Vol
  type: Filter

From GUI enable Apply automatically
From GUI make this yml config the Active configuration.
Now alter bit depth (format) for playback device to S32LE bit. On my system it continue to play after a short init.
Click Save to file

Next reboot CamillaDSP wont start with this error:
Oct 19 09:16:46 RPi camilladsp[526]: 2022-10-19 07:16:46.956392 INFO [src/bin.rs:7 11] CamillaDSP version 1.0.2
Oct 19 09:16:46 RPi camilladsp[526]: 2022-10-19 07:16:46.956579 INFO [src/bin.rs:7 12] Running on linux, aarch64
Oct 19 09:16:46 RPi camilladsp[526]: 2022-10-19 07:16:46.964777 #033[38;5;196mERRO R#033[0m [src/bin.rs:344] Playback error: ALSA function 'snd_pcm_hw_params_set_for mat' failed with error 'EINVAL: Invalid argument'
Click to expand...
 
#3,627
DEQ+TheEnd said:
Sure. But its not a problem if user know why it happens and how to handle it. I figured out while writing this the GUI will still start and let user edit and save the parameter preventing CDSP from starting. Those in fear of console windows can then get it running with a reboot.

Here I use RPi Headphone output to demonstrate
Code: 
devices:
  adjust_period: 10
  capture:
    channels: 2
    device: hw:Loopback,0,0
    format: S32LE
    type: Alsa
  capture_samplerate: 0
  chunksize: 4096
  enable_rate_adjust: false
  enable_resampling: false
  playback:
    channels: 2
    device: hw:Headphones,0,0
    format: S16LE
    type: Alsa
  queuelimit: 4
  rate_measure_interval: 1
  resampler_type: Synchronous
  samplerate: 44100
  silence_threshold: -60
  silence_timeout: 2.8
  stop_on_rate_change: false
  target_level: 0
filters:
  Vol:
    parameters:
      ramp_time: 200
    type: Volume
mixers: {}
pipeline:
- channel: 0
  names:
  - Vol
  type: Filter
- channel: 1
  names:
  - Vol
  type: Filter

From GUI enable Apply automatically
From GUI make this yml config the Active configuration.
Now alter bit depth (format) for playback device to S32LE bit. On my system it continue to play after a short init.
Click Save to file

Next reboot CamillaDSP wont start with this error:
Click to expand...

Does the headphone output even support S32LE? Here is what I see for my raspberry pi 4 and it does not look like it.

I think it is saving the updated configuration but not applying it to the DSP (I imagine if you fetch from DSP after changing to S32LE it will show S16LE). However when you restart CamillaDSP it tries to apply the incompatible config and fails.

Code: 
michael6@raspberrypi6:~$ aplay -v -D hw:Headphones /dev/zero --dump-hw-params
Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:Headphones":
--------------------
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  U8 S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: [8 16]
FRAME_BITS: [8 128]
CHANNELS: [1 8]
RATE: [8000 192000]
PERIOD_TIME: [10000 16384000]
PERIOD_SIZE: [80 131072]
PERIOD_BYTES: [1024 524288]
PERIODS: [1 128]
BUFFER_TIME: (416 16384000]
BUFFER_SIZE: [80 131072]
BUFFER_BYTES: [1024 131072]
TICK_TIME: ALL
--------------------

Michael
 
Last edited:
#3,629
Ah, now I understand what you were saying.

I've never noticed this as I always hit the "Apply and save" button which will fail if you try to apply an incompatible configuration. The same thing will happen if you have both the "Apply automatically" AND "Save automatically" boxes checked.

On the other hand if you have an incorrect config and hit "Apply to DSP" or have only "Apply automatically" checked it seems to revert to your previous config. I guess it would be nice in these cases if CamillaDSP gave an indication that it attempted to apply the config but it was unsuccessful and reverted to the previous config as a result.

Michael
 
#3,631
Finished my crude script to install ready playing Squeezelite with CamillaDSP on RPi-OS Lite 64 bit.
https://github.com/StillNotWorking/LMS-helper-script/tree/main/camilladsp
direct link: https://github.com/StillNotWorking/LMS-helper-script/blob/main/camilladsp/installcamilladsp.sh

If you don't trust running it just follow it manually as It simly list more than 40 steps needed to have your RPi up playing stereo music with a few optional EQ filters. Rather than have script do text manipulation it pull ready made configuration files from my repository.
 
#3,632
Looks good! A few thoughts:
It's usually preferred to install python libraries from the system repos with apt rather than with pip. So I would recommend to install aiohttp, jsonschema, numpy ad matplotlib with apt. They should all be available.
There is a big overhead when you run apt to install single packages. Why not install them all with a single apt command at the start? That should save some time and make the script shorter.
 
  • Like
Reactions: DEQ+TheEnd
#3,634
I've noticed some odd behavior with the Quick Config Switch in the GUI.

The first time I try to change a configuration it does not take effect. From then on every time I switch to a new configuration it will change to the configuration that I tried to change to previously.

A work around is to double click the configuration I want to change to but this is annoying.

Has anyone else experienced this?

Michael
 
#3,636
mdsimon2 said:
I've noticed some odd behavior with the Quick Config Switch in the GUI.
Click to expand...
Sounds like a potential bug, I'll take a look. I modified the code behind that quite a bit before the release.

TNT said:
Henrik, please explain which frequencies the lines represent. It looks logarithmic but I cant figure it out...

View attachment 1101883
So its: 10 Hz, x Hz, y Hz, z Hz and 100 Hz - solve x, y, and z 🙂

//
Click to expand...
The lines are made automatically by the plotting library. It seems that generating good tick marks for every possible zoom level is really tricky. I have tried different ways but none worked better than the default. So I went back to using the default, but then I look at what it came up with and hide some labels (because there isn't space for displaying all of them nicely).
I think the ones without labels between 10 and 100 are 25, 50 and 75. But I'll have to check to be certain.
 
#3,637
Writing them out I understand will be messy. Hoovering->display would be nice... trying... 🙂

Hoovering gave: 30, 60 and 80 🙂

If one hoover at an intersection between a scale and a trace, the frequency is revealed.

Thats usable.

//
 
#3,638
Which value is actually applied to the DSP engine when input is factor of .5? Do we get a bit shift or is it roundet going in?

Bash: 
pi@HiFiBerry:~/camilladsp $ python set_volume.py 1234 -6.0205999132796239042747778944898
Current volume: -18.0 dB
Changing volume to: -6.020599913279624 dB
pi@HiFiBerry:~/camilladsp $ python3 set_volume.py 1234 -6.0205999132796239042747778944898
Current volume: -6.0206 dB
Changing volume to: -6.020599913279624 dB

Mostly of academic interest I'm curious if I can hear a difference using prinsipple of Lossless Digital Volume control used in Lumin streamers. With CDSP I'm thinking integer upsampling and no filters other than volume would be a good test platform. Given the already high precision we can notch number off to be roundet for 24b without any consived volume change. https://www.processing-leedh.com/copie-de-presentation

In the spirit of above LDV, when sample rate are selected above original input volume drop as expected. Is this done by a number that need to be rounded to fit 24 bit?
 
#3,640
IIUC LDV picks volume attenuation coeffs which can be implemented in integer DSP with minimized bitshift division (to avoid crossing the 24th bit boundary for 16bit input) and subsequent multiplication. That avoids truncation/rounding for 16bit samples when the volume operations are performed in 24bit resolution for attenuation down to 16 -> 24 extra resolution of 8bits (=-48dB). I do not believe a change at the 24th bit can be audible, no proper listening tests have been reported, that linked paper studies only the precision of the volume calculations and carefully steps around the audibility question.

CDSP does not do DSP/volume calculations in integer, but in float64 (or float32, if configured so at the build time).
 
  • Like
Reactions: mdsimon2
You must log in or register to reply here.
Top Bottom