Closed 0x0fe closed 1 year ago
You were really taking the combination of the most RAM demanding functionalities possible:
I assume that you pushed it a litte bit too far. I suggest that you print out the available ram in the loop as well to check if my assumption is right.
If this is the case you can also consider to use PSRAM, if your microcontroller support this.
ps. I only looked at the speed difference of the different FFT implementations but I am pretty sure that they have different memory requirements as well...
i see, that makes sense. The S3 variant i use has and additional 2MB internal PSRAM but it is not put to contribution yet. As a side note i tested with another sample URL (https://file-examples.com/wp-content/uploads/2017/11/file_example_MP3_2MG.mp3) and it worked fine, i could read the file in full, so the issue is also related to how the file is served apparently, maybe the drops increases buffer usage and lead to the stack collision.
Anyway i will disable the FFT (of no use here) and write to the file. Later i will try to figure how to assign some of the PSRAM to audio-tools so i can increase buffering.
I had this "Line cut off" problem with URLStream too. the problem is the server. the mp3 is not send via chunked. i fixed it via highWaterMark
here is a nestjs controller example
@Get(':id/audio')
@Header('Content-Type', 'audio/mpeg')
@Header('Cache-Control', 'no-cache')
async getAudio(
@Param('id') id: string,
@Req() req,
@Res({ passthrough: true }) res
): Promise<StreamableFile> {
const message: Message = await this.messagesService.findUnique({ where: { id } });
try {
const filePath = path.join(messagesPath, message.fileName);
const readStream = createReadStream(filePath, { highWaterMark: 1024 });
res.set({
'Content-Disposition': 'attachment; filename=audio.mp3',
'Transfer-Encoding': 'chunked', // Enable chunked transfer
'Connection': 'keep-alive', // Keep the connection open
});
return new StreamableFile(readStream);
} catch (error) {
throw new Error('File not found or could not be read');
}
}
took me a few hours to figure this out.
So, while experimenting with the multioutput on the sdfat-ffti2s example (modified to play an UrlStream) i face a stack corruption / stack smashing protection which is not random as it occurs everytime (in loop). The file is this one, 1.61MB and the stack corruption occurs after about 5 or 6 seconds https://filesamples.com/samples/audio/mp3/sample3.mp3 In the code below i commented the FFT display since it is not useful to show the bug and it fills the debug output. What i notice is that after few second streamcopy::copy get messed up and it crashes right after that.
StreamCopy::copy 1024 -> 4294967295 -> 0 bytes
What could be the cause of this issue? The platform is ESP32S3 and it plays on an external DAC.