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

Jump to Latest
#121
🙂Hey guy's...

I installed the excellent samplerate switching way on my main stereo yesterday and me and my son took a listning (along with some beer's :sing::xmasman::faint:) comparing it with the old installation i had before.
The good thing with the new way is that there are no longer any pops and click's when samplerate change, otherwise we couldn't hear any difference (which i didn't expect either)... This new solution is brilliant! thanks @pi r.

@Henrik, regarding integrating it into the pCP i had this in my mind for some time, and i proberly will contact one of the developers there. (maybee some will even see this post???)
But until then i will do it this way.

@pi r, I am doing some small rewriting of the script's, i will send them to you so we can discuss it before they are released here or anywhere at all.!? Okay?
[EDIT] pi r, btw. Is it possible that you can rewrite some of the script's and repack it so that it is located in /home/tc/DSP_Engine instead of /home/tc/camilladsp... ? Please 🙂

There was a comment that the graphical (matplotlib+numpy) was a must in the webinterface, but i also find it very usefull without the plotting.
I attached a picture here, where it clearly shows that my filters are used in the correct location on the directory structure 🙂

Jesper.
 

Attachments

  • GUI_Screenshot_1.png
    GUI_Screenshot_1.png
    85.9 KB · Views: 223
Last edited:
#122
I'm not using RPi, so I'm not intending to use https://www.diyaudio.com/forums/att...lerate-auto-switching-machine-cdsp-setup3-zip as it is.

Just so that I'm on the same page, basically the solution is now to read squeezelite's logs from a named pipe and change config file for camilladsp, according to the new samplerate read from the log?

No changes to squeezelite?

Are there any restarting of squeezelite or camilladsp involved or does it just work when the config for camilladsp is changed through the websocket?
 
Last edited:
#123
...and of course, squeezelite plays to stdout ("-o -") and camilladsp is configured to capture from stdin and play to sound_out, with this content in asound.conf:

Code: 
pcm.sound_out {
type hw
card 0
device 0
}

ctl.sound_out {
type hw
card 0
}
Correct?
 
#124
Audiac;

I'am pretty sure you are correct in all phrases 🙂

You use same asound.conf as i do.
Are there any restarting of squeezelite or camilladsp involved or does it just work when the config for camilladsp is changed through the websocket?
Click to expand...
This is only thing where i'am not 100% sure, but it's prroberly right what you write!

You can also remove (you proberly know) snd_aloop module.
And yes we use plain vanilla squeezelite now 🙂

Jesper.
 
#125
@ Henrik:
Maybe I should take a look into how to make a piCore tce-packet for installing this. Then it might get adopted...
"Supporting SqueezeCore?" - I don't know if I missed something but... using x86 architecture to run squeezelite in a 17 MByte OS..? From a global warming perspective... that wouldn't be my choise. Simofil is of course free to use whatever he likes from here.

@ wineds:
pcp.cfg contains a lot of junk not related to squeezelite, but I guess you easily can clean that out. This one has a pretty basic config...

@ Jesper:
It was kind of on purpose I moved around and changed some names... And not just not to avoid interfering with your setup I had on the same device. I like to at least try to follow the conventions for naming and placing things. I'm certainly not an expert on the subject though... and there are always compromises to consider. So suggestions are always welcome. 🙂
My comment about usefulness of the GUI without graphs was strictly my personal thoughts. I would certainly appreciate the GUI without in some situations. I just don't expect to encounter those situations soon, to take the effort of instlalling.
 

Attachments

#127
Obviously I'm late to present a description of the setup I have here.

It is mostly based on audiac's suggested "second approach" and example code, for making automatic sample rate switching with squeezelite and CamillaDSP. Thanks to audiac's persistence in pointing the direction, I eventually realized that hes concept could be implemented without hacking squeezelite, as lykkedk did in the start of this thread.

This is how it works:

The problem:
CamillaDSP needs to load a new config file whenever the sample rate at its input changes, and can't do that by itself.

The solution:

  • We hijack the log output from squeezelite, and sends it to a "named pipe".
  • A Python daemon reads the log messages from the pipe,
    finds and extracts the sample rate of a new track to be played.
  • Based on which sample rate, the daemon sends a message to CamillaDSP
    though a websocket call, containing the name of the config file to load.
(A named pipe is a "trick" to make a pipe look like a file, that can be read in real time by another program. Just as with a "normal" pipe, like: ps | grep camilladsp)

My setup also relies on a connection between squeezelite and CamillaDSP using stdout | stdin. Another pipe...
The alsa loopback device from lykkedk's setup didn't work if used with a non-hacked squeezelite (my goal). Which was a good thing. It made me look for the very superior piped alternative. A direct connection without involving alsa at all...
But that isn't quite compatible with the pCP start and stop method for squeezelite. - So I had to make my own (partly based om pCP's code).
All configurations for squeezelite can (should) still be made with pCP's web interface. There are two limitations:

  • Output option "-o" is ignored. It's hard-coded to stdout, "-o -" in my start script.
  • The log level settings is limited to: "none", "all=|*|" or "output=|*|"
    (info, debug and sdebug as selected)"
    Any other selected level gets converted to "all=|*|".
Don't try to manipulate the log options in the "Various Options" box. It won't work... And be careful with other exotic manipulations there.

Both squeezelite and CamillaDSP must be started by my script: /opt/camilladsp/cdsp-squeezelite.sh
And: pCP must be configured NOT to start squeezelite on boot.


CamillaDSP *.yml config files capture section should look like this:
Code: 
  capture:
    type: File
    channels: 2
    filename: /dev/stdin
    format: S32LE
There is no need to edit /etc/asound.conf
...if you set playback section something like this:
Code: 
  playback:
    type: Alsa
    channels: 2
    device: "hw:1,0"
    format: S24LE3
Provided you haven't disabled the Rpi internal DAC:
"hw:0,0" will use the Rpi 3.5 mm socket output.
"hw:1,0" is for a USB DAC.
"format" as your DAC can handle...

I still consider this under development - alpha-3. :magnify:
/Pierre
 
Last edited:
#128
EDIT :: (I posted at same time as pi r.) Very good explanation of the setup Pierre.

@ Jesper:
It was kind of on purpose I moved around and changed some names... And not just not to avoid interfering with your setup I had on the same device. I like to at least try to follow the conventions for naming and placing things. I'm certainly not an expert on the subject though... and there are always compromises to consider. So suggestions are always welcome. 🙂
My comment about usefulness of the GUI without graphs was strictly my personal thoughts. I would certainly appreciate the GUI without in some situations. I just don't expect to encounter those situations soon, to take the effort of instlalling.
Click to expand...

Hey pi r... I sort of regret i posted about changing the directory structure, so nevermind that.
I can see that Greg (one of the piCore guy's) posted that they are willing to apply an extension(.tcz's) or two 🙂... So this is great news, thank's Greg.
We have to pack everything up in .tcz's pi r, and try it out and figure out how the configuration must be set up (including the webinterface in pCP perhap's?)

