opus
opus copied to clipboard
xiph
decode fails on long stream when compiled with NONTHREADSAFE_PSEUDOSTACK
Hi - My platform (https://github.com/sle118/squeezelite-esp32) is an esp32 CPU and I've compiled opus & opusfile for that target. It works fine when using VAR_ARRAYS but this is a fair bit of stack consumption which is a scarce resource on this chipset (it mostly needs to be in internal memory - although there are ways around). The best solution is to use NONTHREADSAFE_PSEUDOSTACK and use heap. Unfortunately, what happens on most long playback is a failure after 10~30 mins.
op_read returns -136 and the issue is that there seems to be some corruption in the pseudo-stack
- op_get_packet_duration has a nsamples >> 120*48
- a general OPUS_INVALID_PACKET that can happen at many places (I've not been able to track them precisely yet)
I've compiled with O3 (same result with any O level) and for fixed point only. I've tried different values of the stack "pool", from 32 to 120k, no change.
I understand my description is too vague for allowing any analysis, but what I'm asking is that if others have seen issues when compiled with PSEUDOSTACK. I don't think there is a memory corruption somewhere else on my system as it's a very stable and runs mp3,flac,aac,alac,pcm,vorbis without issue for hours. Of course I cannot rule that out, but it only & systematically happens with opus.
sorry I'm not sure I understand what you mean. It started from an audio core that initially was built on x86 processors (then on many others) and is a well maintained project https://github.com/ralph-irving/squeezelite. The porting and many extensions I've made compile on an x86 but you'd need an embedded system with the different I/O access as well as a port of some of the espressif's esp-idf libary if you want to use these.
Sorry, what I meant was.
If you use the same build options for opus lib only and use same/similar input can you reproduce the same memory corruption with Opus demo on linux x86? Or is it unique for ESP32?
Silly me, of course. Well, I've not been able to get any error on x86 recently. I think (...) I had at least one, but I have to say that at best it's much less frequent (although on the esp32, it can be after 5 mins or after 6 hours ...). I've compiled it with the same parameters on x86, no asm optimization, fixed points, no CPU detection, no stack. I know it speaks for a compiler-related problem, but that's the only piece of code on my whole project that repeatedly shows a problem, regardless of compile optimization level.
It makes sense, I've been using and following Opus for years and never even heard of NONTHREADSAFE_PSEUDOSTACK. Probably not as well-tested as more common configurations. Can you throw a specific 24 hour stream of audio at it, and get it to reliably break at a point? Or unreliably, for that matter, that would point to something uninitialized.
You might wanna measure heap usage on X86 and ensure that you have enough heap on ESP32 for Opus to work.
Also there is an espressif engineer that seems to be looking into Opus here: https://gitlab.xiph.org/xiph/opus/-/issues/2318
Might be worth contact him and see if he has any hints or thoughts regarding this.
I've tried with a pseudo-stack of 32k and 120k (both successfully allocated of course) and did not see any difference. Other than that, I don't think.know if opus does heap allocation, but there is a few 100kB left