Rockbox

Tasklist

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

Attached to Project: Rockbox
Opened by Ryan Sawhill (ryran) - Tuesday, 12 February 2008, 00:02 GMT
Last edited by Andree Buschmann (Buschel) - Sunday, 30 March 2008, 10:15 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System PortalPlayer-based
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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.
This task depends upon

Closed by  Andree Buschmann (Buschel)
Sunday, 30 March 2008, 10:15 GMT
Reason for closing:  Fixed
Additional comments about closing:  #16889 and #16890
Comment by Ryan Sawhill (ryran) - Tuesday, 12 February 2008, 04:07 GMT
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.
Comment by Michael Sevakis (MikeS) - Sunday, 17 February 2008, 20:55 GMT
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/
Comment by Florin Popescu (florinp3) - Sunday, 24 February 2008, 21:24 GMT
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.
Comment by Ryan Sawhill (ryran) - Monday, 25 February 2008, 07:38 GMT
***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.
Comment by Andree Buschmann (Buschel) - Monday, 25 February 2008, 12:13 GMT
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?
Comment by Ryan Sawhill (ryran) - Monday, 25 February 2008, 15:50 GMT
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.
Comment by Humberto Santana (hhannah) - Monday, 25 February 2008, 15:57 GMT
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
Comment by Ryan Sawhill (ryran) - Tuesday, 26 February 2008, 02:13 GMT
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.
Comment by Humberto Santana (hhannah) - Tuesday, 26 February 2008, 05:46 GMT
Thanks, looks like the problem I'm experiencing must be different
Comment by Vlado Plaga (vlado-do) - Sunday, 23 March 2008, 17:59 GMT
I can reproduce the stuttering in r16727 when crossfading from ogg to mp3 and vice versa. Sometimes my nano also crashes (see  FS#8787 ).
Comment by Andree Buschmann (Buschel) - Saturday, 29 March 2008, 19:00 GMT
Please check out  FS#8651  for an update.

Loading...