pi r!
Great new's really great :
I have no problem on my homesystem with Python's running...
+3 and proberly more running for day's and day's since last poweroutrage
There was some post around letting the LMS server handle the conversion and filter's, like the Brutefir drc plugin used to do, also this is a good idea but for me i rather have it working local on the player's; not that it's a bad idea but because of the flexibility and the easyness of disabling it if i e.g would like to listning with my headphones
...
I used to have a script accepting an ssh from my phone running, to change filter or to disable it... works like a charm
Looking forward to see what you came up with pi r!
Jesper.
Great new's really great :
I have no problem on my homesystem with Python's running...
+3 and proberly more running for day's and day's since last poweroutrage
There was some post around letting the LMS server handle the conversion and filter's, like the Brutefir drc plugin used to do, also this is a good idea but for me i rather have it working local on the player's; not that it's a bad idea but because of the flexibility and the easyness of disabling it if i e.g would like to listning with my headphones
...I used to have a script accepting an ssh from my phone running, to change filter or to disable it... works like a charm
Yes and no for me... I would also like to have a full 64bit system running, but as a long term TinyCore/Picore user i like to deal with piCorePlayer, mostly to help other accomplish what they want and soo on...
Looking forward to see what you came up with pi r!
Jesper.
Yes I'm in the wrong spot. I thought I was being helpful but I've given a solution to a problem that no one wants.
Yes the stop and start scripts can be killall camilladsp and camilladsp {rate appropriate config} if you want. No guarantees you won't drop audio that way though or play some audio through the wrong filters as camilla is restarting or reconfiguring. The hook has the advantage of being able to force any player to pause until camilla is fully reconfigured and ready but you don't have to use it. From a loopback perspective you really just need camilla to close the loopback before the player tries to change the hw params to make the player happy. It will keep dumping audio through the loopback even if camilla never gets run.
Stdin/stdout synchronization is potentially more complicated, but maybe not. Given camilla is I believe 3 threads I'll leave it to Henrik to answer how it will behave if its input and output threads are happily chewing along on stdin/out and the control thread gets a reconfigure command that should be applied at a given point in the stdin stream. Or how he handles flushing the remainder of the stdin stream if you kill camilla and restart it. Or any other possible sync issue that comes with the control sitting outside the data stream.
I think there are still users who would want this. Maybe me
But if you give it up and wanting something to do this could maybe be something to spend a few CPU cycles on:
I wireless volume control that interacts with CamillaDSP to be the main and only volume control (inc dither NB!) in a system. I would wish something really slick like the table thingy for Devialet... a pot, a BT send/rec unit and something in the other end...
//
But if you give it up and wanting something to do
this could maybe be something to spend a few CPU cycles on:I wireless volume control that interacts with CamillaDSP to be the main and only volume control (inc dither NB!) in a system. I would wish something really slick like the table thingy for Devialet... a pot, a BT send/rec unit and something in the other end...
//
Any BTE volume control sending HID keyboard media keys can be easily integrated, commercial or diy (e.g. Overview | BLE Volume Knob with CircuitPython | Adafruit Learning System )
If you count everything, including the websocket server, its five threads, plus one for each active websocket connection. Without the websocket server it's four.
A reload command is handled in the same way for all backends. The capture thread checks if it should exit between each chunk. If there is a stop command, it will not read any more from the device/file/pipe. Any remaining data there will be ignored. Instead it sends an EndOfStream message to the processing thread. Then it exits, and closes any open device/pipe/file.
The processing thread processes all chunks in order, and when it gets to the EndOfStream chunk (which contains no data) it passes this along to the playback thread, and exits.
The playback thread then continues to play any chunk in the queue, and once it reaches the EndOfStream it exits, closing the device/pipe/file.
Finally the supervising thread waits for all three to exit. Once they are all down, it either exits or starts up new threads to handle a new config.
That should be a fun little project
It would only need a little python script that reads the value of the knob, and then updates the camilla config via the websocket server. Want to give it a go yourself? Just ask if you get stuck.I've tried to get my piped setup to start nicely in pCP's standard environment, configured from the web page. It doesn't seem to be possible.
They use the shell command "start-stop-daemon" to run squeezelite. And as far as I understand (very limited) the start-stop-daemon detaches both stdin, stdout and stderr of the program to run, from all terminals. I have not managed to pipe anything anywhere, when run through start-stop-daemon.
Anyone who knows better..?
Otherwise we are forced to disable squeezelite in pCP's web-setup, and start it with our own start script. It might be to early to just start without a delay from /opt/bootlocal.sh
They use the shell command "start-stop-daemon" to run squeezelite. And as far as I understand (very limited) the start-stop-daemon detaches both stdin, stdout and stderr of the program to run, from all terminals. I have not managed to pipe anything anywhere, when run through start-stop-daemon.
Anyone who knows better..?
Otherwise we are forced to disable squeezelite in pCP's web-setup, and start it with our own start script. It might be to early to just start without a delay from /opt/bootlocal.sh
Pi r.
Do you care to share the setup and script's you struggling with getting started at pCP?
In meantime, TNT trigged an old idea i had making a wireless media/volume controller so i bougth this from Ebay; but hey it's offtopic sry...
Espressif esp32 Wifi Dev Kit development board Bluetooth WiFi v1 Factory 32 nodemcu | eBay
Let's see if i can make it a fun winter-project
TNT
What do you mean writing (inc dither NB!)
Jesper.
Do you care to share the setup and script's you struggling with getting started at pCP?
In meantime, TNT trigged an old idea i had making a wireless media/volume controller so i bougth this from Ebay; but hey it's offtopic sry...
Espressif esp32 Wifi Dev Kit development board Bluetooth WiFi v1 Factory 32 nodemcu | eBay
Let's see if i can make it a fun winter-project
TNT
What do you mean writing (inc dither NB!)
Jesper.
Attachments
Last edited:
I would have... if it wasn't for a power outage yesterday, and some other business today. The power outage was planed, so could shut down properly in advance. But when I was back on line again, I had all sorts of new problems. Most worrying is a lot of snaps and cracks while playing. I replaced the power supply to my pCP while the power was out. I believed it should be better, but it gave me hell... Still struggling to find my way back on track...
The "pipe" setup with the standard squeezelite I'm working with, is otherwise really promising. It will be much easier to setup, and can still use pCP's built in web interface to configurate squeezelite.
I have made a script that handles start and stop of squeezelite + camilladsp + a daemon for sample rate switching, both on boot and manually.
I will pack it all in a tar.gz file. that then can be unpacked with all files in the right places, with the right owner and permissions, all in one go.
I'm almost there... Have a little patience with me... My capacity is limited, and far from Henrik...
The "pipe" setup with the standard squeezelite I'm working with, is otherwise really promising. It will be much easier to setup, and can still use pCP's built in web interface to configurate squeezelite.
I have made a script that handles start and stop of squeezelite + camilladsp + a daemon for sample rate switching, both on boot and manually.
I will pack it all in a tar.gz file. that then can be unpacked with all files in the right places, with the right owner and permissions, all in one go.
I'm almost there... Have a little patience with me... My capacity is limited, and far from Henrik...
I do have issues with sound disruptions of various kinds with my "piped" setup. And I have trouble to isolate them, and I think some parallel testing would be good. So I'd like if someone else would like to test it..?
I have put everything you need to test on a working pCP device in a tar file. Including camilladsp v0.4.0-beta-4 and some of my .yml config files to help getting started. It should be possible to run this setup without interfering with Jesper's (lykkedk) setup, in the same mashine. Just make sure you stop both squeezelite and camilladsp before you try to start up my setup.
Installation is easiest if you unpack my .tar file with the path directed to the file root "/" with the "-C /" option. The .tar file can be saved anywhere, and the unpacked files will end up at the right places, with ownership and permissions allreadt set.
It will create a new folder at: /home/tc/camilladsp and put some config files there. If you already have a folder with that name - rename or move it first. Another new folder will be created at: /opt/camilladsp with the executable files.
Remove the option "-C /" if you just want to unpack into current folder, and then move the files yourself. My script for starting, will not work if the those two folder-names are changed.
After installing the files, you have to check and edit some config files for camilladsp. The ones in use initially are placed in the sub-folder /home/tc/camilladsp/normal.
You also have to do is make sure you have a proper configuration for squeezelite done and saved with pCP's web interface. My start script depends on that.
Then run the script as root:
It will start a pyhon daemon to handle sample rate switching, and then start squeezelite withe its output "hard-coaded" to stdout, piped to camilladsp stdin.
Camilladsp log is at /var/log/camilladsp.log.
No log for squeezelite at the moment (coming feature...)
You can easily select a different set of config files for camilladsp, placed in any of the sub-folders in /home/tc/camilladsp, by running the script:
it will redirect all the symbolic links at /home/tc/camilladsp/*.yml to selected folder, and tell camilladsp to reload its config with a SIGHUP signal. The shift is almost instant and seamless...
There is so much to tell... please ask.
I have put everything you need to test on a working pCP device in a tar file. Including camilladsp v0.4.0-beta-4 and some of my .yml config files to help getting started. It should be possible to run this setup without interfering with Jesper's (lykkedk) setup, in the same mashine. Just make sure you stop both squeezelite and camilladsp before you try to start up my setup.
Installation is easiest if you unpack my .tar file with the path directed to the file root "/" with the "-C /" option. The .tar file can be saved anywhere, and the unpacked files will end up at the right places, with ownership and permissions allreadt set.
It will create a new folder at: /home/tc/camilladsp and put some config files there. If you already have a folder with that name - rename or move it first. Another new folder will be created at: /opt/camilladsp with the executable files.
Code:
tar -xvf cdsp-setup.tar -C /After installing the files, you have to check and edit some config files for camilladsp. The ones in use initially are placed in the sub-folder /home/tc/camilladsp/normal.
You also have to do is make sure you have a proper configuration for squeezelite done and saved with pCP's web interface. My start script depends on that.
Then run the script as root:
Code:
sudo /opt/camilladsp/cdsp-squeezelite.sh startCamilladsp log is at /var/log/camilladsp.log.
No log for squeezelite at the moment (coming feature...)
You can easily select a different set of config files for camilladsp, placed in any of the sub-folders in /home/tc/camilladsp, by running the script:
Code:
/opt/camilladsp/select-config.sh [folder-name]There is so much to tell... please ask.
There is one particular issue I'd like anyone who test this should look for.
In my previous lykkedk-setup, I had log output from camilladsp showing a "set capture rate" close to 100%:
Now with my piped setup I only get 98.6 - 98.7%..?:
I saw this recently, and can't really tell if it changed wit the new setup, or it happened at some other point.
The funny thing is that when I first tested this new setup, I frequently double-checked the sample rate display on my DAC, after starting a new track with a new sample rate. It just didn't feel right - it felt to slow... But it never was.
Does Henrik, or anyone else, have any ideas of a reason for this..?
In my previous lykkedk-setup, I had log output from camilladsp showing a "set capture rate" close to 100%:
Code:
[2020-10-18T17:37:52Z DEBUG camillalib::audiodevice] Current buffer level 2050.5555555555557, set capture rate to 99.99954648526077%
Code:
[2020-10-21T15:53:55Z DEBUG camillalib::audiodevice] Current buffer level 31862.185185185186, set capture rate to 98.65816326530611%The funny thing is that when I first tested this new setup, I frequently double-checked the sample rate display on my DAC, after starting a new track with a new sample rate. It just didn't feel right - it felt to slow... But it never was.
Does Henrik, or anyone else, have any ideas of a reason for this..?
If you are piping the sound to CamillaDSP, then you don't want to have rate adjust enabled! Just disable it, it's not needed. Camilla will read samples as fast as needed to feed the playback device (since you have queuelimit=1).
BTW I'll change the default queuelimit to a small value. The large limit is causing trouble, and is usually not useful anyway..
BTW I'll change the default queuelimit to a small value. The large limit is causing trouble, and is usually not useful anyway..
Thank you Henrik! That works.
With no log posts about speed, listening will have to tell if there is a difference...
And listening is such a great fun now..!
Finally... Back on track..!
After a long session of hard work - Sitting in my sofa, leaning back with my eyes shut - Carefully listening...
(No - not with earphones...)
No more issues with the sound!
I guess it was Henrik's advice that made the difference. My suspicions aimed at the power supply for my Rpi + USB-powered DAC, was probably just a random coincident. In the process, I realized that I need to beef up my old wifi router to play hi-res audio > 96kHz without gliches.
After a long session of hard work - Sitting in my sofa, leaning back with my eyes shut - Carefully listening...
(No - not with earphones...)
No more issues with the sound!
I guess it was Henrik's advice that made the difference. My suspicions aimed at the power supply for my Rpi + USB-powered DAC, was probably just a random coincident. In the process, I realized that I need to beef up my old wifi router to play hi-res audio > 96kHz without gliches.
Hey here...
I'am trying to get your'e setup running pi r, but i had some difficulties to understand why i cannot make it work? - I'am some confused don't understand why i cannot figure this out
Quistions are for a start. - More to come proberly, but a small step at a time now for me
1. I have to start camilladsp myself right?
2. pCP must be configured in the webinterface, and then you force the output to stdout,
how must pCP be configured ?
Jesper.
I'am trying to get your'e setup running pi r, but i had some difficulties to understand why i cannot make it work? - I'am some confused don't understand why i cannot figure this out
Quistions are for a start. - More to come proberly, but a small step at a time now for me
1. I have to start camilladsp myself right?
2. pCP must be configured in the webinterface, and then you force the output to stdout,
how must pCP be configured ?
Jesper.