Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by some-xtc - 2010-07-13
Last edited by Buschel - 2010-10-02

FS#11476 - Fast Forward makes Musepack (SV8) "data abort"

1. Player: Sansa Clip+ 8gb
2. Player Sansa Fuze V1 2gb
Version: 27409-100713
microSD: 8gb

Hello,

this is my first bugreport.

I have some strange behaviours when I want to play Musepack (SV8).

Sometimes, when I fast-forward (even a little) a .mpc-track, my Clip+ & Fuze V1 goes “data abort”.

For example my Clip+ says this:
Data abort
at 30006638
(domain 0, fault 8)
address 0xFBFAF60C

And my Fuze V1 says this:
Prefetch abort
at BB06574
FSR 0xFF
(domain 15, fault 15)

I’ve also tried the official 3.6 release for Fuve V1, but this is what happened too:
Data abort
at 30801020
FSR 0×8 (domain 0, fault 8)
adress 0xD106D033

or:

Data abort
at 30801020
FSR 0×8 (domain 0, fault 8)
adress 0ACFC87EF

And this is what I get sometimes with the 3.6 release, when I just wanted to start a .mpc :
Undefined instruction
at 2F900000

Hopefully, you guys can fix this.

Greetings

Closed by  Buschel
2010-10-02 17:44
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Submitted with r28197

Additional information:
These “data aborts” appears basically at the end of a file, after I made a ffwd.

Okay,

the next surprise is, that Musepack SV7 works fine.
Testet on Sansa Clip+ 8gb & Fuze V1 2gb (Version: 27409-100713): no such problems occurs.

So the problem child is the Stream Version 8….

I have just checked the files from http://samples.mplayerhq.hu/A-codecs/musepack/sv8/ on PCsim an my iPod Video – no problems at all. Could also please check those files and give an upate whether those show the same problems on your player?

There are no problems with the files from the site.

Hold on! ….it is the same problen with “Choral.mpc” for example:
Data abort
at 30006638
FSR 0×8 (domain 0, fault 8)
address 0x8BE1154C

Additional information:
this problem only occurs when the next file on the playlist is “CPE.mpc”

Can you attach our config.cfg here? Maybe you are using some other settings that I do not use (e.g. crossfade).

this is the config.cfg from my Clip+

I have also testet this issue on my Sansa e260 & M:Robe 100 …. no problems at all.

Maybe this problem limit oneself to the Sansa AMS models?

Still not reproducible. The error adress points to a failure when using memset(). There are only few calls of memset in the decoder engine… Are you able to build rockbox on your own?

No, sorry.

Please try to use the attached 4 versions (fuze v1 build). Rename each file from “mpc.codec.v0x” to “mpc.codec” and copy it to /.rockbox/codecs
Is there any difference in behaviour?

The codec was built against r27405.

with .v01 the same situation:
I play “Choral.mpc” and if I ffwd to the end or just even switch to the next track “CPE.mpc” I get this:
Data abort
at 30006760
FSR 0×8 (domain 0, fault 8)
address 0x8BE1154C

with .v02 (same situation as above)

- ffwd to the end:
Data abort
at 30006760
FSR 0×8 (domain 0, fault 8)
address 0x8BE1154C

- just switch to the next track “CPE.mpc” Data abort
at 300068D8
FSR 0×8 (domain 0, fault 8)
address 0x8BE11674

with .v03 the player randomly freeze after ffwd (and the current time shrugs).

sometimes I get this:
Data abort
at 30006760
FSR 0×8 (domain 0, fault 8)
address 0x8BE1154C

with .v04 it is same like in .v02
I am unable to play “CPE.mpc”:
Data abort
at 300068D8
FSR 0×8 (domain 0, fault 8)
address 0x8BE11674

Hmm, now it does not crash in memset(), but in the buffering routines of rockbox. To me it seems like the seek (which will trigger data loading and buffering in rockbox’s core code) raises a bug in the buffering code that will come up when the next track must be loaded.

Can you please re-check with r27950?