Jesper.
 
Last edited:
#131
Thank you pi r and lykkedk for your explainations, clarifications and efforts! I have had all sorts of problems, but I think it works now (almost). I consider the fact that I have no sound to be just a minor issue. I think VirtualBox is to blame this time. The hwparams of the virtual sound card looks ok, so hopefully it is just a glitch between the guest and the host. I can live with that until I test on my main system.
 
#133
pi r said:
Did you create the two python module tcz's: py_websocket.tcz and py_six.tcz, at your GitHub? I.e. Do you know how..?
Click to expand...

Yes, i compiled them and created the .tcz... They are needed for using the websocket function in Camilladsp.

In chaptor 14 in this good book, you can see how .tcz's are made. (It's a bit like packing things up in e.g. .tar)

http://tinycorelinux.net/corebook.pdf

.Tcz's are better to use if there are something which are readonly (could be e.g. camilladsp)
etc... etc...

Jesper.
 
#134
Earlier today, I made a fresh install from a new pCP image.
I had some issues...

My zip/tar file "cdsp-setup3.tar" has some strange owner and permissions error. All symbolic links (owned by root) has permissions "777". Still, user tc is not allowed to alter those links. This might be a problem of the limited tar version supplied by BusyBox. I'll investigate... :scratch1:

There was also a problem with my start script: /opt/camilladsp/cdsp-squeezelite.sh
If I tried to start without setting a logging option -l or -v, I got the error message "Invalid option". It works with either option.
Needs a fix... 😡

Apart from that it went along very smooth.
I did really minimal changes to squeezelite's setup (with USB DAC connected). Just this:

  • Audio output device settings: Set USB audio output + reboot
  • Output setting: hw:CARD=ALSA,DEV=0 (for internal DAC)
  • Set player name
  • Set LMS IP
Then I had to edit camilladsp/44100.yml to set the playback section to:
Code: 
  playback:
    type: Alsa
    channels: 2
    device: "hw:0,0"
    format: S16LE
Then start: /opt/camilladsp/cdsp-squeezelite.sh start -l
And then: Rock-And-Roll in my speakers...

Modifying camilladsp/44100.yml to set the playback to "hw:1,0" for my USB DAC
Then restart: /opt/camilladsp/cdsp-squeezelite.sh restart -l
Again: Rock-And-Roll in my speakers... 😎
 
#135
pi r; you are good!

http://tinycorelinux.net/corebook.pdf

Read chapter 14, 15 & 16 also regarding permission's.
I think maybe we can fix those permissions problems by using a .tcz

Even if we create an .tcz which are packed out in home & opt, which are persistant anyway, we don't have to use it onboot afterwards (hope you understand?)

Alternatively a script can set the right owner & permissions after things are packed out!
A script is also possible to attach an .tcz, which are ran after the .tcz are unsquashed 🙂

Btw.: I changed the /opt/camilladsp/select-config.sh script a little so that it now removes all letter's in e.g an Avg_special_filter_44100.yml file. So nomatter what you call your'e .yml the script allways links with the right file name e.g :

Code: 
tc@piCorePlayer:~/DSP_Engine$ sudo /opt/camilladsp/select-config.sh filters

Setting CamillaDSP configuration to: filters
config comment:
  
  devices:
    samplerate: 44100
    chunksize: 4096

