Are these changes described in text anywhere so that one can prepare for an anpdate to 2.0 - which has to wait a few days for me I'm afraid...
//
//
I worked quite a bit on the documentation for the new version of pycamilladsp, but I didn't think of posting the link to it 🙂I've mostly got my head around the pycamilladsp nomenclature changes and can't wait to test out some of the new parameters like the config Title and Description fields.
It's published here: https://henquist.github.io/pycamilladsp/
Yes the new way is to use the statefile, -s. The old way with symlinks was clunky and didn't work on windows. With a statefile you can start camilladsp with just the statefile, andthen it will use the config file given in the statefile. If you give a config on the command line, that will override what you have in the statefile, so not recommended when you use the gui.There is just one thing I am unclear on. With the removal of active_config.yml what is the correct way to run camilladsp if you want to specify a configuration via the GUI? It seems like using "-s" to reference statefile.yml is the way to go but want to confirm.
I haven't written any migration guide or any tool for automatically updating an old config (yet at least). For most config files it's likely enough to just update the resampler options. The other changes are mostly new optional fields.Are these changes described in text anywhere so that one can prepare for an anpdate to 2.0
I worked quite a bit on the documentation for the new version of pycamilladsp, but I didn't think of posting the link to it 🙂
It's published here: https://henquist.github.io/pycamilladsp/
Yes the new way is to use the statefile, -s. The old way with symlinks was clunky and didn't work on windows. With a statefile you can start camilladsp with just the statefile, andthen it will use the config file given in the statefile. If you give a config on the command line, that will override what you have in the statefile, so not recommended when you use the gui.
Thanks for the info. The statefile seems to work well. Only issue I am seeing is that I typically specify a gain of -40 in my service to ensure that CamillaDSP always starts at a low level. From the documentation below my understanding is that this -40 gain should be applied on CamillaDSP restarts, however this is not happening, and the gain reverts to the last volume position.
Michael
Thanks for testing! I'll take a look. There is a lot of new code to handle the statefile, not surprising if there is a bug or two 🙂this -40 gain should be applied on CamillaDSP restarts, however this is not happening
@TNT thanks, that doesn't look quite right. Will fix!
Descriptive function names please - not requiring context... ;-)
Also set_main()
mainvol(), set_mainvol() ?
//
Also set_main()
mainvol(), set_mainvol() ?
//
Is anyone else experiencing the GUI level meters that disappear and come back 1-2 times a second in V2.0? I've checked three different browsers (chrome, safari, edge) and two different machines (mac and pc) and all have the same issue. There are no dropouts and the log shows no issues.
Michael
Michael
Yes there is a bug in the vu meter. It gets worse if you have several browser windows showing the gui at the same time. It will be fixed in the next preview.
I've been testing out how V2.0 handles invalid configurations while using statefile.yml and have run in to some issues.
I find that when I attempt to load an invalid configuration (say for a DAC that is not connected), I get nothing in the log. Sometimes I can get CamillaDSP to run again by setting a valid configuration as active but not always. When I am unable to get CamillaDSP to run after applying an invalid configuration the only way to solve the issue is to delete statefile.yml. It seems like CamillaDSP is getting stuck with the bad configuration in statefile.yml and will not overwrite it, even when a valid configuration is set as active.
Michael
I find that when I attempt to load an invalid configuration (say for a DAC that is not connected), I get nothing in the log. Sometimes I can get CamillaDSP to run again by setting a valid configuration as active but not always. When I am unable to get CamillaDSP to run after applying an invalid configuration the only way to solve the issue is to delete statefile.yml. It seems like CamillaDSP is getting stuck with the bad configuration in statefile.yml and will not overwrite it, even when a valid configuration is set as active.
Michael
The initial volume and mute issue is fixed.
I'm trying to reproduce the statefile problems, but haven't managed so far. Can you give the exact steps you use to trigger it? What do you get in the camilladsp logs when it happens? There should be messages on debug level both when it read and writes the statefile.
I'm trying to reproduce the statefile problems, but haven't managed so far. Can you give the exact steps you use to trigger it? What do you get in the camilladsp logs when it happens? There should be messages on debug level both when it read and writes the statefile.
The initial volume and mute issue is fixed.
I'm trying to reproduce the statefile problems, but haven't managed so far. Can you give the exact steps you use to trigger it? What do you get in the camilladsp logs when it happens? There should be messages on debug level both when it read and writes the statefile.
The log is erased when I load the invalid configuration, it is completely blank. Looking at this some more CamillaDSP goes offline when this happens and then cannot come back online. I have noticed that using "-w" in my service seems to make the issue go away because CamillaDSP will stay online, even if the config in statefile.yml is invalid.
As I don't get a log in the GUI when this happens I ran CamillaDSP from the command line. I started with a valid configuration and then switched to an invalid configuration which causes CamillaDSP to crash. Once it crashes I cannot restart it as shown in the log.
I also tried the same but using "-w" and that worked fine.
I think the learning here for me is I need to use "-w" when using the GUI/statefile. Is this expected behavior?
Michael
Attachments
Hi Henrik,The first preview of v2.0 is up, get it at https://github.com/HEnquist/camilladsp/releases/tag/v2.0.0-alpha1
does CamillaDSP v2.0 hande the automatic samplerate switching when used with a usb gadget capture device?
@Sandor no, it still needs help by with the switching.
Take a look at https://github.com/pavhofman/gaudio_ctl
It takes a bit of work to implement, but you should be able to use this to restart camilladsp with a new config when the sample rate changes.
Take a look at https://github.com/pavhofman/gaudio_ctl
It takes a bit of work to implement, but you should be able to use this to restart camilladsp with a new config when the sample rate changes.
I already use gaudio_ctl with success.Take a look at https://github.com/pavhofman/gaudio_ctl
Thanks for answering.
I have developed an automatic sample rate switcher for CamillaDSP.
Unlike gaudio_ctl, this tool is dedicated to updating the CamillaDSP configuration. It also automatically reloads a valid configuration after the playback device has been unavailabe for a while (e.g. when you switch the input of your DAC from USB to S/P-DIF and then back to USB).
Details and software are available on github.
camilladsp-setrate
Unlike gaudio_ctl, this tool is dedicated to updating the CamillaDSP configuration. It also automatically reloads a valid configuration after the playback device has been unavailabe for a while (e.g. when you switch the input of your DAC from USB to S/P-DIF and then back to USB).
Details and software are available on github.
camilladsp-setrate
- Home
- Source & Line
- PC Based
- CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc