- Status Closed
- Percent Complete
- 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
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.
2008-03-30 10:15
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
#16889 and #16890
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
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.
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.
*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?
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
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#8651for an update.