work in progress which eventually will enable the user to configure dsp processor on the fly using an on device http server.
first try and possible fix for #22
Signed-off-by: Karl Osterseher <karli_o@gmx.at>
dsp processor now will process smaller chunks of audio at a time and loop over the audio data array
which results in a much smaller RAM usage but probably longer execution times
of IIR filters.
Signed-off-by: Karl Osterseher <karli_o@gmx.at>
- instead of storing chunk duration in ms store the frame count
and do calculations based on that
- add updated snapserver.conf for reference (#17)
- some code clean up
- move Kconfig entries to correct place
- remove unnecessary Kconfig entries
- add necessary dependencies in Kconfig files
Signed-off-by: Karl Osterseher <karli_o@gmx.at>
- detect snapcast configuration and init everything accordingly, e.g sample rate, chunk duration, ...
o calculate apll predefines in dependence of sample rate
o communicate these settings to interested parties
- remove typos
- minimize RAM usage of all components
- use both IRAM and DRAM in player component so we can buffer up to 1s on modules without SPI RAM
- support fragemented pcm chunks so we can use all available RAM if there isn't a big enough block available but still enough HEAP
- reinclude all components from jorgen's master branch
- add custom i2s driver to get a precise timing of initial sync
- change wrong usage of esp_timer for latency measurement of snapcast protocol
- add player component
- use espressif ADF, remove external opus rep
o uses audio pipelines now
- change code to use flac decoder
- remove mersus code
- add first try of audio synchronization
o needed to sync timeofday to server on reception of server settings to avoid overflows in timeval calculations (int32_t on esp32 SDK)
o still a lot of TODO's in the code, but it's almost in sync, although there is quite some chunk skipping which I am currently working on