SuperPlayer - The DSP_Engine (CamillaDSP) samplerate switching & ESP32 remote control

Jump to Latest
P

pi r

Member
Joined 2014
I almost got it working. It's close...

It builds without errors, but at my first test it didn't accept my extra option.

But... Just when I succeeded to build, I realized that using an option is not a good idea at all. - It can't be started by cPC. Unless we also hack their web-gui. :headbash:

Back to the drawing table...
 
lykkedk

lykkedk

Member
Joined 2002
p ir; it's not a problem getting the custom to run inside and from pCP webinterface!

797 root 0:13 /home/tc/DSP_Engine/camilladsp -p3011 /home/tc/camilladsp/config/44100.yml
846 root 0:00 [kworker/3:2-eve]
855 root 0:00 /sbin/udhcpc -b -i eth0 -x hostname:piCorePlayer -p /var/run/udhcpc.eth0.pid
1385 root 0:00 /usr/local/sbin/sshd
1452 root 0:00 /usr/sbin/httpd -p 80
1606 root 0:00 sshd: tc [priv]
2949 tc 0:00 sshd: tc@pts/0
2969 tc 0:00 -sh
6851 root 0:00 [kworker/1:2-mm_]
8177 tc 0:14 /usr/local/bin/python3 /home/tc/DSP_Engine/camillagui/main.py
8568 root 0:00 /mnt/mmcblk0p2/tce/squeezelite-custom -n SuperPlayer_upgrade -o squeeze -a 80 4 1 -b 10000 20000 -r 44100 192000 2500 -s 192.168.1.29 -U -U -J
8974 tc 0:00 ps aux
Click to expand...

There is a box named [Various Options] in squeezelite settings page...
It's working as you can see (i just named my option -J)

Jesper.
 
A

audiac

Member
Joined 2020
Regarding more changes to the modified squeezelite (e.g. config file and a path to the python script as an argument), it is doable of course. But, I regard modifying someone else's code as the least desirable way to deal with the problem. The more changes you do, the more work you'll have adding your changes each time squeezelite is updated upstreams.

If I would follow the path of upgrading squeezelite, I would probably try the second approach as described in https://www.diyaudio.com/forums/pc-...crossovers-correction-etc-72.html#post6317469 (squeezelite_sample_rate.pdf). I think that this approach will lead to less hacking in squeezelite. The path to the named pipe is given as an argument to squeezelite, which it already supports.

As I see it, any of the following approaches are better:

  • Make the developers of squeezelite accept a pull request with the changes you want to do. Then the developers will maintain the code, with the help of any of you that want to participate. If I remember correctly, there has been some communication with the developers of squeezelite.

  • Write a plugin that does the job for you, so that a modifying squeezelite is not required. I'm assuming that the problem can be solved with a plugin.


The latter approaches are generic, i.e. not closely bound to any player. That suits me the best, because I use more players than squeezelite. I will put my efforts into a generic solution.
 
lykkedk

lykkedk

Member
Joined 2002
Regarding more changes to the modified squeezelite (e.g. config file and a path to the python script as an argument), it is doable of course. But, I regard modifying someone else's code as the least desirable way to deal with the problem. The more changes you do, the more work you'll have adding your changes each time squeezelite is updated upstreams.

If I would follow the path of upgrading squeezelite, I would probably try the second approach as described in https://www.diyaudio.com/forums/pc-b...ml#post6317469 (squeezelite_sample_rate.pdf). I think that this approach will lead to less hacking in squeezelite. The path to the named pipe is given as an argument to squeezelite, which it already supports.

As I see it, any of the following approaches are better:

Make the developers of squeezelite accept a pull request with the changes you want to do. Then the developers will maintain the code, with the help of any of you that want to participate. If I remember correctly, there has been some communication with the developers of squeezelite.

Write a plugin that does the job for you, so that a modifying squeezelite is not required. I'm assuming that the problem can be solved with a plugin.

Solve the problem in another part of the audio chain. Both seashell and HenrikEnquist suggest ways to do it. Se for example ALSA pcm hw_params hook (Loopback Notify Kludge) and CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc..


The latter approaches are generic, i.e. not closely bound to any player. That suits me the best, because I use more players than squeezelite. I will put my efforts into a generic solution.
Click to expand...

