Also Jesper will probably need to set the port to 3011 in camillagui.yml in the config subfolder of camillagui. And lastly start the server with :
python3 /home/tc/camillagui/main.py
You can add this command to your startup file later.
[Henrik]
This dir contains this:
I am sure this is wrong, as i have pointed the config & coeff dir to where i have my filters
Also i'am not sure what coeff filters are ?
[wineds]
Thanks
... In my case (for now) i start the server with:
I can actually make it start, but webinterface tells me i am offline.
And after that the output of then main.py start spitting a lot of errors:
I'am sure my config is the problem here.
Jesper.
I think i got this package right. I have placed it (just for test for now) /home/tc/DSP_Engine/Camilla_GUI_v0.4.2
This dir contains this:
And the config is like this:
I am sure this is wrong, as i have pointed the config & coeff dir to where i have my filters
Also i'am not sure what coeff filters are ?
[wineds]
Thanks
... In my case (for now) i start the server with:I can actually make it start, but webinterface tells me i am offline.
And after that the output of then main.py start spitting a lot of errors:
I'am sure my config is the problem here.
Jesper.
Attachments
Nobody (I know) uses HW volume (pot or IR) controls anymore.
squeezelite or mpd would let you use a DAC based VC, but only if you have that DAC defined as output device and the DAC offers it via driver. In case of attached DSP (Camilla or brutefir) squeezelite or mpd would just see stdout or alsaloop. I don't know if you can define mixer-in mixer-out features in the asound.conf of the alsaloop device that would transparently transfer the VC codes from app to the HW.
lykkedk could of course further hack squeezelite to bypass the alsaloop output towards the DSP and talk to the DAC (amixer) directly regarding HW VC control.
squeezelite like mpd can output pretty much any samplerate or precision. 32bit is no issue. But I don't see your 20dB. Camilla alone does at least 6dB. Therefore in real life I'd expect rather a 30dB+ attenuated signal entering the DSP. I havn't seen many people running a gain optimized chain.
All this is no issue or discussion if you run the DSP before the player app or volume control stage.
LMS can handle it with a simple one-liner in the custom-convert.conf.
If you'd need a more complex filter switching feature you simply write a basic
wrapper-script and refer to it in the custom-convert.conf . It'd work with pipes file>>DSP>>stdout or file>>app>>stdoutin>>DSP>>stdout . app can be any app like sox, flac or alike. There's no need for LMS plugins. Most of them are not well maintained anyhow.
On top LMS allows to route a pipe to whatever client identified by MAC.
The only reason for not using LMS as the DSP host is if you go multichannel.
For those doing room correction and a bit of EQing LMS would probably be the better choice.
There's more beside the LMS universe.
Most other quality (pro) apps work with ""plugins"". For a reason. They all do the DSP part prior to VC. VC is usually the last part of the chain.
Alsa controls and alsa stream are configured separately in asound configs - pcm vs. ctl sections. That gives an option for players which do not have a separate config for volume control (e.g. mixer_device in mpd) to use a single pcm device for pcm and ctl methods and yet route the ctl commands to a different alsa device. I.e. the stream can go to aloop, while volume control commands are passed to the actual soundcard, circumventing the DSP chain.
That's nice to know. So. For audiointerfaces that offer ondevice VC via driver that'd be the way to go.
Ah now I see! The problem is just that you are running the old version of pycamilladsp, from before I changed to the json protocol. Get this one instead: https://github.com/HEnquist/pycamilladsp/archive/develop.zip
Since everything 0.4.x is in beta at the moment things are a bit messy, sorry about that. Once I make production 0.4 release I will merge everything to master.
Use develop for camilladsp and pycamilladsp, and master for pycamilladsp-plot. For the backend you should use the zip from the latest release.
I would actually say the exact opposite. Nobody I know uses software volume control!Nobody (I know) uses HW volume (pot or IR) controls anymore.
squeezelite or mpd would let you use a DAC based VC, but only if you have that DAC defined as output device and the DAC offers it via driver. In case of attached DSP (Camilla or brutefir) squeezelite or mpd would just see stdout or alsaloop. I don't know if you can define mixer-in mixer-out features in the asound.conf of the alsaloop device that would transparently transfer the VC codes from app to the HW.
lykkedk could of course further hack squeezelite to bypass the alsaloop output towards the DSP and talk to the DAC (amixer) directly regarding HW VC control.
squeezelite like mpd can output pretty much any samplerate or precision. 32bit is no issue. But I don't see your 20dB. Camilla alone does at least 6dB. Therefore in real life I'd expect rather a 30dB+ attenuated signal entering the DSP. I havn't seen many people running a gain optimized chain.
All this is no issue or discussion if you run the DSP before the player app or volume control stage.
LMS can handle it with a simple one-liner in the custom-convert.conf.
If you'd need a more complex filter switching feature you simply write a basic
wrapper-script and refer to it in the custom-convert.conf . It'd work with pipes file>>DSP>>stdout or file>>app>>stdoutin>>DSP>>stdout . app can be any app like sox, flac or alike. There's no need for LMS plugins. Most of them are not well maintained anyhow.
On top LMS allows to route a pipe to whatever client identified by MAC.
The only reason for not using LMS as the DSP host is if you go multichannel.
For those doing room correction and a bit of EQing LMS would probably be the better choice.
There's more beside the LMS universe.
Most other quality (pro) apps work with ""plugins"". For a reason. They all do the DSP part prior to VC. VC is usually the last part of the chain.
The 20dB is just a number I took since you wrote it somewhere. Let's say we convert 16 bits to 32 bit int. That means we are using the 16 upper bits out of the 32. The 16 lower bits are all empty, meaning the lsb of the actual signal sits 96dB above the lsb of the data. In this case it would be fine to attenuate by up to 96dB without losing any information. If we go with the common 32-bit float instead, we have a 24 bit significand, which give a margin of 48 dB.
Once the signal reaches Camilladsp it gets converted to 64-bit float, which has a significand of 53 bits. The numerical noise from FFT etc ends up in the -300dB range even if many long filters are used. So even if you send in a heavily attenuated signal, the numerical noise from the DSP won't affect it.
It changes a bit if we compile for 32-bit floats. Then the numerical noise ends up in the -140dB range. A heavily attenuated signal would get some added noise from filtering. That noise will still be lower than the noise floor of DACs, but it's getting close. There is however very little reason for running with 32-bit floats since 64 bit is nearly as fast nowadays.
So the short version is that f you run 64-bit floats, in practice it doesn't matter if you have the sw volume control before or after the dsp. With 32-bit float, it makes a small difference that most likely drowns in the dac noise.
You know me now.
And probably some others.
Where have you been the last decade. Pretty much the entire computer based audio world, incl. the streaming world and smartphone world asf. uses SW volume control.
Not sure what you're talking about.
Ok if you include phones, laptops etc then of course I and everyone I know use sw volume control. I meant just in the main hifi system.You know me now.
And probably some others.
Where have you been the last decade. Pretty much the entire computer based audio world, incl. the streaming world and smartphone world asf. uses SW volume control.
Not sure what you're talking about.
Got it running now...
My workflow in very early state get it going like this :
Rgds; Jesper.
Attachments
I spent a bit of time tweaking my room EQ filters on the weekend. Recreating a new set of filters for 5 different sample rates (ie : 10 filters) in rephase is quite laborious and error prone. This is in no way a criticism of rephase! Would it be useful if CamillaDSP could directly import REW filter settings which are in XML format? Rephase can import this format. Additionally CamillaDSP could then create filters on the fly for whatever sample rate was incoming?
Last edited: