The automatic sample rate switcher works with any playback device, as it depends on the capture device.Quick question. Only USB dacs?
The automatic unlock of the DSP after temporary unavailability of the playback device works with USB DACs only.
Last edited by a moderator:
I just published v2.0.0-alpha2 of camilladsp, python libs, and the gui.
There are changes to all parts, so upgrade everything to the v2.0.0-alpha2 release.
This should make sure that the command line volume and mute overrides whatever is in the state file. It also fixes the misbehaving vu meter in the gui.
Finally the python libs are now using pyproject.toml instead of setup.py, which should avoid some warnings that setup.py is deprecated.
There are changes to all parts, so upgrade everything to the v2.0.0-alpha2 release.
This should make sure that the command line volume and mute overrides whatever is in the state file. It also fixes the misbehaving vu meter in the gui.
Finally the python libs are now using pyproject.toml instead of setup.py, which should avoid some warnings that setup.py is deprecated.
There must be some way to detect the playback device is not active anymore. IIUC the camilladsp-setrate project does that via udev detecting removal of the USB audio device https://github.com/marcoevang/camilladsp-setrate/blob/main/85-DAC.rules , signalling the event to the setrate project.Quick question. Only USB dacs?
E.g. if your DAC switches from I2S input to SPDIF input and the I2S input is slave (i.e. transmitter is the master), there is no way to detect this change without some custom side channel - the I2S transmitter will still be able to transmit data and does not know that the other side is not using them.
Theoretically it could work for an I2S slave transmitter provided a DAC will stop supplying I2S clocks upon switching to other source. But I have not seen an I2S master DAC with switching to SPDIF input on the market.
The mentioned udev rule signals to camilladsp-setrate the appearance of a USB playback device, not its removal.IIUC the camilladsp-setrate project does that via udev detecting removal of the USB audio device
In my DAC (SMSL DO100), if I switch from a non-USB input to USB input, that udev rule is triggered. Someone testing my tool please confirm whether this also applies to other USB DACs.
if your DAC switches from I2S input to SPDIF input
Unfortunately, I have no means of doing tests with I2S inputs.
I am blind, thanks! 🙂The mentioned udev rule signals to camilladsp-setrate the appearance of a USB playback device, not its removal.
I do not think it would work anyway, the I2S receiver in master mode cannot detect/report if the slaved DAC is listening or not.Unfortunately, I have no means of doing tests with I2S inputs.
A slaved I2S receiver gets stuck when the master DAC stops the clock - alsa stops consuming samples and eventually returns error - that mode is supported in CDSP, IMO (at least on capture side).
I would like to clarify that my answer concerned the playback device only (playback from camilladsp's point of view).The automatic sample rate switcher works with any playback device, as it depends on the capture device.
The automatic unlock of the DSP after temporary unavailability of the playback device works with USB DACs only.
camilladsp-setrate is meant for use with a usb gadget capture device, as highlighted in the github page.
Last edited:
Yes, I wrongly said I2S receiver instead of transmittter - it should have been "A slaved I2S transmitter gets stuck when the master DAC stops the clock", the post cannot be edited anymore.would like to clarify that my answer concerned the playback device only (playback from camilladsp's point of view).
you can always ask a moderator to edit a post when you cannot because the time limit for editing has expired. One way to do that is to use the "Report" link at the bottom left corner of the post to report your own post and ask for a correction to the mistake in the text.
Last edited:
I've noticed that the GUI compact view no longer works with V2.0, not a huge deal to me as I don't use it but wanted to make sure the issue was reported.
Otherwise alpha2 seems to working well, no more level meter issues and volume override in the case of restart works great.
Thank you for the Title field, that works really well for pulling a line of text into a display that is unique to a configuration.
MIchael
Otherwise alpha2 seems to working well, no more level meter issues and volume override in the case of restart works great.
Thank you for the Title field, that works really well for pulling a line of text into a display that is unique to a configuration.
MIchael
@HenrikEnquist The screen is completely blank when I click the button. I get the same result on Chrome and Safari on a Mac, Edge on a PC and Safari on an iPhone. If I refresh my browser from the blank screen I see the compact view popup for a fraction of second but then it disappears.
Michael
Michael
Ok that looks like some script error and there should be an error in the browser console. Can you check?If I refresh my browser from the blank screen I see the compact view popup for a fraction of second but then it disappears.
@HenrikEnquist Thanks for the tip, I figured it out. Here is the log when attempting to enter compact mode, it seemed to fail because a Bass filter was not defined. I added Bass / Treble filters and I was able to use compact mode.
I thought this was odd so I dug in a bit more. To preface this I was using very simple configurations with no filters defined or applied and was starting from a V1 configuration converted to V2.
To minimize variables I started from a blank configuration in V2 and noticed that if no filters were specified the configuration showed filters: {}. When converting my old configuration from V1 to V2 I completely deleted my Filter section of my configuration as previously the only filter I had defined was a Volume filter which was not needed in V2.
Just adding filters: {} to my old configuration (without a Bass / Treble filter) completely solved the issue. So a dumb conversion issue that I should have seen on my end and is unlikely to occur in normal non-testing applications as there will almost always filters applied.
Michael
Code:
react-dom.production.min.js:189 TypeError: Cannot read properties of null (reading 'Bass')
at Ei (config.ts:695:31)
at vM (shortcuts.tsx:34:16)
at Sa (react-dom.production.min.js:167:137)
at ku (react-dom.production.min.js:290:337)
at bl (react-dom.production.min.js:280:389)
at yl (react-dom.production.min.js:280:320)
at gl (react-dom.production.min.js:280:180)
at ol (react-dom.production.min.js:271:88)
at ul (react-dom.production.min.js:273:300)
at Bi (react-dom.production.min.js:127:105)
hs @ react-dom.production.min.js:189
n.callback @ react-dom.production.min.js:189
Fo @ react-dom.production.min.js:144
_u @ react-dom.production.min.js:262
bu @ react-dom.production.min.js:260
mu @ react-dom.production.min.js:259
(anonymous) @ react-dom.production.min.js:283
xl @ react-dom.production.min.js:281
ul @ react-dom.production.min.js:273
Bi @ react-dom.production.min.js:127
(anonymous) @ react-dom.production.min.js:267
config.ts:695 Uncaught TypeError: Cannot read properties of null (reading 'Bass')
at Ei (config.ts:695:31)
at vM (shortcuts.tsx:34:16)
at Sa (react-dom.production.min.js:167:137)
at ku (react-dom.production.min.js:290:337)
at bl (react-dom.production.min.js:280:389)
at yl (react-dom.production.min.js:280:320)
at gl (react-dom.production.min.js:280:180)
at ol (react-dom.production.min.js:271:88)
at ul (react-dom.production.min.js:273:300)
at Bi (react-dom.production.min.js:127:105)
I thought this was odd so I dug in a bit more. To preface this I was using very simple configurations with no filters defined or applied and was starting from a V1 configuration converted to V2.
To minimize variables I started from a blank configuration in V2 and noticed that if no filters were specified the configuration showed filters: {}. When converting my old configuration from V1 to V2 I completely deleted my Filter section of my configuration as previously the only filter I had defined was a Volume filter which was not needed in V2.
Just adding filters: {} to my old configuration (without a Bass / Treble filter) completely solved the issue. So a dumb conversion issue that I should have seen on my end and is unlikely to occur in normal non-testing applications as there will almost always filters applied.
Michael
Thanks for investigating! It's supposed to work even if the filters section is completely missing. I'll fix that for the next preview.
I have updated and extended the setup scripts to work on Linux, MacOS and Windows. Very preliminary for now, but if someone wants to give them a try they are here: https://github.com/HEnquist/camilladsp-setupscripts/tree/linux_venv
There are two versions, one for conda and one for venv. Both work fine for running the gui, but venv needs less space and seems generally to be faster to set up.
As usual, any feedback is appreciated 🙂
There are two versions, one for conda and one for venv. Both work fine for running the gui, but venv needs less space and seems generally to be faster to set up.
As usual, any feedback is appreciated 🙂
There are two bugs I found in Alpha-2 so far. One is that from time to time, in volume section, output level bars will not disappear even there is no input. The other one is that when creating a new config in GUI with different sample rate(comparing to the sample rate of the config that is applied at the moment) with resampler_type set to none, the capture sample rate will not change to the new value unless you set resampler_type to values other than "none". Minor issues though.
Attachments
- Home
- Source & Line
- PC Based
- CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc