On the best way to stream-save a remote mp3 playlist

[0x0fe]

What i try to achieve is the following, there is a set of 5 or 10 mp3 files, stored online, and i try to save them to the SD-MMC while ((almost) immediately streaming the first one, later next files will be played from the SD once frist file playback finishes.

Files in most cases are HTTPS but are accessed with the non secure client (HTTPClient), which saves some processing overhead, i found that the average performance without modifying the SDK config (which would imply recompiling all the core libraries) is around 80KB/s (on aws), but it can be lower, like 48KB/s in my test below (https://file-examples.com/storage/fe629099fc646eff79529f9/2017/11/file_example_MP3_2MG.mp3).
It is hard to know exactly which time is spent where,e specially when using arduino APIs, i however timed what i could (CHUNK_SIZE is 65536):

  auto start_ = millis();
  unsigned long c=0;
  while ( downloadRemaining > 0 && http.connected() ) {
    auto dstart = millis();
    auto data_size=stream->available();
    if (data_size > 0) {
      
      auto available_buffer_size = CHUNK_SIZE - (cur_buffer - buffer_);
      auto read_count = stream->read(cur_buffer, ((data_size > available_buffer_size) ? available_buffer_size : data_size));
      cur_buffer += read_count;
      downloadRemaining -= read_count;

      if (cur_buffer - buffer_ == CHUNK_SIZE) {
        auto wstart = millis();
        write(fileno(file), buffer_, CHUNK_SIZE);
        cur_buffer = buffer_;
        auto wend = millis();
        writeTime+=wend-wstart;
      }
    }
    auto dend = millis();
    downTime+=dend-dstart; 
    vTaskDelay(1);
    delayTime+=10;
  }

01:01:35.551 -> .Stream received
01:01:35.551 -> TOTAL SIZE : 2113939
01:01:35.551 -> START END
01:02:18.683 -> speed 48KB/s  total:43092  read:184  write:7676  delay:31380  idle:3852

speed is total time / total datas received,
read is the time spent to actually read the stream (stream->read)
write is the time spent writing on sd-mmc (write(fileno(file), buffer_, CHUNK_SIZE);)
delay is the number of calls to vTaskDelay(1);
idle is the time spent outside this task (total-read-write-delay)

These timings are obviously flawed especially for stream::read because it is obvious it has spent the most time here but it doesnt show, i suspect because the stream api stores in a buffer in the background and all we do in stream::read is to read from the ram buffer, so the real time spent reading from server ends up in idle count. Regarding the SD it seems accurate although very slow (278KB/s).
Anyway, it looks like maybe it could be possible to send datas to a decoding / I2S task in between the reads from server and writes to the SD card.

What would be the best strategy to integrate this with arduino-audio-tools?

Of course the fact that download is faster than audio streaming implies the first file will still be playing when the next file will start downloading, i am not sure wether the sd_mmc driver can allow to read and write two separate files concurently, and also if it can allow to read the same files in two separate instances (the case of the first file which will be both downloaded to and read from at the begining of the process).

Any pointer will be much appreciated.

[pschatzmann]

Two alternative proposals:

• Keep your existing logic download and just create a new task to play the files from the sd drive
• Use a flow that copies the data from URLStream to MultiOutput which writes to both a File and I2s

[0x0fe]

yes, so i chosed the first option, the HTTPS file-stream is started normally in a dedicated task and downloads occur in parallel in a separate task, a large 16K buffer is allocated dynamically on the PSRAM for each download to "maximize" the download speed (and SD_MMC write speed).

It works well however the memory conumption of wifi is large, since both connections are HTTPS a lot of memory is wasted in TLS. also download speed is slow, If running this in arduino the download speed is at best 100KB/s, but this is enough (the songs are downloading faster than the streaming), to improve wifi speed the only way is to move on VSCode and make a project with both PIO and IDF, so that we can access the menuconfig and still have the arduino HAL. Most tweaking to improve wifi speed is done on TCP and TLS settings.

The ultimate goal is to have https file-streaming, https download and A2DP sink and source within the same firmware (without rebooting). OF course A2DP sink is never used at the same time as file streaming (or even file download) however there is something weird with the espressif A2DP implementation which prevents from stopping it, free ressourecs and restarting it. This is very annoying and i opened a ticket about this, hopefully they find a way to solve it.

Overall it is a little hard (if not impossible) to have the wifi and bluetooth A2DP active at the same time because it seems to uses most of the IRAM and sadly we cannot assign much of the wifi / bluetooth stack on the PSRAM, there are many limitations with PSRAM, the cache is shared with FLASH and it is slow compared to IRAM, anyway i continue to fiddle with this, maybe at some point i can get averything together and working within the available IRAM (and the 2MB internal PSRAM on the ESP32D0WDR2 which i use).

[pschatzmann]

It is documented that after starting A2DP some memory can not be released any more and that after releasing some other memory, A2DP can not be started any more!

So you better now what you are doing and I don't think that your goal can be achieved!

[0x0fe]

yes, i saw it and that is why i opened a ticket, it can probably be fixed.

So you better now what you are doing and I don't think that your goal can be achieved!

well, i think i do, i dig since a while into epressif APIs and the various implementations. In my opinion the bluetooth stack should be able to release this memory, espressif will look into it. IF it is not possible i may have to implement a flag in the RTC backup registers or in NVS and silently reboot when the A2DP mode is requied, to make wifi and A2DP exclusive.
By the way, i wonder why you init the SPP in your library, it is not used for A2DP, and in IDF menuconfig we can disable SPP while keeping A2DP active. So I had to comment this line.

[pschatzmann]

I don't remember, but I think that it was to be compatible with the Arduino BluetoothSerial.

[0x0fe]

OK i see, at the moment i already ave wifi enable along with A2DP sink and player, all working. slowly adding the downlaod function to see how far i can push.
I realized, since your library is modular it may be possible to free the MP3 decoded ressources when A2DP is in use.

[pschatzmann]

I committed a change to activate SPP only on request. I think this is a better solution and should save some unnecessary memory allocation

[pschatzmann]

Your comment about the download speed does not make any sense to me: See https://www.pschatzmann.ch/home/2023/02/28/arduino-audiotools-esp32-vs-rp2040-pico-w/

I was getting around 148’400 bytes per second in Arduino!

[0x0fe]

I am not talking of the "decoded bytes" out of the mp3 decoder but the actual download speed of a file, and the speed i gave have been measured with an httpclient in dedicated thread using chunks of 16384 bytes (and writing to the SD_MMC) while there is a stream playback of another file at the same time (in another task), both from https.
On ESP32 the wifi PHY and TCP stack are theorically capable of about 2.5MB/s (20mb/s) with ideal tcp configuration and using IDF only. On arduino this is another story, the httpclient is slower, and use the inefficient stream class, and TCP parameters are not set for best speed. The asyncwebserver is apparently faster (i did not try it yet).

[pschatzmann]

Nor do I, the 148’400 are measured bytes per second with one single download.
I completely agree with the rest of your statement and I would expect as well that this number decreases if you do 2 downloads in parallel.

So my recommendation would have actually been the second proposed option. But this has the disadvantage that the file is only available after it has been played.

[0x0fe]

yes, we dont know the "total" throughput because i did not measure it, i only measured the file download throughput which is what matters to me. Probably that the total throughput is 150KB/s or close, as you have seen in your tests. Also i know the async web client performs a little better, but i did not try it yet being in a dedicated task there was not much reason to do so for initial implementation.

The second option is not possible because the files have to be downloaded faster than the streaming is going., so that there is a chance that all files are saved to the media (sd_mmc) even if the streaming is aborted early.