Thank's for chiming in here audiac :) appreciate it.

I actually agree with you, and the part where we request an option for the real squeezelite so to avoid any maintance ourself is the best option. The second approach you did in the .pdf are also a very nice idea (haven't tried it through)... I did not see this before now sry...

The idea of using an plugin was my first idea, but i needed squeezelite to tell me when samplerate changed, and at that time i was not able to accomplish this :eek:
- My idea back then was to let some python read an squeezelite samplerate output file somewhere, but i coulden't find it.

If i was an better programmer (or say programmer at all ;)) I would make an pull request to Ralph's squeezelite, but i'am not capable of writing that code now.

Thank's :)

Jesper.
 
P

pi r

Member
Joined 2014
Aggh.. Why do I never read a text to the end..? :headbash:

audiac's second approach "kind of works" - Out of the box - With the default squeezelite - No modifications...

It's only that camilladsp dies when receiving the websocket call.
My guess it's a timing issue. camilladsp tends to die when alsa is not prepared to receive data.
 
lykkedk

lykkedk

Member
Joined 2002
Pi r...

Did you do any progress in the other solution with the option to start squeezelite with an e.g -J /path/to/configdir solution?

Maybe we can in time make the code right and do a pull request to the real squeezelite???

Still think could be fun to have that work!

Jesper.
 
A

audiac

Member
Joined 2020
pi r said:
@ audioac:


In your pdf you mentioned the need to add a UNLOCK command to squeezelite, for this to work. Seems odd as the log line we are watching for, is a standard message in the log..?
Click to expand...


As I wrote I haven't been able to get it working myself. I just assumed that UNLOCK was necessary because it was added in the original hack. Yes, the script is watching for a standard log message.


I have been messing around with seashell's and HenrikEnquist's approaches today, but no luck there either.
 
P

pi r

Member
Joined 2014
I switched to the new, smoking hot, camilladsp v0.4.0 beta 4.
It can now use the -w option to wait for config at start, and use websocket calls to (re)load. It also means that it won't die when connection is lost.

Very convenient right now - Thank you Henrik..! - what a tremendous timing..!

So camilladsp looses its connection to squeezelite when switching sample rate. The old version died. The new version continues, waiting for a new config (with its output connected to the DAC @96k). And when starting a track @ 44.1k it gets a new config, reloads, reconnects, and start playing again... :eek:

I run test sequence and tracked both logs from camilladsp and squeezelite (standard):

  1. Start a 44.1k track
  2. Start a 96k track
  3. Start another 96k track
  4. Start another 96k track
  5. Start a 44.1k track
  6. stop
This is from camilladsp's log when 96k track starts and connection to squeezelite is lost:
Code: 
/.../
[2020-10-18T12:32:27Z DEBUG camillalib::biquad] a1=-1.9996452186167575 a2=0.9996559259709864 b0=1.0002601004279503 b1=-1.9996452186167575 b2=0.9993958255430361
[2020-10-18T12:32:27Z DEBUG camillalib::biquad] a1=-1.9997461331309943 a2=0.9997602451281226 b0=1.0001743867748498 b1=-1.9997461331309943 b2=0.9995858583532731
[2020-10-18T12:32:27Z ERROR camilladsp] Capture error: ALSA function 'snd_pcm_hw_params_set_rate' failed with error 'EINVAL: Invalid argument'
[2020-10-18T12:32:27Z DEBUG camilladsp] Error while starting, release barrier
[2020-10-18T12:32:27Z DEBUG camillalib::biquad] a1=-1.9998199311761358 a2=0.9998354541154326 b0=1.0002452615403732 b1=-1.9998199311761358 b2=0.9995901925750594
[2020-10-18T12:32:27Z DEBUG camillalib::biquad] a1=-1.9992912257404656 a2=0.9993116132983456 b0=0.9998060524961605 b1=-1.9992912257404656 b2=0.9995055608021849
/.../
[2020-10-18T12:32:27Z ERROR camillalib::processing] Message channel error: receiving on a closed channel
[2020-10-18T12:32:27Z DEBUG camilladsp] Wait for playback thread to exit..
[2020-10-18T12:32:27Z DEBUG camilladsp] Restarting with new config
[2020-10-18T12:32:27Z DEBUG camilladsp] Wait for config
/.../
This is when reconnecting:
Code: 
/.../
[2020-10-18T12:33:25Z DEBUG camillalib::biquad] a1=-1.9966222655576924 a2=0.9970905616389267 b0=1.0026452365276706 b1=-1.9966222655576924 b2=0.9944453251112559
[2020-10-18T12:33:25Z DEBUG camillalib::biquad] a1=-1.9919533668942897 a2=0.9925309441240469 b0=0.9974601083778034 b1=-1.9919533668942897 b2=0.9950708357462436
[2020-10-18T12:33:25Z DEBUG camillalib::alsadevice] Opened audio device "camilla_in" with parameters: HwParams { channels: Ok(2), rate: "Ok(44100) Hz", format: Ok(S32LE), access: Ok(RWInterleaved), period_size: "Ok(2048) frames", buffer_size: "Ok(16384) frames" }, SwParams(avail_min: Ok(2048) frames, start_threshold: Ok(0) frames, stop_threshold: Ok(16384) frames)
[2020-10-18T12:33:25Z DEBUG camillalib::biquad] a1=-1.9410675609260504 a2=0.9419052035475628 b0=0.4688144643185656 b1=-0.8972876351406528 b2=0.42931081344359984
[2020-10-18T12:33:25Z DEBUG camilladsp] Capture thread ready to start
[2020-10-18T12:33:25Z DEBUG camillalib::biquad] a1=-1.9935593194571966 a2=0.995192426961647 b0=1.0043710043768739 b1=-1.9935593194571966 b2=0.9908214225847731
[2020-10-18T12:33:25Z DEBUG camillalib::biquad] a1=-1.962345347305777 a2=0.9640447919081228 b0=0.9869171605592597 b1=-1.962345347305777 b2=0.9771276313488629
  /.../
Nothing happens when the folowing 96k tracks are started...

How do we avoid disconnection? Anyone..?
I tested delaying the websocket command to camilladsp - No good. So maybe it's too late, but the timing shouldn't be that much different from with our modified squeezelite-custom?
 
Last edited:
lykkedk

lykkedk

Member
Joined 2002
Hi... all fighter's :)

Well, i tested different.

I also did install the newest camilladsp and started it with the -w option; now camilladsp dosen't crash anymore as you also see pi r!

I started a plain original :D squeezelite with no hacks.

Case is that nomatter what, as long as squeezelite is started camilladsp dosent (re)start, she just waits until squeezelite is stopped and a new config is loaded on her :)

So i guess that we must do this :

  • killall squeezelite-custom
  • SEND new config to camilladsp, which is waiting [-w]
  • Start squeezelite again

Jesper.

tc@piCorePlayer:~$ /home/tc/DSP_Engine/camilladsp -w -p3011 /home/tc/camilladsp/config/44100.yml
Buffer frames 8192
[2020-10-18T17:18:00Z INFO camillalib::alsadevice] Capture device supports rate adjust
[2020-10-18T17:18:00Z INFO camillalib::alsadevice] Starting playback from Prepared state
Buffer frames 16384
[2020-10-18T17:55:45Z ERROR camilladsp] Capture error: ALSA function 'snd_pcm_hw_params_set_rate' failed with error 'EINVAL: Invalid argument'
[2020-10-18T17:55:45Z ERROR camillalib::processing] Message channel error: receiving on a closed channel

Buffer frames 16384
[2020-10-18T17:56:31Z INFO camillalib::alsadevice] Capture device supports rate adjust
[2020-10-18T17:56:32Z INFO camillalib::alsadevice] Starting playback from Prepared state
Buffer frames 8192
[2020-10-18T17:57:50Z ERROR camilladsp] Capture error: ALSA function 'snd_pcm_hw_params_set_rate' failed with error 'EINVAL: Invalid argument'
[2020-10-18T17:57:51Z ERROR camillalib::processing] Message channel error: receiving on a closed channel
Buffer frames 8192
[2020-10-18T17:58:04Z INFO camillalib::alsadevice] Capture device supports rate adjust
[2020-10-18T17:58:04Z INFO camillalib::alsadevice] Starting playback from Prepared state
Buffer frames 16384
[2020-10-18T17:58:38Z INFO camillalib::alsadevice] Capture device supports rate adjust
[2020-10-18T17:58:38Z INFO camillalib::alsadevice] Starting playback from Prepared state
Click to expand...
 
