Cool... Yes my shed is an secret entrance ofcause... busted
Well.
I was looking at the nice gui, but i'am in doubt what i need to have running on the Picoreplayer/Tinycore linux dist.
I have this running on the Picoreplayer now:
python3.6
websocket-client
CamillaDSP
Custom-squeezelite
I need to have as little as possible running on the Picoreplayer, so what is the minimum we need to have to connect to CamillaDSP from a laptop or like?
I will then start to create Picoreplayer/TinyCoreLinux .tcz extensions for thoose needed
Jesper.
Good luck! I spent a lot of time trying to get the gui to work with pcp. Eventually I switched to dietpi and everything is working now.
I will try...
You helped me get started and howto create EQ-prefilter and stuff, also helped me with the DRC part with Gmads script's. - I learnedhow the impulse responce must "look" like and stuff... From that i succesfull created some nice filters for my stereo, which helped a lot regarding the too much bass boost i had etc...
Jesper.
You helped me get started and howto create EQ-prefilter and stuff, also helped me with the DRC part with Gmads script's. - I learnedhow the impulse responce must "look" like and stuff... From that i succesfull created some nice filters for my stereo, which helped a lot regarding the too much bass boost i had etc...
Jesper.
Hi,
stdin/stdout is working. It is also mentioned in the documentation here:
GitHub - HEnquist/camilladsp: A flexible linux IIR and FIR engine for crossovers, room correction etc.
stdin/stdout is working. It is also mentioned in the documentation here:
GitHub - HEnquist/camilladsp: A flexible linux IIR and FIR engine for crossovers, room correction etc.
Now it's possible to run the backend without numpy/matplotlib. Instead of usual plots it displays a placeholder message.
It's handled automatically by checking if it's possible to import pycamilladsp-plot. If not, plotting is disabled.
Another change is that it now includes a very basic VU meter in the left panel.
New release here: Release v0.4.2 * HEnquist/camillagui-backend * GitHub
It's handled automatically by checking if it's possible to import pycamilladsp-plot. If not, plotting is disabled.
Another change is that it now includes a very basic VU meter in the left panel.
New release here: Release v0.4.2 * HEnquist/camillagui-backend * GitHub
OK. I'll look it up.
On the github frontpage (Readme) the text is a bit misleading:
This is not correct then. It should be phrased differently. Perhaps Henrik should also list file and stdin as capture options.
*****
I got another Q.
Has C-DSP a dry-run "dirac" filter functionality like brutefir to be able to e.g. test higher taps (2^16) filter functionality and load on the machine before playing around with filters?
THX
Oh right, that little section part is completely outdated, I'll rewrite. Thanks for spotting!
There is a simple dry-run feature but it will only make a filter that is one chunksize long (so no segmented convolution). This is enabled by setting the type in the parameters of a Conv filter to "Values", and then leaving out the "values" key. Not very useful for testing cpu load. I could add a "Dirac" type where you specify the length.
Perfect Henrik...
I am making some progress, later i have some basic questions.
I will try this simplyfied "version" for a start without plotting on Picoreplayer.
Jesper.
That'd be nice.
Q.
If FFTW3 is being used, would this imply that also the ARM Neon support of FFTW3 will
be used for C-DSP?
Background: I'm running all the stuff on a PI4. I measured 30% improvement when benchmarking flac plus NEON support vs. normal flac. ARM Neon can make a nice difference.
Hello...
So i have now CamillaDSP 0.4.0 running fine on my Picoreplayer/SuperPlayer
(RPI)
I will now try to make the GUI work, so for a start i will pip3 install most stuff to see if i can get it running.
First i installed setuptools
Then i transfered the hole unzipped pycamilladsp-master dir to /home/tc/DSP_Engine
from within that dir i executed sudo -H pip3 install .
Everything is then placed in /usr/local/lib/python3.6/site-packages without error's...
I then executed, also without any errors : sudo -H pip3 install aiohttp
This is also placed in /usr/local/lib/python3.6/site-packages
Next i transfered the hole dir Camilla_GUI_v0.4.2 to /home/tc/DSP_Engine.
So now my DSP_Engine dir looks like this :
I don't know why, but i allway's had problems understanding how backend, frontend and so is working,
So now i don't know howto configure the backend server, so that i can see it from my laptop (running Linux on this one too)
Hoping someone can tell me that stuff?
Thank's all in advance...
Jesper.
So i have now CamillaDSP 0.4.0 running fine on my Picoreplayer/SuperPlayer
(RPI)I will now try to make the GUI work, so for a start i will pip3 install most stuff to see if i can get it running.
First i installed setuptools
Then i transfered the hole unzipped pycamilladsp-master dir to /home/tc/DSP_Engine
from within that dir i executed sudo -H pip3 install .
Everything is then placed in /usr/local/lib/python3.6/site-packages without error's...
I then executed, also without any errors : sudo -H pip3 install aiohttp
This is also placed in /usr/local/lib/python3.6/site-packages
Next i transfered the hole dir Camilla_GUI_v0.4.2 to /home/tc/DSP_Engine.
So now my DSP_Engine dir looks like this :
I don't know why, but i allway's had problems understanding how backend, frontend and so is working,
So now i don't know howto configure the backend server, so that i can see it from my laptop (running Linux on this one too
)Hoping someone can tell me that stuff?
Thank's all in advance...
Jesper.
One more.
Q1. Where to apply volume control?
Some thoughts.
From what I've seen many people run the DSP after the (SW) volume control stage, which usually is done inside the feeding app.
E.g. If you'd pipe squeezelite into the DSP, squeezelite would be done with the volume control and the signal would usually be down by 20-30dB at that point.
Then the DSP will add another 6dB att or so prior to the filter. That'd also happen if you use these Alsa loopdevices.
The signal would therefore already be seriously degraded when hitting the filter section.
Q2: How much would it matter?
I'm not really sure. To me it looks not that great.
Q3: A way out?
In case of LMS/squeezelite we'd be talking about running Camilla-DSP on the server (stdin and stdout) and NOT after squeezelite (via Alsa or stdout ). With this solution
we'd filter the original file only degraded by the 6dB prior to the filter. The SW volume control would then come after the filter section.
Any other thoughts or solutions?
THX
Q1. Where to apply volume control?
Some thoughts.
From what I've seen many people run the DSP after the (SW) volume control stage, which usually is done inside the feeding app.
E.g. If you'd pipe squeezelite into the DSP, squeezelite would be done with the volume control and the signal would usually be down by 20-30dB at that point.
Then the DSP will add another 6dB att or so prior to the filter. That'd also happen if you use these Alsa loopdevices.
The signal would therefore already be seriously degraded when hitting the filter section.
Q2: How much would it matter?
I'm not really sure. To me it looks not that great.
Q3: A way out?
In case of LMS/squeezelite we'd be talking about running Camilla-DSP on the server (stdin and stdout) and NOT after squeezelite (via Alsa or stdout ). With this solution
we'd filter the original file only degraded by the 6dB prior to the filter. The SW volume control would then come after the filter section.
Any other thoughts or solutions?
THX
I use this binding for FFTW: GitHub - rust-math/fftw: FFTW3 binding for Rust
The default setting is to compile FFTW from source, and that is done without any extra features (so no avx, sse, neon etc). The options are here: FFTW 3.3.8: Installation on Unix
It would be nice if the various extra instruction sets were exposed as options, but that is probably quite tricky to make work reliably for all supported systems.
The alternative (which I haven't explored yet) is to use the system FFTW library. This can then be compiled with whatever instruction sets you want to enable. I have not tried this, but if you want to give it a go I can show you how to enable it.
Up to and including aiohttp it looks good. Then you probably downloaded the source code of the backend, which is only half of what you need. You need camillagui.zip from here: Release v0.4.2 * HEnquist/camillagui-backend * GitHubHello...
So i have now CamillaDSP 0.4.0 running fine on my Picoreplayer/SuperPlayer
I will now try to make the GUI work, so for a start i will pip3 install most stuff to see if i can get it running.
First i installed setuptools
Then i transfered the hole unzipped pycamilladsp-master dir to /home/tc/DSP_Engine
from within that dir i executed sudo -H pip3 install .
Everything is then placed in /usr/local/lib/python3.6/site-packages without error's...
I then executed, also without any errors : sudo -H pip3 install aiohttp
This is also placed in /usr/local/lib/python3.6/site-packages
Next i transfered the hole dir Camilla_GUI_v0.4.2 to /home/tc/DSP_Engine.
So now my DSP_Engine dir looks like this :
I don't know why, but i allway's had problems understanding how backend, frontend and so is working,
So now i don't know howto configure the backend server, so that i can see it from my laptop (running Linux on this one too
Hoping someone can tell me that stuff?
Thank's all in advance...
Jesper.
All web apps are split into a backend and a frontend. The frontend is html and javascript, and runs in the browser. This is the part you see. It can't talk to databases, or hardware etc directly. Instead all low level stuff is handled by a backend that runs on the server side. This backend presents an interface the frontend can talk to via http requests. The backend then translates between a http request to some more low level function, like opening a file or asking some other process for some piece of information.
The frontend code must be provided to the browser. In a large system with many users this part is handled by a dedicated web server (which becomes the third part) for performance reasons. Here, with one or possibly a few clients, this isn't necessary and the backend can easily handle serving that as well. This is why the full backend package also must include the frontend code.
Another thing, the frontend code that is included in the backend zip is a "compiled" version. I write "compiled" because it's actually compiled from javascript to javascript. What it does it optimize the code and include only the parts of all libraries that are actually used.
Does this help?
I prefer to use some hardware volume control (with remote) either inside the dac or after the dac. With a 24-bit dac software volume control is basically the same quality, but I don't fully trust a software volume control to never, not even once, forget the volume setting and go to full volume.
I don't know enough about squeezelite to give a very good answer. Does it always output the same format it's playing, eg 16-bit it output as 16-bit? Or can it give 32 bits no matter what the file is? If it's outputting 16 bits, then it would be a pity if the sw volume control is done in squeezelite. But if it actually gives 32 bits out, then a 20dB attenuation of a 16-bit signal isn't degrading the signal. It's of course not bit perfect, but it still contains all the 16 bits of information. This signal can then be fed through DSP without any problems. The result would be the same as going into the DSP at full volume and then doing sw volume control after.
Placing the filtering server-side is quite elegant. From my limited reading about this, it seems not that difficult and it has been working with brutefir but probably doesn't any more since the plugin isn't maintained (I could easily be wrong here). The existing plugin should be a good starting point for a camilladsp integration, even if it's currently broken.
The potential problem is what happens if you have multiple clients, let's say a primary and secondary sound system in different rooms. Can each client request a separate filter? If not it becomes locked to a single client and you need a separate server for each client.