You can adjust the pre gain stage by changing R22 so the gain can be set at any value starting at 14 db.
Is the ALSA loopback able to handle input sample rate change yet? Is there any prospect of this working anytime soon or a workaround being devised?
Apologies if I've missed something. I've been running v1.0.0-alpha4 since last year but I still have Roon running at a fixed rate since Roon Bridge > ALSA > CDSP couldn't handle rate changes. And since Roon Bridge can only play to a pcm device type hw, @seashell's workaround doesn't work for me.
I'm going to have to update my RPi4's OS because the Ubuntu release (based on kernel 5.13) it currently uses recently went end of life. To make some other changes (to control spotifyd), I can either go now to Ubuntu 22.04 (based on 5.15) or hold fire until next month for 22.10 (based on 5.19). Or adopt another distribution if anyone advises that would kill both birds with one stone. Thanks.
I think the handling of sample rate change by CDSP is desirable when your source is not able to do high quality sample rate conversion.
There are three ways to integrate CDSP in your system. You can resample at source and run CDSP at a single sample rate, you can resample in CDSP and run CDSP processing at a single sample rate or you can run CDSP at the sample rate of your source. I think these will be equivalent in terms of signal quality when using the CDSP sample rate converter or other high quality sample rate converter. The CDSP sample rate converter is very good, at high quality setting it is essentially transparent, I dont see a reason to avoid using it other than limiting cpu usage. I would expect the roon sample rate converter to also be of very good quality.
My setup is similar to yours, roon with sampling rate conversion to roon bridge. I use FIR filters so I like this setup because I dont need to have a different set of FIR for each sample rate frequency and I dont need to worry about changing the CDSP config to match changing source sample rate.
Not yet no, and I'm not aware of any work on fixing it.
CamillaDSP will get support for a partial workaround in a future version. The loopback has controls that can be used to get notified when the devise is opened and closed. This can maybe be used here, but it won't be a full solution. It will only work with player apps that close the playback device, and then keep it closed for a bit before opening it again at a new rate. While it's closed, CamillaDSP can then close the capture side, and this releases the lock of the sample rate. After this, the player app can open the playback device again at the new rate, and then CamillaDSP can be restarted with the new rate.
If the app closes and then immediately tries to reopen, then CamillaDSP won't have had time to close the capture device yet, and setting the new rate will fail.
Thanks for the update. Exactly what Roon > RAAT > Roon Bridge does behind the scenes when there's a sample rate change I'm not aware of, but in the unlikely event that Roon Bridge closes and then reopens, the timing wouldn't be under user control. I may see if I can determine exactly what happens.
I noticed you updated to a new version of realfft 3.0.1. What is Released CI and how do I easily upgrade to newer version?
I came across a camilladsp-controller, pyalsa-class.py loopback volume control. Very interested in this since the volume control in GUI doesn't work with pipewire. (probably a config problem on my part).
Been looking into software volume controllers for pipewire.
There is a frontend out there for pipewire https://github.com/smasher164/pw-volume, and you can attach it to Swap or Waybar.
I came across a camilladsp-controller, pyalsa-class.py loopback volume control. Very interested in this since the volume control in GUI doesn't work with pipewire. (probably a config problem on my part).
Been looking into software volume controllers for pipewire.
There is a frontend out there for pipewire https://github.com/smasher164/pw-volume, and you can attach it to Swap or Waybar.
If alsa is being used, it's almost certain the output device is closed and reopened with the new samplerate. The issue which Henrik mentions is whether CDSP will manage to close its capture side of the loopback before the player tries to re-open its playback side with the new samplerate.
Nevertheless adding an option to the loopback to close side B if side A is opened with new incompatible params would be a nice alsa kernel project for a volunteer 🙂
The way I understood it, it's not about adding such an option. It's already supposed to be there, but has been broken for a long time.
https://mailman.alsa-project.org/pipermail/alsa-devel/2020-March/165454.html
He changes in Realfft 3.0.1 only benefit developers using the library, with better error messages and such. Functionally it's unchanged.
The camilladsp-controller is a work in progress. At this point it's mostly a prototype for testing ideas. It listens to control events but doesn't do anything (yet) when it receives them. You should be able to use it for controlling the camilladsp volume if you extend it.
Basically yes, but if I understand Jaroslav's response correctly the feature implementation must be redesigned to fit some internal changes.
@HenrikEnquist where do you hide the Python script converting REW EQ to .yml ?
I can't find it nowhere 🙂
Jesper.
I can't find it nowhere 🙂
Jesper.
TNT,
Here is a note I wrote for my own reference -
Translating IIR (biquad) filters exported by REW
https://github.com/HEnquist/camilladsp#translating-filters-exported-by-rew
REW can automatically generate a set of filters for correcting the response. These can then be exported as an .xml-file. This file can then be translated to CamillaDSP filters using the translate_rew_xml.py Python script. This will generate filters and pipeline steps that can be pasted into a CamillaDSP config file. This script currently supports only Peaking filters.
python3 translate_rew_xml.py YOURXMLOUTPUT.xml > YOURXMLOUTPUT.yml
The script is here: https://github.com/HEnquist/camilladsp/blob/master/translate_rew_xml.py
-
In CamillaDSP I made a directory called biquad and copied the translate_rew_xml.py
cd camilladsp
mkdir biquad
cd biquad
I copied the script by copy and paste into a translate_rew_xml.txt file and then renamed it to .py and copied it to camilladsp/biquad . A simpler way to get the script is from camilladsp/biquad
In REW EQ, set the Equaliser: rePhase (96 kHz), in Filter Tasks, "save the EQ filters to file" which will save the filters to an .xml file.
C:\REW Measurements\June Camilla 2022\Right\EQ\Bass\EQ Oct 12 M052R Bass 90db 20-500 TL89db 30-450Hz 1db tweaked.xml
I use WinSCP to transfer the file from my Win 11 PC to camilladsp/biquad and renamed it to R_Bass.xml and edited the speaker destination in line 3 to R_Bass.
python3 translate_rew_xml.py
camilla@camilla:~/camilladsp/biquad$ python3 translate_rew_xml.py R_Bass.xml > R_Bass.yml
Found speaker: R_Bass
Found filter: 1, enabled: true, f: 30.8, Q: 11.96, gain: -1.6
Found filter: 2, enabled: true, f: 36.0, Q: 7.06, gain: 3.8
Found filter: 3, enabled: true, f: 37.5, Q: 9.0, gain: 2.0
Found filter: 4, enabled: true, f: 40.65, Q: 7.52, gain: -5.0
Found filter: 5, enabled: true, f: 44.15, Q: 8.61, gain: -3.4
Found filter: 6, enabled: true, f: 69.8, Q: 7.01, gain: 3.1
Found filter: 7, enabled: true, f: 92.4, Q: 6.13, gain: -3.0
Found filter: 8, enabled: true, f: 111.0, Q: 8.0, gain: 1.6
Found filter: 9, enabled: true, f: 134.0, Q: 5.32, gain: -4.7
Found filter: 10, enabled: true, f: 164.5, Q: 3.21, gain: -7.7
Found filter: 11, enabled: true, f: 169.0, Q: 3.0, gain: 3.0
Found filter: 12, enabled: true, f: 208.0, Q: 10.0, gain: 8.6
Found filter: 13, enabled: true, f: 252.0, Q: 12.0, gain: -4.0
Found filter: 14, enabled: true, f: 279.0, Q: 30.0, gain: 5.8
Found filter: 15, enabled: true, f: 308.0, Q: 10.25, gain: -2.4
Found filter: 16, enabled: true, f: 400.0, Q: 15.0, gain: -4.2
Found filter: 17, enabled: true, f: 490.0, Q: 16.02, gain: -3.0
Translated config, copy-paste into CamillaDSP config file:
camilla@camilla:~/camilladsp/biquad$
I then used the edit function in WinSCP to add the filters to the appropriate .yml file.
Not sure if this is too off topic but I thought it might be of interest here as one of the more unusual CDSP implementations. I have one of these old V1.1 TV boxes and have setup CDSP on it running latest arch linux ARM. Runs cool. About as powerful as a RPI3 which is fine for my 2ch room correction use case. No more issues with corrupted sdcards on power outages. Potentially the display could be used to indicate sample rate/volume etc. All credit goes to Arnar Gauti Ingason who wrote this very entertaining read :
https://www.codedbearder.com/posts/mainline-linux-on-tx3-mini/
https://www.codedbearder.com/posts/mainline-linux-on-tx3-mini/
Hi all...
I'am doing some develop with my SuperPlayer script's, and so far i (partly)succesfully created some new functions (not on Github yet!) 😊
My Camilladsp config file is as it was from the beginning changed by a Python script on the fly (sample rate changes).
The config file is more or less the same as the Scripple $$ way, mine just look's like <<sample_rate>> instead.
Well nevermind that. Case is i have created some new way's of configuring it now.
This is the original way of configuring it :
The <<active_config>> is set when i wan't the active_config, created in the GUI to be used, when started.
The ##44100##, ##48000## etc... is used when i wan't to run a fixed samplerate.
Thoose changes can be set on the fly, e.g. by changing the cdsp_template.yml file. The script are looking for changes in the file, and when there is, it's automatically saved... That's all ok!
The develop is still in very early progress now, but i need some thing's.
The most correct way of saving stuff in piCorePlayer/TinyCore Linux is using the native RAM, to avoid saving directly on the SD-card.
But when something is changed directly in the CamillaGUI i need some way of having the files saved (the command filetool.sh -b) is used for this in TinyCore.
Is there somehow a trick to have the CamillaGUI execute "filetool.sh -b" on the OS, everytime something is changed by user @HenrikEnquist ?
Another thing i was also wondering about is, if there ever will be an option to have CamillaDSP change/resamble the incomming "Capture" samplerate.
One way of doing it, is with squeezelite before CamillaDSP, but i never tried that, really would prefer to have CamillaDSP to resample it on the Capture.
(I use stdout from squeezelite and stdin on CamillaDSP btw.)
Thank's a lot for all!
Jesper.
I'am doing some develop with my SuperPlayer script's, and so far i (partly)succesfully created some new functions (not on Github yet!) 😊
My Camilladsp config file is as it was from the beginning changed by a Python script on the fly (sample rate changes).
The config file is more or less the same as the Scripple $$ way, mine just look's like <<sample_rate>> instead.
Well nevermind that. Case is i have created some new way's of configuring it now.
This is the original way of configuring it :
But now i also created the possibility to set it as samplerate: <<active_config>> or samplerate: ##44100##
The <<active_config>> is set when i wan't the active_config, created in the GUI to be used, when started.
The ##44100##, ##48000## etc... is used when i wan't to run a fixed samplerate.
Thoose changes can be set on the fly, e.g. by changing the cdsp_template.yml file. The script are looking for changes in the file, and when there is, it's automatically saved... That's all ok!
The develop is still in very early progress now, but i need some thing's.
The most correct way of saving stuff in piCorePlayer/TinyCore Linux is using the native RAM, to avoid saving directly on the SD-card.
But when something is changed directly in the CamillaGUI i need some way of having the files saved (the command filetool.sh -b) is used for this in TinyCore.
Is there somehow a trick to have the CamillaGUI execute "filetool.sh -b" on the OS, everytime something is changed by user @HenrikEnquist ?
Another thing i was also wondering about is, if there ever will be an option to have CamillaDSP change/resamble the incomming "Capture" samplerate.
One way of doing it, is with squeezelite before CamillaDSP, but i never tried that, really would prefer to have CamillaDSP to resample it on the Capture.
(I use stdout from squeezelite and stdin on CamillaDSP btw.)
Thank's a lot for all!
Jesper.
One way of doing it, is with squeezelite before CamillaDSP....
This is my configuration and it indeed plays different sample rate files but display stays solid on 44,1.
But for some reason I cant figure out, I cant seem to get radio working - like playing SR P2.
Oops, apparently I use SqueezPlay - don't know the difference... but maybe it was something about being able to choose input source from configuration script which wasn't possible with Squeezlite...?
Like:
audio1@Audio1 bin % ./SPstartScript.sh -s
Type the number of the max rate to use:
1) 44.1kHz
2) 48kHz
3) 96kHz
4) 192kHz
#? 1
Using 44.1kHz
44100
Type the number of the device to use:
1) Built-in Output
2) Soundflower (2ch)
3) Soundflower (64ch)
#? 2
Soundflower (2ch)
audio1@Audio1 bin %
//
This is my configuration and it indeed plays different sample rate files but display stays solid on 44,1.
But for some reason I cant figure out, I cant seem to get radio working - like playing SR P2.
Oops, apparently I use SqueezPlay - don't know the difference... but maybe it was something about being able to choose input source from configuration script which wasn't possible with Squeezlite...?
Like:
audio1@Audio1 bin % ./SPstartScript.sh -s
Type the number of the max rate to use:
1) 44.1kHz
2) 48kHz
3) 96kHz
4) 192kHz
#? 1
Using 44.1kHz
44100
Type the number of the device to use:
1) Built-in Output
2) Soundflower (2ch)
3) Soundflower (64ch)
#? 2
Soundflower (2ch)
audio1@Audio1 bin %
//
Last edited:
Hi all (again)...
I sort of find a solution to one of my ask's here before.
I compiled a Python watchdog https://pypi.org/project/watchdog/ - which does excatly what i need here, watching the CamillaGUI configs directory for any change etc...
Everytime it sees a change it sends a command to backup 😊
Jesper.
I sort of find a solution to one of my ask's here before.
I compiled a Python watchdog https://pypi.org/project/watchdog/ - which does excatly what i need here, watching the CamillaGUI configs directory for any change etc...
Everytime it sees a change it sends a command to backup 😊
Jesper.
I see you already solved this with a wathdog. An alternative could be to add something to the "save_config" function in the backend: https://github.com/HEnquist/camillagui-backend/blob/master/backend/filemanagement.py#L128
Sorry, don't understand the question! Could be either of yes, no, or maybe 😛