P

pi r

Member
Joined 2014
lykkedk said:
/.../
So i guess that we must do this :

  • killall squeezelite-custom
  • SEND new config to camilladsp, which is waiting [-w]
  • Start squeezelite again
Jesper.
Click to expand...


In my previous test, after starting a track at 96k, that didn't play, I tried to send a new config to camilladsp by manually running: "update-config.py [rate]" with 96k and 44.1k back and forth - Didn't work. I never tried to restart squeezelite though.


I sorted my setup, and here are a similar test as my last post. But now with the working setup with audiac's and my squeezelite-custom and update-config.py. CamillaDSP log is clean as expected, but there are some interesting differences in squeezelites log when shifting to 96k:

Not working - standard squeezelite (from previous test):
Code: 
[14:32:26.966490] _output_frames:86 pause 2204 frames
[14:32:27.006218] _output_frames:86 pause 440 frames
[14:32:27.046229] _output_frames:86 pause 0 frames
[14:32:27.046357] _output_frames:149 track start sample rate: 96000 replay_gain: 0
[14:32:27.056506] output_thread:687 open output device: squeeze
[14:32:27.056875] alsa_open:351 opening device at: 96000
cmd: /home/tc/camilladsp/update_config.py 96000


[14:32:27.058033] alsa_open:422 opened device squeeze using format: S32_LE sample rate: 96000 mmap: 1
[14:32:27.058205] alsa_open:513 buffer: 160 period: 4 -> buffer size: 7056 period size: 1764
[14:32:27.058810] _output_frames:86 pause 120000 frames
[14:32:27.059813] _output_frames:86 pause 117952 frames
[14:32:27.060474] _output_frames:86 pause 115904 frames
Working squeezelite-custom (new test):
Code: 
[19:37:26.076175] _output_frames:86 pause 3060 frames
 [19:37:26.116193] _output_frames:86 pause 1296 frames
[19:37:26.156245] _output_frames:86 pause 0 frames
[19:37:26.156365] _output_frames:149 track start sample rate: 96000 replay_gain: 0
[19:37:26.166441] output_thread:718 open output device: squeeze
[19:37:26.166715] alsa_open:362 opening device at: 96000
[19:37:26.166750] alsa_open:367 Player detected sample rate change ! 96000
[19:37:26.860529] alsa_open:375 Sample rate changed to 96000
[19:37:26.861045] alsa_open:453 opened device squeeze using format: S32_LE sample rate: 96000 mmap: 1
[19:37:26.861115] alsa_open:544 buffer: 160 period: 4 -> buffer size: 7056 period size: 1764
[19:37:26.861365] alsa_open:362 opening device at: 96000
[19:37:26.861384] alsa_open:367 Player detected sample rate change ! 96000
[19:37:27.548582] alsa_open:375 Sample rate changed to 96000
[19:37:27.549098] alsa_open:453 opened device squeeze using format: S32_LE sample rate: 96000 mmap: 1
[19:37:27.549197] alsa_open:544 buffer: 160 period: 4 -> buffer size: 15360 period size: 3840
[19:37:27.549446] _output_frames:86 pause 120000 frames
[19:37:27.549571] _output_frames:86 pause 117952 frames
[19:37:27.549690] _output_frames:86 pause 115904 frames
This is cut from the two logs at the same location. The extra lines in the later "working" output, comes from our hack. But the rate change only executes once in the first standard squeezelite, compared to twice in our squeezelite-custom.
And you changed that, Jesper, didn't you..? But I thought you changed it the other way around..? :confused:
My DAC worked at all sample rates with pCP before all this hacking. Is it the loopback device that needs dual settings?
 

Attachments

  • test-5-camilla.log.txt
    115.5 KB · Views: 79
  • test-5-squeeze.log.txt
    13.7 KB · Views: 84
You must log in or register to reply here.
Top Bottom