Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Deprecated: Function create_function() is deprecated in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/rockbox.org/flyspray/adodb/adodb.inc.php on line 845 Deprecated: Function create_function() is deprecated in /sites/rockbox.org/flyspray/includes/class.user.php on line 111 FS#13131 : Opus speech @ 32kBit: plays fine, but crashes on resume or bookmarks on Sansas

Rockbox

Tasklist

FS#13131 - Opus speech @ 32kBit: plays fine, but crashes on resume or bookmarks on Sansas

Attached to Project: Rockbox
Opened by Johannes Rauh (johnbtracker) - Saturday, 23 September 2017, 07:37 GMT
Last edited by Willliam W (Bilgus) - Thursday, 15 August 2019, 02:40 GMT
Task Type Bugs
Category Codecs
Status Closed
Assigned To No-one
Operating System Another
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I encoded an audiobook with libopus 1.2.1 @ 32kBit VBR.

Playback and seeking works fine, but resuming playback (after stopping) or launching a bookmark crashes RB on my clip+ with this message:

*PANIC*
Stkov codec
pc: 30063F8C sp:30803B:
A: 300BCB8
bt end

I did some more tests:

The problem exists @ 32 & 48 kBit/s
All is fine @ 64 & 96 kBit/s.


So I believe this is due to the codec improvements jmvalin has done in the < 48 kBit/s range:
https://hydrogenaud.io/index.php/topic,114234.0.html

Further experiments:
I get the crashes on clip+, FuzeV2, FuzeV1 (<- verified with acc3ef3b6-170922).
No crash with Samsung YP-R0 and Sony 585 (both hosted).

It doesn't happen with music, only with speech. So I encoded this free speech:
https://archive.org/download/ObamaSpeech/obama%20speech.flac

32 kBit sample: http://www.mediafire.com/file/o7c1ccwuzs1ckl2/obama_speech.32.opus
48 kBit sample: http://www.mediafire.com/file/bt0llwlyaeucxl7/obama_speech.48.opus
Both crash RB on the Sansas.

The above is basically a summary of
http://forums.rockbox.org/index.php/topic,51881.msg240132.html#msg240132
This task depends upon

Closed by  Willliam W (Bilgus)
Thursday, 15 August 2019, 02:40 GMT
Reason for closing:  Fixed
Comment by Johannes Rauh (johnbtracker) - Saturday, 27 October 2018, 12:12 GMT
The problem is gone with the latest Opus release:
https://people.xiph.org/~jm/opus/opus-1.3/

Tested with 32 and 48 kBit.
Comment by Logan (strombergl) - Thursday, 09 May 2019, 15:52 GMT
I am still experiencing this problem on Clip+ with the latest firmware 4ed5727

*PANIC*
Stkov codec
pc:30067390 sp:30803a A: 3008f734

It happens when I seek to the middle of this file, about 40 minutes in (24Kbit ogg opus): http://discogenie.dyndns.org/Cloudsdale/Music/The%20Adventure%20Zone/The%20Adventure%20Zone%20-%20Amnesty/Justin,%20Travis,%20Clint%20and%20Griffin%20M%20-%2026%20-%20Amnesty%20Arc%204%20Part%205.opus

In the meantime is there a last known good version of the firmware where this worked? I had another Clip+ about 2-3 years ago that I never saw any errors on.
I'm listening to speeches and podcasts constantly and this is a major pain to have to tiptoe around this error, so if this doesn't get fixed I will probably do some bisection to see if there's a firmware version where this doesn't happen.
Comment by Johannes Rauh (johnbtracker) - Thursday, 09 May 2019, 19:06 GMT
What opusenv version have you used for creating that file?
Comment by Johannes Rauh (johnbtracker) - Thursday, 09 May 2019, 19:15 GMT
opusenc
Comment by Logan (strombergl) - Friday, 10 May 2019, 01:03 GMT
ffmpeg-20190107-038d291-win64-static.
Hard to tell exactly what version of libopus is used in there (libavcodec is version 58.43.100...), but the release is dated 2.5 months after opus 1.3 so I can only guess that it's up-to-date.

I can try re-encoding the file with latest opus 1.3.1 to see if that makes a difference though.
Comment by Logan (strombergl) - Friday, 10 May 2019, 01:52 GMT
Reencoding the file with the latest opusenc 1.3.1 doesn't make any difference.
Comment by Logan (strombergl) - Friday, 10 May 2019, 02:18 GMT
Hmmm. I just tried flashing different versions of the firmware to see if I can identify the regression (bisecting is actually really difficult because I can't effectively browse all of the dev build history, but I digress...)
I couldn't repro the problem on 3.13 firmware, but I can repro with 3.14 and the latest dev version.

One strange thing is that when I restored my original backup afterwards (to the latest dev 4ed5727), I could still repro the panic but it was much rarer. All I could think of is that if this is an out-of-memory error because of stack space or something, maybe some setting changed (database caching? max playlist size?) that affected background memory use.

I was hoping I could just tell you "here is the commit that caused the regression" but for now that's all the info I have.
Comment by Willliam W (Bilgus) - Sunday, 04 August 2019, 18:55 GMT
Can someone test this with the latest dev versions?
Comment by Johannes Rauh (johnbtracker) - Sunday, 11 August 2019, 07:46 GMT
I am going to test it today ...
Comment by Johannes Rauh (johnbtracker) - Sunday, 11 August 2019, 16:34 GMT
I tested with clip+ dev build 190810 and the opus files I posted above.
No problems found on resume playback and launching bookmarks.

However, on the second file (48kbps) I can trigger a stack overflow by seeking in the file and releasing the > button.
Comment by Johannes Rauh (johnbtracker) - Sunday, 11 August 2019, 16:38 GMT
And again, encoding the flac file with libopus 1.3, libopusenc 0.2.1 @48kbps also that problem is gone.
Comment by Logan (strombergl) - Monday, 12 August 2019, 05:35 GMT
Yep, I can still repro. Sansa clip+, build ID 3b75f98, 24Kbps .opus file encoded with libopus 1.3. Seeking about 45 minutes into a 1.5 hour file triggers a panic:
Stkov codec pc:3007c73c sp:30803a A: 30094838
Comment by Willliam W (Bilgus) - Monday, 12 August 2019, 06:08 GMT
john or logan can you get me that file so I can do some testing?
Comment by Logan (strombergl) - Monday, 12 August 2019, 06:13 GMT Comment by Johannes Rauh (johnbtracker) - Monday, 12 August 2019, 10:17 GMT Comment by Willliam W (Bilgus) - Monday, 12 August 2019, 16:34 GMT
Good news everyone I was able to reproduce the error
bad news is that I haven't figured out how to fix the issue yet

followed it here:
https://github.com/Rockbox/rockbox/blob/master/lib/rbcodec/codecs/opus.c#L502
ci->pcmbuf_insert(&output[skip * header.channels], NULL, ret);

https://github.com/Rockbox/rockbox/blob/master/apps/codec_thread.c#L223

and then lo and behold I find this: https://github.com/Rockbox/rockbox/blob/master/apps/codec_thread.c#L94
/* Workaround stack overflow in opus codec on highmem devices (see  FS#13060 ). */
#if !defined(CPU_COLDFIRE) && (MEMORYSIZE >= 8) && defined(IRAMSIZE) && IRAMSIZE > (32 * 1024)
#define WORKAROUND_FS13060 0x800
#else
#define WORKAROUND_FS13060 0
#endif

https://www.rockbox.org/tracker/task/13060

So a fix had already been submitted and you've found a case where it still occurs so the search continues..
Comment by Willliam W (Bilgus) - Tuesday, 13 August 2019, 03:59 GMT
ok try this clip+ build
http://www.mediafire.com/file/lism0bn3edhi8wh/Clip%252BOpus_8-12-19rockbox-full.zip

This fixes it for me hopefully you as well
http://gerrit.rockbox.org/r/#/c/2231/
(build only includes the above patch)


speachy also has a patch that moves some opus structures off the stack that may help
http://gerrit.rockbox.org/r/#/c/1932/

Comment by Logan (strombergl) - Tuesday, 13 August 2019, 17:59 GMT
Hallelujah, that fixes it for me! I went seeking back and forth through a dozen opus files and couldn't repro it once.

It seems like a strange fix though - I would have thought that resetting the decoder state wouldn't actually free any memory, only zero out the buffers that were already in place. Still, I can't argue with the results v0v.

You really don't know how thankful I am for this. I was hitting this bug on a near-daily basis and it was the one thing keeping me from fully enjoying Rockbox. I owe you a coffee or something.
Comment by Willliam W (Bilgus) - Wednesday, 14 August 2019, 04:32 GMT
At first I thought it might be the effect of disabling optimizations for ARM since one of the changelogs mentions
'Resetting the encoder or decoder state with OPUS_RESET_STATE would disable some run-time selected architecture-specific optimizations;'
but disabling optimizations did not stop the stackoverflow

OPUS_RESET_STATE removes all the previous info opus uses to optimize the audio so I figure there might be some loss of quality
but since preskip is still intact I figure it is about the same as streaming opus and I honestly hear no extra artifacts (not to say there aren't any...)
this will still need some testing and a bit of error handling too before i push it and close this FS

Comment by Willliam W (Bilgus) - Wednesday, 14 August 2019, 06:37 GMT
Asking about the consequences of OPUS_RESET_STATE in the #opus IRC channel it sounds like its a good idea to reset the decoder after a seek anyways

mark4o> The packets overlap and may reuse state set by other recent packets, so if you seek to a different position,
resetting the state helps to ensure that the subsequent packets won't use the state set by the unrelated packets that were processed before the seek
Comment by Logan (strombergl) - Wednesday, 14 August 2019, 21:07 GMT
I did some more testing on the RESET_STATE patch. I encoded a 2-hour long file at various bitrates and modes, from 16Kbps - 64Kbps and with flags such as FORCE_MODE_SILK, FORCE_MODE_HYBRID, to try and produce files that would require varying complexity for the decoder to process. Seeking around through all of them, bookmarking and restarting, playing and pausing - none of them could trigger the stack overflow.

I still can't explain how resetting the state fixes the issue, but I agree that it's definitely best to do the reset after seeking, along with the 80ms preroll and the other stuff that Mark mentioned in IRC
Comment by Willliam W (Bilgus) - Thursday, 15 August 2019, 02:40 GMT
we already do the preroll its a bit convoluted but it's there so yeah we'll call this fixed, going to close this as its been pushed to the dev versions earlier today

Loading...