CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc

Jump to Latest
#5,342
The logs are from the java controller, not from the actual player (mpd?) which talks to the alsa device. Also this error does not seem to be related to the actual player:
Code: 
2025-01-05 01:04:50,480 [Thread-6] DEBUG [org.rpi.player.PlayManager] Set Next AV Track :
2025-01-05 01:04:50,480 [Thread-6] DEBUG [org.rpi.mpdplayer.MPDPlayer] PreLoad Next Track:
2025-01-05 01:04:50,480 [Thread-6] ERROR [org.rpi.radio.parsers.FileParser] java.net.MalformedURLException: no protocol:
2025-01-05 01:04:50,481 [Thread-6] ERROR [org.rpi.mpdplayer.TCPConnector] Error: ACK [50@0] {addid} No such song

Did you troubleshoot your chain by playing to the soundcard directly first, without the alsa_cdsp plugin? You chain has many layers and each needs to be tested first, adding one by one.
 
#5,343
HenrikEnquist said:
In most cases you will need an asynchronous resampler to synch clocks with the output device. It's mostly the output sample rate that affects the cpu usage of the asynchronous resampler, so starting from a very high rate isn't a problem.
Click to expand...
Ah, that is very good news to me.
Aliasing of input noise above samplerate/2 down into 20 to 20k would be a problem if the input samplerate and analog input filter is off. Eg analog filter cutof is to high compared to Fs. Here I mean noise, not signal from music.

Just for the ones interested in oversampling, decimation, and noise. This is a application note written for cheap MCUs with SAR ADCs but the principles is the same for all normal ADCs https://www.st.com/resource/en/appl...se-ratio-on-stm32-mcus-stmicroelectronics.pdf
 
#5,344
I now understand that constant samplerate is a requirement. But still i want to propose a solution to save the earth for some used watts.
The background is that the FIR filtering is a N squared prosess. So for example 1k quotient FIR is 10 000 more efficient than 100 k FIR.
I use the CISIS-DSP framework as building blocks but I thing the same i available for RUST. https://github.com/ARM-software/CMSIS-DSP.
I want to propose a 'Decimate -> FIR -> Interpolate' block where input SF = output SF and FIR filters needes are also related input/output SF.
First the components
https://arm-software.github.io/CMSIS-DSP/latest/group__FIR__decimate.html
https://arm-software.github.io/CMSIS-DSP/latest/group__FIR.html
https://arm-software.github.io/CMSIS-DSP/latest/group__FIR__Interpolate.html

Now we need tree FIR filters as input
The filter for the user with SF = input SF.​
The LP filter for the decimate with SF = input SF.​
The LP filter for the interpolate with SF = input SF.​
​
Possibly the two last filters can be the same filter.

This only works with the same integer desimation/interpolation value L and M. the integer value of L and M must also be a log(2) integer value. 2^x. So this restricts the lower limit of downsampling.

First the filter for the user must be downsampled to SF/L. 'The LP filter for the decimate with SF = input SF.' can be used.
This is the input to the internal FIR filter. User FIR internal. Can be calculated one one time.

So then the 'Decimate -> FIR -> Interpolate' block uses:
Desimate uses the 'The LP filter for the decimate with SF = input SF'. And the desimation value L​
FIR uses 'User FIR internal'​
Interpolate uses 'The LP filter for the interpolate with SF = input SF'. And the desimation value M. M = L​

This is very useful for bass or midrange FIR filtering with high frequency resolution.
Can even be used for tweeter FIR if FS >> 48k.

The ekstra input from the user in adition to the user FIR are:
L (= M) , log(2) integer value that result in an integer value when FS is devided with L.​
The LP filter for the decimate​
The LP filter for the interpolate​
 
#5,346
I noticed conversion clipping on some 44.1/16 bit to 96/24 bit songs. The album was a maroon5 and the signal level is quite high. The warning messages look like
WARN [src/conversions.rs:65] Clipping detected, 10 samples clipped, peak +0.89 dB (110.7%)
The devices section looks like
devices:
samplerate: 96000
chunksize: 16384
resampler:
type: Synchronous
enable_rate_adjust: true
capture_samplerate: 44100
capture:
type: File
channels: 2

filename: "/rabbitA/data/stage2/maroon01.wav"
skip_bytes: 144
format: S16LE
playback:
type: Alsa
channels: 18
format: S24LE3
device: hw:CARD=UltraLitemk5,DEV=0

I tried adding negative gain in the mixers section/sources subsection with no change. I could remove the clipping warns by running the data thru audacity and cutting the gain 3db and then regening the wave file in 44.1 and then running it thru camilla. Another thing I tried and worked was using audacity to cut the gain 6db (1 bit) and then exporting in 44.1 with 24 bit. Is there some way in camilla in the resample section that the input can be attenuated before conversion to 96? I might have missed an option.
 
#5,348
I've attached 2, one with the source with 4 more db of attenuation. Both give exactly the same warns from camilla.
[1db pad cfg]
2025-01-07 12:10:54.616892 WARN [src/conversions.rs:65] Clipping detected, 9 samples clipped, peak +0.84 dB (110.2%)
...
[5db pad cfg]
2025-01-07 12:11:04.864007 WARN [src/conversions.rs:65] Clipping detected, 9 samples clipped, peak +0.84 dB (110.2%)
...
What makes me believe it is in the conversion is the src/conversions.rs:65. I don't read rust, so difficult for me to follow the code.
 
#5,351
phofman said:
Did you troubleshoot your chain by playing to the soundcard directly first, without the alsa_cdsp plugin? You chain has many layers and each needs to be tested first, adding one by one.
Click to expand...
Thanks for the advice. Yes, it works without the alsa_cdsp plugin, and the alsa_cdsp plugin works with aplay but not with the mediaplayer. I checked now the logs and the status of the mpd.service and it seems that I came a bit closer to the problem:

Code: 
 mpd.service - Music Player Daemon
     Loaded: loaded (/lib/systemd/system/mpd.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-01-11 16:06:04 CET; 3min 16s ago
TriggeredBy: ● mpd.socket
       Docs: man:mpd(1)
             man:mpd.conf(5)
             file:///usr/share/doc/mpd/html/user.html
   Main PID: 659 (mpd)
      Tasks: 12 (limit: 4387)
        CPU: 485ms
     CGroup: /system.slice/mpd.service
             ├─ 659 /usr/bin/mpd --systemd
             └─1014 camilladsp -s /home/pi/camilladsp/statefile.yml -w -p 1234 -a 0.0.0.0 -l warn -f S16LE -r 44100 -n 2

Jan 11 16:06:04 raspberrypi systemd[1]: Starting mpd.service - Music Player Daemon...
Jan 11 16:06:04 raspberrypi mpd[659]: zeroconf: No global port, disabling zeroconf
Jan 11 16:06:04 raspberrypi systemd[1]: Started mpd.service - Music Player Daemon.
Jan 11 16:09:01 raspberrypi mpd[659]: exception: Number too large: 1
Jan 11 16:09:01 raspberrypi mpd[659]: exception: No such song
Jan 11 16:09:14 raspberrypi mpd[1014]: 2025-01-11 16:09:14.418536 WARN [src/statefile.rs:24] Could not read statefile '/home/pi/camilladsp/statefile.yml'. Error: Permission denied (os error 13)
Jan 11 16:09:14 raspberrypi mpd[1014]: 2025-01-11 16:09:14.419700 ERROR [src/statefile.rs:89] Unable to open statefile /home/pi/camilladsp/statefile.yml, error: Permission denied (os error 13)
Jan 11 16:09:15 raspberrypi mpd[659]: exception: No such song
it seems that alsa_cdsp starts camilladsp correctly but that the software cannot open the statefile although the permisson of the file is set to 0666 and the path is correct.
 
#5,352
ok, I solved the file permission issue, I added user=pi instead of user=mpd in the mpd.conf file. Now, it works when I start playback with the first track in the playlist. It hangs up, so soon as I stop playback and try to start playing again or when playback tries to move from track1 to track2 of the playlist.
The log file of mpd says "exception: Number too large: 1".
The log from mediaplayer:
Code: 
2025-01-11 17:51:57,121 [Thread-0] DEBUG [org.rpi.mpdplayer.StatusMonitor] Song Changed From :  To: 1
2025-01-11 17:51:57,134 [Thread-0] DEBUG [org.rpi.mpdplayer.StatusMonitor] Status Changed From : Stopped To: Playing
2025-01-11 17:51:57,134 [Thread-0] DEBUG [org.rpi.mpdplayer.MPDPlayer] Status Changed: Playing
2025-01-11 17:51:57,134 [Thread-0] DEBUG [org.rpi.player.PlayManager] EventStatusChanged: Playing
2025-01-11 17:51:57,134 [Thread-0] INFO  [org.rpi.player.PlayManager] SetStatus: Playing Source: PLAYER
2025-01-11 17:51:57,135 [Thread-0] DEBUG [org.rpi.providers.PrvAVTransport] Status: Playing
2025-01-11 17:51:57,136 [Thread-0] DEBUG [org.rpi.providers.PrvTransport] Status: Playing
2025-01-11 17:51:57,138 [Thread-0] DEBUG [org.rpi.mplayer.TrackInfo] Send EventUpdateTrackInfo: TrackInfo [bSentUpdate=true, codec=32 bits, bitRate=0, sampleRate=96000, duration=286, depth=32]
......
025-01-11 17:52:17,163 [Thread-0] DEBUG [org.rpi.mpdplayer.StatusMonitor] Status Changed From : Playing To: Paused
2025-01-11 17:52:17,163 [Thread-0] DEBUG [org.rpi.mpdplayer.MPDPlayer] Status Changed: Paused
2025-01-11 17:52:17,163 [Thread-0] DEBUG [org.rpi.player.PlayManager] EventStatusChanged: Paused
2025-01-11 17:52:17,163 [Thread-0] INFO  [org.rpi.player.PlayManager] SetStatus: Paused Source: PLAYER
2025-01-11 17:52:17,163 [Thread-0] DEBUG [org.rpi.providers.PrvAVTransport] Status: Paused
2025-01-11 17:52:17,164 [Thread-0] DEBUG [org.rpi.providers.PrvTransport] Status: Paused
 
#5,354
  • Like
  • Thank You
Reactions: darkless, Quza, bambadoo and 8 others
#5,357
Dual01 said:
ok, I solved the file permission issue, I added user=pi instead of user=mpd in the mpd.conf file. Now, it works when I start playback with the first track in the playlist. It hangs up, so soon as I stop playback and try to start playing again or when playback tries to move from track1 to track2 of the playlist.
The log file of mpd says "exception: Number too large: 1".
Click to expand...
Dual01 said:
2025-01-11 17:51:57,121 [Thread-0] DEBUG [org.rpi.mpdplayer.StatusMonitor] Song Changed From : To: 1
Click to expand...
IMO this has nothing to do with CDSP. The java controller cannot get URL of the next song (the previous error log we already discussed), yet asks MPD to play it (To :1) , making MPD output: Number too large: 1.

Now you are nicely going layer by layer. Aplay -> CDSP OK. MPD -> CDSP OK. Now the next step is the java controller -> MPD not OK, IIUC. The java controller needs to be troubleshooted. I would open the java source code in IntelliJ, set a breakpoint, and see what is going on before the error message. But I do java for living, a bit easier position, I know 🙂
 
#5,359
Hello,
there is a problem with the webinterface on my mobile phone (Samsung S22) since release 3.
Adjusting size with two fingers is impossible (pinch and zoom).
It looks like this:
1000006449.jpg

One can barrely see the left meter side.

Regards
Olaf
 
You must log in or register to reply here.
Top Bottom