Creates or updates symbolic links in folder: /home/tc/DSP_Engine
  176400.yml -> filters/Avg_176400.yml
  192000.yml -> filters/Avg_192000.yml
  44100.yml -> filters/Avg_44100.yml
  48000.yml -> filters/Avg_48000.yml
  88200.yml -> filters/Avg_88200.yml
  96000.yml -> filters/Avg_96000.yml

Sending signal to CamillaDSP to apply configuration: filters

This is the code change :
Code: 
for f in $ConfigPATH/$ConfigFolder/*.yml ; do 
  if [ -f $f ] ; then
    if [ ! $Label ] ; then
      echo -e "\nSetting CamillaDSP configuration to: $ConfigFolder"
      if [ $ShowComment > 0 ] ; then
        echo "config comment:"
        echo "$(head -$ShowComment $ConfigPATH/$ConfigFolder/*44100.yml | sed -e 's/^/  /')"
      fi
      echo -e "\nCreates or updates symbolic links in folder: $ConfigPATH"
      Label=1
    fi
    File=`basename $f`

[COLOR="SeaGreen"]  RAW=$File                                         # RAW are grapping the present proceeded .yml name
  YML=$(echo $RAW | sed 's/[^0-9]*//g')             # Remove all letters from name and assign to variable YML
  YML_FILE=$YML".yml"                               # Add .yml to variable YML
[/COLOR]
    echo "  $YML_FILE -> $ConfigFolder/$File"       # Show symbolic links

 [COLOR="Green"] ln -sf $ConfigFolder/$File $ConfigPATH/$YML_FILE  # ln -sf [TARGET FILE] [Sym. LINK][/COLOR]
  else
    echo -e "-----\nError - There are no config files (*.yml) in folder: '$ConfigPATH/$ConfigFolder'"
    exit 1
  fi
done

I ofcause also changed the ConfigPATH="/home/tc/DSP_Engine" for it to work on my setup...

Jesper.
 
Last edited:
#136
Ideally /home/tc and /opt should only contain config files (non static files).

Whenever you do a pCP save or backup all this stuff is backed up into mydata.tgz.

We are guilty of doing this, but are gradually undoing it. You will note WWWROOT is not longer in /home/tc.

The other guys do all the packaging, so I am not the expert here. I am the one who puts stuff in the wrong place.
 
Last edited:
#137
I think you should create a main extension, maybe camilladsp.tcz

Then create camilladsp.dep with the required extensions.

So camilladsp.dep would look like this.

Code: 
nano.tcz
python3.6.tcz
py_websocket.tcz
py_six.tcz

When all the extensions are in the one repository doing a

Code: 
$ tce-load -iw camilladsp.tcz

will load all the required extensions and add camilladsp.tcz to onboot.lst

Note: nano could be removed from the dep file and made a ondemand extension.
 
#138
Hello.

@Greg so to confirm the files should be unsqueezed to the folowing locations:

Camilladsp --> /usr/local/bin
Sample-rate-daemon (Python) --> /usr/local/bin (or do you prefer other location for Python scripts?)
Select-config.sh --> /usr/local/bin ?

Then the start-script should be "integrated" in pCP somehow.

The basic configfiles should be unsqueesed to /home/tc/camilladsp as a "one shoot" .tcz, where the .tcz checks if the files are already there (script should look for /home/tc/camilladsp directory)

This gives a camilladsp.tcz with the deps like this or so :
Python3.6.tcz
Py_websocket.tcz
Py_six.tcz
Sample-rate-daemon.tcz
Select-config.tcz
Basic-config-files.tcz (as one shoot install)
Camilladsp.tcz

I suppose that all files located outside home and opt should have only root access? Like root:staff ? All files in home & opt are tc:staff ?

What do we forget here ? 🙂

Jesper.
 
#139
Integrating our start script in the main pCP ditto would be a major change, and should be avoided at this stage.

We only need to find a way for the user to control if it should launch on boot. That could be done the on the "Tweaks" web -page, by adding a "User command".
(Hmm... we should do it that way now too)
 
#140
@ Jesper:
Your change in select-config.sh don't work if you happen to have numbers in the name prefix, like: "test-3_44100.yml".
The result will be: 344100.yml

Try this:
Code: 
    Link=`echo $f  | egrep -o '[0-9]{4,6}\.yml$'

    echo "  $YML_FILE -> $ConfigFolder/$File"       # Show symbolic links

  ln -sf $ConfigFolder/$File $ConfigPATH/$Link  # ln -sf [TARGET FILE] [Sym. LINK]
I had some thought about doing this, but I didn't want to create "unnecessary" restraints. I think there might be situations where having a parallel set of .yml files in ~/camilladsp/ could be useful. The price for that flexibillity is having to strip the filenames on my old config files. But that was a one time fix... Write a script to do the job if you have "too many" files. 🙂

If you're up to hacking... Fix the printing of the "comment", so that it only prints lines that start with a #, if there is any. And maybe all initial lines with a #, in stead of a fixed number of lines... (I realized when I saw your output...)
 
You must log in or register to reply here.
Top Bottom