unfortunately … :(
with r27958 I get various messages, e.g.
Data abort
at 3000677C
FSR 0×8 (domain 0, fault 8)
address 0x8BE1154C

Bad… :/ And thanks for still supporting the debugging.

Let’s see whether there will be some fixes in the buffering area. I’ll keep this task open…

Edit: Btw, is this error happening when playing files from SD or internal Flash?

Thanks for still debugging!

Call me a nerd, but Musepack sounds just much better than other free codecs :D
__

The error happens on SD and internal Flash with the same Data abort.

eevan commented on 2010-09-13 20:27

Hello to all!

Here’s my data regarding this issue. I have Fuze V2. The problem occurs on track change, both on manual skip and when a player is about to play the next track in a playlist. Also, manual skip sometimes works, but maybe 1 in 10 times. Sometimes (but rarely) it freezes in the WPS when I start the playback and disk access icon stays on, without any message. I should say that Fuze V2 plays SV7 files without any problems. My c200v1 don’t have these issues, it plays both SV7 and SV8.

When the backlight is on, WPS is displayed and player should play the next track in a playlist. It freezes with the following message:

Prefetch abort
at E1FD5F16
FSR 0×8 (domain 0, fault 8)

And if the backlight is off when the player should play next track it freezes with:

Undefined instruction
at 0006CD8

Also, sometimes the player freezes with the backlight still off, so I can’t see the message. The only thing I can do is a hard reset.

Seeking within the file on my Fuze V2 works fine I guess, but I haven’t tested with large files (CD images in mpc format for example).

Weinberg thought in his post (http://forums.rockbox.org/index.php?topic=25705.0) that maybe it has to do with album art, but I tested this both with and without album art in WPS, and it occurs anyway.
And I can also confirm that error happens when the files are on SD card, and internal flash.

Also some answers to Andree:
– It happens on track change. It can play the whole track without seeking, and it crashes on change to the next track in playlist. The error never occured when I fast forward on my player. But If I FF to near the end of a track, it plays until track change and then freezes… –Files have only APEv2 tags. Nothing else.
–Yes, there is a file which crashes all the time.

I also put one Vorbis file in playlist after SV8 file, and the player didn’t crash! The change from Vorbis to SV8 also passed without error, and there are some SV8 files that won’t trigger it. It is quite irregular.

I also got:

Prefetch abort
at E1FD5F16
FSR 0xAA
(domain 10, fault 10)

when the player was playing MP3 file and was about to change to SV8, next in the playlist.

I hope this can help you some more…

Hello Ivan,

I have also created a topic in the forum:
http://forums.rockbox.org/index.php?topic=25354.0

Your report (and you are the only one yet) confirms my assumption, that this is a SansaAMS-specific problem.

Maybe this is helpfull to isolate this problem, Andree?

Leo, here is a patch for you to test. Another user stated that this solved seek issues on his clip+.

As I remember you cannot compile for your own I have attached a codec file (to replace your players .rockbox/codecs/mpc.codec) that was built against r28184 for Sansa clip+.

This patch rolls back an optimization I did months ago to allow reasonable speed for seek forward. If this also solves your issue I need to further dig into the code to understand why this introduces errors on clip+ and for sv8 only.

Please let me know your test results,
Andree

unfortunately I don’t have the build r28184, so I used the current (r28187):

The problem is still there on my clip+.
Data abort
at 30006788
FSR 0×8 (domain 0, fault 8)
address 0x8BE1154C

Or this here:
Data abort
at 39F8D6D4
FSR 0×8 (domain 0, fault 8)
address 0xEF54FC7F

I have also made some other observations:

The error is sometimes and somehow related to the WPS.
Normaly I use cabbiev2.
But when I change the WPS on startup, I get immediately a data abort with the files that previously are playable on cabbiev2.

For example look here:

with cabbiev2:
Data abort
at 30006788
FSR 0×8 (domain 0, fault 8)
address 0x8BE1154C

and with a simple WPS-code:

%wd
%?ia<%ia|%d(2)>
%?id<%id|%d(1)>
%?in<%(%in%) |>%?it<%it|%fn>

I get this:
Data abort
at 300068F0
FSR 0×8 (domain 0, fault 8)
address 0x8BE11674

Tested with the same files (from http://samples.mplayerhq.hu/A-codecs/musepack/sv8/ ), same build (r28187), with your mpc_sv8_seek_v01.patch

And here is the playlist.
I get always (realy always) a data abort on trackchange from “Choral.mpc” to “CPE.mpc”

Another approach (clean-up of different buffering calls) built against r28188.

Please check with sv7 and sv8. Both play and seek fine on pc simulation.

can you upload a compiled mpc.codec please?

silly me… I had it attached and then pushed the wrong button – instead of adding a second file I have exchanged the codec-file wioth the patch :/
will add this this evening (in about 8 hours).

Here is the patch.

   mpc.codec (49.4 KiB)

Play and seek works fine, but everytime on trackchange ;(

at 30006788
FSR 0×8 (domain 0, fault 8)
address 0x8BE1154C

Damn. The crash is happening somewhere in the buffering code, not in the codec part.

After lots of printf-debugging I found out that sv8 contains a seek table at the very end of the bitstream. Your playlist contains two files whoms cumulative sze exceeds your buffer size (only 8 MB of RAM, files are > 8 MB). Therefore seeking to the end of the second file (to load this files seek table) forces rebuffering, than seeking back to beginning of the file (for playback) will again force rebuffering. Maybe this patch does the trick?

Yes!
It works!

Trackchange works without any data aborts on my clip+ !!
And the best: It’s gapless :)

Thanks!

eevan commented on 2010-10-02 17:06

Great Andree!
Will the same patch be helpful for Fuze v2 data aborts?

Ivan, I expect this fix to help on Fuze v2 as well :o)

\o/

I will submit this in the next hours.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing