Sample rate switcher for CamillaDSP

Jump to Latest
M

mevang

Member
Joined 2004
Frunse said:
Would be the camilladsp-saterate the right tool to switch automaticly to any incomming samplefrequenz on I2S ???
Click to expand...
I actually carried out testing of camilladsp-setrate in a single simple context, and i cannot setup other test beds. Therefore I'm sorry I can't give you an answer.
However, please note that camilladsp-setrate gets sample rate change information from the alsa sound system. Your HDMI-to-I2S device shall be supported by alsa and its driver shall provide the required information, which may not be the case for some alsa-supported devices.
It is not difficult to build and install camilladsp-setrate, so I encourage you to do your own experiments, and let us know the results.

Concerning sample rate conversion, please note that camilladsp-setrate allows resampling to a fixed rate by using the --capture flag on the command line.
I am also about to release version 2.1, which adds the ability to upsample incoming audio by a fixed rate (e.g. 2X, 4X, ...).
 
Last edited:
  • Like
Reactions: 1 user
M

mevang

Member
Joined 2004
I have just uploaded camilladsp-setrate v2.1.0 to github:
https://github.com/marcoevang/camilladsp-setrate

This version adds the --upsampling command option to achieve upsampling by a fixed integer factor (e.g. 2X or 4X) regardless of the sample rate of the incoming audio. Make sure your playback device supports the resulting upsampled rate.
It is up to the user to enable resampling in the configuration file.

Please read the CHANGELOG.md and README.md files.
 
  • Like
Reactions: 1 user
T

TerryForsythe

Member
Joined 2012
My setup is WiiM --> miniDSP MCHStreamer kit input --> Raspberry Pi 5 --> miniDSP MCHStreamer kit output --> DAC. The miniDSP MCHStreamer kit connects to the Raspberry Pi via USB, connects to the WiiM via the TosLink input, and connects to the DAC via the Toslink output.

When I execute the command camilladsp-setrate -d hw:TosLink, I receive the following error:
E: WAIT_RATE_CHANGE: Callback: Connection to localhost:1234 failed: HS: Rejected at CLIENT_ESTABLISHED

I checked the port assigned to CamillaDSP with the netstat -ntlp command, and it outputs the following:
tcp 0 0 127.0.0.1:1234 0.0.0.0:* LISTEN 1054/camilladsp

So, it appears that CamillaDSP is using port 1234.

I reviewed the comments by DeBrow, who posted a similar error. In his case his device was not USB gadget compatible. Based on the error I am getting, I assume that also is the case for the MCHStreamer kit, but figured I would check before I give up on getting camilladsp-setrate working.

The OS on the Raspberry Pi is Ubuntu Server 23.10.

If anyone has some insight, please let me know.

Thank you!
 
M

mevang

Member
Joined 2004
TerryForsythe said:
My setup is WiiM --> miniDSP MCHStreamer kit input --> Raspberry Pi 5 --> miniDSP MCHStreamer kit output --> DAC. The miniDSP MCHStreamer kit connects to the Raspberry Pi via USB, connects to the WiiM via the TosLink input, and connects to the DAC via the Toslink output.
Click to expand...
I do not know the miniDSP MCHStreamer device, therefore I can't comment on this.
TerryForsythe said:
When I execute the command camilladsp-setrate -d hw:TosLink, I receive the following error:
E: WAIT_RATE_CHANGE: Callback: Connection to localhost:1234 failed: HS: Rejected at CLIENT_ESTABLISHED
Click to expand...
camilladsp_setrate attempts to connect to camilladsp websocket server before initialising alsa. Therefore, the blocking error does not concern audio devices, but the websocket connection.

Considering that your raspberry pi is running ubuntu, I suggest you take a look at posts #41, #42 and #43 in this thread.
Hope this helps.
 
M

mevang

Member
Joined 2004
You could ask @Cathul for details on how he solved the problem, assuming the cause is the same.
(I apologise for not being able to test camilladsp-setrate with libwebsockets19, but dietpi is still stuck at version 17).

