I know when these files come down, you see then in the What’s New Icon. Will we have to go to the Files Manager Icon and then find them there somewhere? Ken
Im getting mixed results here. I built c2dec and sox binaries for skylark today and made a few tests with the c2/1200 file. while the decoded WAV file sounds ok-ish (takes up 4 MB of SD card), the re-encoded MP3 file sounds horrible regardless of bitrate. Tested with LAME and SHINE. Decoding/recoding times are below real-time, the 5 minute newscast takes about 40 seconds of processing time with SHINE. the LAME encoder takes about twice as much and the result sounds the same. Either there’s something wrong with the PA-Model of shine (and lame/sox) or the cortex/neon combo works differently than x86. I’ll make some more tests with higher quality c2 files tonight.
So at least on DC3 the processor has enough ‘steam’ to do the processing for real-time low-bandwidth audio in c2 format. While the tests were conducted for c2 filecast and conversion on-board, this proves that even with streaming the board is powerful eough. Only the sound quality is still questionnable.
1 Like
But this is where like having a rpi to act as a web serer would be good since to could with the correct access pull the compressed file from the dreamcatcher 4 then eather push it back to the dream catchers 4 storage or store it on the rpi for playback via it’s web server
Right now there’s already quite a bit of content that is decompressed or decoded after download. Currently that’s 3 file types, the grib2 weather data, the compressed news bulletins and OTA software updates. The DC4 needs to provide similar mechanisms. Although its CPU is quite less powerful than the Cortex in the Allwinner A13, it should be able to do the decompression jobs alongside receiving the files. Not sure about real time decoding of audio though. I’ve had good results in that departement with the RP2040 processor on the Raspberry Pi Pico with is about the same ballpark as an ESP32. Of course the RPI didn’t do anything alongside I2S audio shuffling and decompressing.
(RPI2040: Dual Core Cortex M0+ processor, up to 133 MHz, 264 kB RAM)
The Main Issue here will be that the ESP32-S2 is Signle Core, so it has to do one thing at a time, but i think Audio decoding should be possible, decompressing larger Files will not work i think, that’s why i implemented a Decompresor in JS for the normal Files like Wikipedia Articles.
It could work if it detects a file that already has been received once and it still has on the sd card it could in theory stop focusing on receiving that file and devote all of the cpu power it has to do decompressions and just checking the receiving once in a while to detect when the next file is going to start to then switch the cpu back to focusing on the download again.
@Group
Let’s take Voice of America news file for this example. I have a question about group preference (ultimately @Syed will make the decision). Would it be better to have a single file for each feed that gets updated with the latest version (ex: voa_news.mp3) or many individual files (voa_news_032521.mp3) that build up and need to be purged by the user? IMO stale news is pretty pointless, so I vote for the single file that gets updated with no need for purging over time. That’s just my opinion, I’d love to hear yours.
1 Like
The problem with overwriting files starts at the moment you are listening to the file while it is supposed to be replaced. I’d prefer rolling names with a short retention of 3 or 5 days and automatic purge afterwards.