Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System PortalPlayer-based
  • 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 ryran - 2008-02-12
Last edited by Buschel - 2008-03-30

FS#8597 - stuttering & undefined instruction errors on codec-switch with crossfade

Tested with an ipod 5g 60GB & r16290.
I described this buggy behavior in Buschel/Soap’s PP502x unsupported builds testing thread when I first noticed it. I should’ve posted the info to the FS entry because it got cleaned up by Soap, but now that Andree’s code is in SVN I can post a real bug report. Back then I hadn’t yet figured out that mp3/ogg codec switching was the cause.

*behavior*
With crossfade enabled, there’s a stuttering glitchy-ness on track transitions (natural or user-initiated) between mp3 and vorbis (or vorbis & mp3) files. The stuttering is not present when crossfading between mp3 & mp3 or ogg & ogg. Sometimes the stuttering seems to last a bit longer (seconds) than other times. Frequently Rockbox bottoms out with an undefined instruction error (and as of yet, only one time [today] with a data abort error).

An important piece of info: the stuttering and the blue-screening doesn’t occur when the cpu is boosted–like when the buffer is still being filled or if you manually force the cpu to stay at 80MHz.

I first noticed all of this once I started testing Buschel’s power-saving patch. It’s now in the latest SVN.

*to reproduce*
Turn on crossfade. Pretty much any setting should work, but the glitches might be more apparent (though the undefined errors will happen eventually no matter what) with longer crossfade times (eg 1 sec fade in, 2 sec fade out delay, 3 sec fade out). Load up an mp3 file and an ogg vorbis file into a playlist. Wait until the hard drive has stopped spinning (so cpu isn’t boosted) and then skip forward (or wait for the track to change naturally. There might just be a short skip/dropout in the sound or there might be a stutter/glitchy pop. It’ll happen though. If you’re really lucky, you’ll get an undefined instruction error in your first try. (It’s happened to me once. :-)

Note: I put PortalPlayer-based for the player type of this bug report. That’s just an assumption of course. I haven’t tried any other players.

Closed by  Buschel
2008-03-30 10:15
Reason for closing:  Fixed
Additional comments about closing:  

#16889 and #16890

ryran commented on 2008-02-12 04:07

I just installed the latest build (still r16290) on my girlfriend’s 30GB 5.5g and reproduced the same thing. For the first time I did it while in the buffering thread screen and [when CPU wasn’t at 80MHz] could actually watch the pcm bar fall all the way to the bottom on ogg/mp3 transitions. I also for the first time was actually able to notice that the undefined instruction errors are IMMEDIATELY preceded by a data abort error–I had always been able to tell that something else flashes up on the screen before, but had never caught it until now.

MikeS commented on 2008-02-17 20:55

The “blue-screening” except when staying fully boosted really sounds like what happens if the core suspends during frequency switches aren’t observed properly. This could also be caused by switching certain other clocks but that tends to deadlock not fault.

EDIT: fix typo s/task switches/frequency switches/

I think it’s not only mp3 to ogg related as I’ve seen this happen on my Ipod Nano and I don’t have a single .OGG on it, I have a mix of mpc and mp3. So it seems to apply to Musepack ↔ Mp3 also.

ryran commented on 2008-02-25 07:38

*I CAN’T BELIEVE I DIDN’T NOTICE THIS UNTIL NOW*
On track transition _when codec-switching_ as soon as the crossfade begins the cpu locks at 30MHz–it doesn’t go back to boosted until the previous track has cleared! Duh. When crossfading between two tracks of the same type, the cpu does the proper, logical thing and stays boosted at 80. A tiny piece of information that anyone who has read all this could’ve figured for themself but it’s key all the same.

PS: My collection consists exclusively of vorbis tracks and mp3s but I took a few minutes to check a few other codecs and .. unsurprisingly it appears to not matter what. In addition to mp3 & ogg, I tested aac, wma, and wav.

Very good shot! This explains why the “device disable” builds, which were offered by soap, made this effect worse: These builds used 24MHz instead of 30MHz… Another MoB-issue?

ryran commented on 2008-02-25 15:50

Indeed. Before I started testing those builds, I hadn’t been using shuffle a whole lot (and thus, crossfade) since MoB was committed… So I kinda assumed it had to do with your power-saving work. I’m glad it doesn’t.

QUESTIONS:

1. Have you also experienced during this problem a VERY annoying, high-pitched noise?
2. Does it NEVER occur between mp3 to mp3 transitions?

I have experienced a similar problem as the one you describe, but it also happens during mp3 to mp3 transitions, presenting the high-pitched noise I mentioned. Seems to happen in transitions involving variable bit rate mp3’s

ryran commented on 2008-02-26 02:13

1.) Yes. I didn’t include that in this bug report because it has nothing to do with codec-switching – I can reproduce that on an mp3-only playlist (like you).

2.) Correct. The symptoms described here have never happened to me when crossfading between two tracks of the same format.

Thanks, looks like the problem I’m experiencing must be different

I can reproduce the stuttering in r16727 when crossfading from ogg to mp3 and vice versa. Sometimes my nano also crashes (see  FS#8787 ).

Please check out  FS#8651  for an update.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing