They also suggest using GitHub - mikebrady/shairport-sync: AirPlay audio player. Shairport Sync adds multi-room capability with Audio Synchronisation to stream to several RPI0/HATS
GitHub - Infineon/merus-audio-amp-hat-zw
I hope a instance of CamillaDSP can be intalled on each of the RPI0s to do filtering?
GitHub - Infineon/merus-audio-amp-hat-zw
I hope a instance of CamillaDSP can be intalled on each of the RPI0s to do filtering?
I considered keeping the format setting but decided not to. I prefer keeping things slim instead of leaving outdated stuff in there just for compatibility. Makes it easier for me to maintain. I'm also thinking about dropping the FFTW option for the same reason.
No not endless energy, I just spend it wisely
It's possible, but the pi zero is a bit weak. It won't manage any fancy filtering, just a few biquads. I think it's mostly the FPU that is slow. Can you use a Pi 2 or above instead? They are vastly superior!
.For simple classic filtering of 1 or two channels a few biquads can be enough
Thinking of system where a
Master RPI 3 or 4 do the advanced filtering - I2S out
A chain of piggy backed RPI0s with AMPHAT that has simple bandlimiting filter for speaker element/elements connectet to the hat. The RPI0 can also do the I2C programing of the HAT.
The question is: Can RPI0s have I2S in from master RPI and I2S out to HAT?
Thinking of system where a
Master RPI 3 or 4 do the advanced filtering - I2S out
A chain of piggy backed RPI0s with AMPHAT that has simple bandlimiting filter for speaker element/elements connectet to the hat. The RPI0 can also do the I2C programing of the HAT.
The question is: Can RPI0s have I2S in from master RPI and I2S out to HAT?
Thinking of a system ala Beocreate 4 channel amplifier | HiFiBerry
But no DSP just RPI and CamillaDSP
BTW Maybe a beocreate with CamillaDSP could be something for portable speakers
But no DSP just RPI and CamillaDSP
BTW Maybe a beocreate with CamillaDSP could be something for portable speakers
I am aware of this issue.
The Dante board would be modified in consequence.
One of the lesser known things about CM4 is designed to go up to 24V input (obviously for trucks).
You power it off a simple 16V Laptop supply.
My 4g router in the same box goes up to 32V....it has the same laptop type connectors.
In my case they are both powered off a 12V DC heater supply (1970 vintage mil spec valves).
The I2S can be chained like that if clocked as slaves. But why complicate the setup with multiple RPi0s instead of a single RPi4?
Because a single RPI4 has only one I2S out?
So the RPI0s read the I2S stream. pick their their part of the signal, filters it and send filtered stream to the HATAMP.
Then one I2S stream can be sent to more than 1 poweramp IC.
Attachments
Last edited:
If the slave RPI0s get the same SCK from I2S stream then they get the sample at "the same" moment
Then I would set up the same Camilla DSP filter chain on all RPI0s.
I guess I would try to control the group delay of the filters and do not use more than 4.th order. Then do a realworld measurement and try to insert allpass delay on the RPI0s CamillaDSP chanels that need one.
But maybe they will just drift apart...?
Thougth Camilladsp adjusted to the input rate if enable_rate_adjust is set.
I assume only one samplerate is used and resampling is done at the RPI4 output.
Then I would set up the same Camilla DSP filter chain on all RPI0s.
I guess I would try to control the group delay of the filters and do not use more than 4.th order. Then do a realworld measurement and try to insert allpass delay on the RPI0s CamillaDSP chanels that need one.
But maybe they will just drift apart...?
Thougth Camilladsp adjusted to the input rate if enable_rate_adjust is set.
I assume only one samplerate is used and resampling is done at the RPI4 output.
But you need all RPis to output samples corresponding to the same audio frame at the same time. That is not about timing the I2S interfaces (they will run synchronously if clocked in slave mode, e.g. the first RPi running in master mode). It's about all camillas on all RPis starting to write samples to the alsa drivers at the same moment, down to one audio frame. That's almost impossible.
That's what multichannel I2S interfaces are for - the audio frame contains all channels and the channels cannot get skewed.
That's what multichannel I2S interfaces are for - the audio frame contains all channels and the channels cannot get skewed.
Maybe best to wait and see if someone can get CamillaDSP to run on the linux side of stm32mp that can get audio from the I2S on the real time time prosessor (STM32F4)
STM32MP157F-DK2 - Discovery kit with STM32MP157F MPU - STMicroelectronics
STM32MP157F-DK2 - Discovery kit with STM32MP157F MPU - STMicroelectronics
!
Hi here
Soo while playing with a setup i would like to use i need to have the possibility to swap between MPD and Squeezelite. (not at same time btw...)
While succes with getting MPD to stream to CamillaDSP with an FIFO, i need to have Squeezelite work somehow also.
Having done this a thousand times before, i simply cannot get it to work
Using newest squeezelite and trying both Camilladsp 0.6.1 and an older one just to try it out, i cannot get it to work playing a normal 44100Hz .flac file.
Hope someone can see where i am wrong ?
Rgds; Jesper.
Soo while playing with a setup i would like to use i need to have the possibility to swap between MPD and Squeezelite. (not at same time btw...)
While succes with getting MPD to stream to CamillaDSP with an FIFO, i need to have Squeezelite work somehow also.
Having done this a thousand times before, i simply cannot get it to work
Using newest squeezelite and trying both Camilladsp 0.6.1 and an older one just to try it out, i cannot get it to work playing a normal 44100Hz .flac file.
Hope someone can see where i am wrong ?
Rgds; Jesper.
Code:
sudo camilladsp -o /home/pi/cdsplog --loglevel trace /home/pi/camilladsp/squeezelite-44100.yml
Code:
sudo squeezelite -n SuperPlayer -o - -f /home/pi/sqlog -d output=debug -zpi@raspberrypi:~ $ cat cdsplog
Sep 09 19:11:55.308 DEBG Read config file Some("/home/pi/camilladsp/squeezelite-44100.yml"), module: camilladsp
Sep 09 19:11:55.309 DEBG Config is valid, module: camilladsp
Sep 09 19:11:55.309 DEBG Wait for config, module: camilladsp
Sep 09 19:11:55.309 DEBG Config ready, module: camilladsp
Sep 09 19:11:55.310 DEBG Build new pipeline, module: camillalib::filters
Sep 09 19:11:55.310 DEBG Build from config, module: camillalib::filters
Sep 09 19:11:55.310 DEBG Using channels [true, true], module: camilladsp
Sep 09 19:11:55.310 DEBG Build from config, module: camillalib::filters
Sep 09 19:11:55.311 DEBG build filters, waiting to start processing loop, module: camillalib:
Sep 09 19:11:55.311 DEBG Capture thread ready to start, module: camilladsp
Sep 09 19:11:55.460 DEBG Opening audio device "hw:1,0" with parameters: HwParams { channels: Ok(2), rate: "Ok(44100) Hz", format: Ok(S32LE), access: Ok(RWInterleaved), period_size: "Ok(1024) frames", buffer_size: "Ok(8192) frames" }, SwParams(avail_min: Ok(1024) frames, start_threshold: Ok(3072) frames, stop_threshold: Ok(8192) frames), module: camillalib::alsadevice
Sep 09 19:11:55.461 DEBG Audio device "hw:1,0" successfully opened, module: camillalib::alsadevice
Sep 09 19:11:55.461 DEBG Playback thread ready to start, module: camilladsp
Sep 09 19:11:55.461 DEBG Both capture and playback ready, release barrier, module: camilladsp
Sep 09 19:11:55.461 DEBG Supervisor loop starts now!, module: camilladsp
Sep 09 19:11:55.461 DEBG Starting playback loop, module: camillalib::alsadevice
Sep 09 19:11:55.462 DEBG Processing loop starts now!, module: camillalib:
Sep 09 19:11:55.462 DEBG starting captureloop, module: camillalib::filedevice
Sep 09 19:11:55.462 DEBG starting captureloop, module: camillalib::filedevice