Please also enable debug for camilladsp (camilladsp --loglevel debug). The log should contain information about the connection attempts by the camilladsp-setrate client.

If the error persists, I would suggest you do some tests to find out whether the problem is due to camilladsp-setrate or not. To this end you could install pycamilladsp https://github.com/HEnquist/pycamilladsp and then run the python script 'get_config' in the 'examples' folder (that script works with camilladsp v2).
Please let me know the results of these tests.
 
Last edited:
T

TerryForsythe

Member
Joined 2012
I have the camilladsp-setrate.service running without errors, but it is not actually changing the sample rate when the music stream changes.

I have Tidal HiFi. It appears to be sending some songs at 192k, some at 96k, some at 48k and some at 44.1k. But Camilladsp is not changing the sample rate when Tidal changes the sample rate.

If I manually select the correct configuration for the currently streamed sample rate in the CamillaDSP GUI, that is working.

Any advice would be greatly appreciated.
 
M

mevang

Member
Joined 2004
Please set the log level of camilladsp-setrate to 'notice'. Then check in the log file if the alsa sound system has been successfully initialised. If yes, any rate change should be tracked in the log file. If no rate change is detected, check the log for errors. Be sure that the capture device name is correct, both in camilladsp-setrate command line and camilladsp configuration file. And don't forget to prepend 'hw:' to the device name.
If everything looks correct, likely the toslink device driver does not provide information about the rate change. In this case, if you can, replace toslink with the USB gadget as capture device.
Just to be sure, post the output of the command arecord -l
 
Last edited:
T

TerryForsythe

Member
Joined 2012
Here are the log entries:

-- Boot e50d58dc7830463c94b329b31b49a802 --
Mar 20 18:01:46 dspserver systemd[1]: alsa-state.service - Manage Sound Card State (restore and store) was skipped because of an unmet condition check (ConditionPathExists=/etc/alsa/state-da>
Mar 20 18:01:46 dspserver systemd[1]: Starting alsa-restore.service - Save/Restore Sound Card State...
Mar 20 18:01:46 dspserver alsactl[741]: alsa-lib main.c:1541:(snd_use_case_mgr_open) error: failed to import hw:1 use case configuration -2
Mar 20 18:01:46 dspserver alsactl[741]: alsa-lib main.c:1541:(snd_use_case_mgr_open) error: failed to import hw:2 use case configuration -2
Mar 20 18:01:46 dspserver systemd[1]: Finished alsa-restore.service - Save/Restore Sound Card State.
lines 130-180/180 (END)


It looks like it is looking for /etc/alsa/state-da, but it is not there. Alsa is in the following directories:

/var/lib/alsa
/usr/share/alsa
/usr/share/sounds/alsa
usr/include/alsa

I did a recursive search for "state-da", but it came up empty. In /var/lib/alsa there is a file named "asound.state".
 
T

TerryForsythe

Member
Joined 2012
Thank you! According to the thread to which you posted the link:

"This file is a switch to choose between two schemes.
If it exists then the commands in 'alsa-state.service' will be used, otherwise the commands in 'alsa-(re)store.service' will be run."

Now, the question is do I need to use the alsa-state service or the alsa-restore service?

I'm guessing I need the alsa-state service, and can implement that by merely creating /etc/alsa/state-da as an empty document. Does anyone know whether this is correct?
 
P

phofman

Member
Joined 2005
IMO that log is shortened (/etc/alsa/state-da does not make any sense), the original was what's listed on that archlinux page:

Code: 
ConditionPathExists=/etc/alsa/state-daemon.conf was not met

IIUC that log is just an information, that the other path was taken.

I am afraid I do not understand what specific problem you encounter, but those logs seem harmless, just information. Not importing a use case should not be a problem, IMO it was not used in this setup.
 
You must log in or register to reply here.
Top Bottom