Sansa Fuze v1 Playback problems above build 27996

[orbidia]

If a developer wants to make a build with any modifications, I would happily test it so we can figure out what's happening.

I'm still trying the modified r28711M build and its working great after a few hours of use.

[manequin]

I have reverted all my changes and commented out this line. Unfortunately it doesn't solve problem.
Build is available here:
http://dl.dropbox.com/u/554609/Rockbox%20archive/rockbox-sansa-20100928-1400.zip

[orbidia]

Confirmed.

The build with the single line commented out does not work right.

The sound is terrible though. One thing I notice is that the sound on FLAC is unplayable but with MP3s it sort of plays garbled.
Does playing Flac files take more CPU power/memory than playing MP3s?

More testing - everything acts the same. When I fast forward/rewind, there seems to be a bit less "crazy random numbers" in the status "played/remaining time" fields.

What procedure is possible to narrow down what the problem code is?

We seem to have narrowed down the bad code change between r27996 and r28000. I think it would be beneficial to narrow down exactly what the very last stable version before there was a problem.

So if r28000 was stable and r28001 (tested to be bad) was totally unusable, then the differences between those builds are where the problem exists. I don't have r27997, r27998, r27999, r28000 or r28001. But I remember testing r28001 and I know it was bad so I deleted it hoping the next day it would be fixed...

Manequin, can you post the official r28000 and r28001 build so I can test that and be sure that was the problem jump?

How much changed from r28000 to r28001? If we narrow this down to a single build, we should be able to work out the exact problem.

[manequin]

I have already tested revisions from 27995 to 28001. I couldn't make a patch without it . In 27999 everything was ok, 28000 was first build that stopped working properly on my hardware. If someone wants to check this on his own hardware, builds from unpached source are available here:
http://mpiesio.pl/sansa-fuze/unpatched/rockbox-27999.zip
http://mpiesio.pl/sansa-fuze/unpatched/rockbox-28000.zip

[saratoga]

I have already tested revisions from 27995 to 28001. I couldn't make a patch without it . In 27999 everything was ok, 28000 was first build that stopped working properly on my hardware. If someone wants to check this on his own hardware, builds from unpached source are available here:
http://mpiesio.pl/sansa-fuze/unpatched/rockbox-27999.zip
http://mpiesio.pl/sansa-fuze/unpatched/rockbox-28000.zip

If you go into the debug menu and turn up the boost counter to 1 so that the CPU is always boosted, do it solve the problem without needing to patch anything?

[manequin]

I have tried this already and it doesn't help.

[darlredfish]

I tried 28000 with and without setting the boost counter to 1 and got the crackling with both, I then tried 27999 and was working fine either way.  So 8000 seems to be where my playback problems started as well.

[orbidia]

Well, I think at least we have a bit of consensus about where the problem code was inserted.

Official r27999 works perfectly stable on my "difficult to please" fuze v1.
Official r28000 is unusable. When I try to play Flac files, it is all garbled. All the same problems from my original post.

When I go to the debug mode with r28000, for CPU frequency setting, at first I see:
Frequency: 62000000
boost_counter: 0

A first, I couldn't figure out how to change the setting to 1.
So I just started pressing each button quick/long press. Turn the dial etc.
Finally I think there must be a way to select the it (press play/pause 'Up?') and then turn the dial to make the change. It doesn't seem like anything is selected.

And immediately, the 1 was flashing with all kinds of huge numbers.
It would show:
boost_counter: 1 (about half a second)
boost_counter: 1207753193 (very quick flash of the number - i think that was the actual number because it would repeat randomly often enough but its hard to follow because it flashes too quickly.)
boost_counter: 1 (about half a second)
boost_counter: 1186775311  (very quick flash of the number - close to the one that flashed but not exact. They all seem to be 10 digit numbers.)
boost_counter: 1 (half a second)
boost_counter: 1203651191  (very quick flash of the number)
etc.
The frequency of the flashing is about 2-3 times per second. It also seems like its actually only flashing about 5 specific numbers. They all start with either 118xxxxxxx or 120xxxxxxx

This is very difficult to change the number for some reason - the dial doesn't work and if the screen blanks out, when it goes back, it is at 0 again.
I see, I just have to turn the dial to bring the screen back and still have the option selected. continuing...

Also, with boost at 0 it is always: "Frequency: 62000000"
The moment I change boost to 1, it shows:
Frequency: 248000000 (3-4 seconds)
Frequency: 143xxxxxxx (REALLY FAST BLINK - 10 digit number that seems to start with 143 but it blinks so fast I can't be sure - seems like the last digit is always an even number 0, 2, 4, 6, or 8 )
Frequency: 248000000 (3-4 seconds)

The flashing  of the frequency number is much slower than the boost_counter number. The random frequency flashes once every 3-4 seconds.

This time, the screen went blank and I had to reboot...

If I keep turning the scroll wheel counterclockwise, the main boot_counter setting will increase 1 every few seconds of turning the wheel. I spun the wheel for about a minute and I got it to read out like this:

boost_counter: 28 (about half a second)
boost_counter: 1186775311  (very quick flash of the number - close to the one that flashed but not exact. They all seem to be 10 digit numbers.)
boost_counter: 28 (half a second)
boost_counter: 1203651191  (very quick flash of the number)

If I scroll clockwise, the setting will decrease by 1 every few second until it gets back to 0 and seems stable (no blinking).
The actual quick flashing numbers seem to be the same 5-6 specific 10 digit numbers that start with either 118 or 120. The flashing numbers and frequency of the flashing seem to be the same for settings 1 and above.

------

A few of these other settings in the debug menu also seem to have oscillating numbers:
For example in: View I/O Ports
[DBOP_DIN]
DBOP_DIN: 887F (starting number)
If I turn the wheel or click any buttons, it will change to
DBOP_DIN: C87F
But sometimes, E87F or A87F will flash briefly.
All other numbers on that screen are solid.

On View Hardware Info:
MMU:    on CVDDP: 12000 (flashes 12025 2-3 times a second or more if use scroll wheel.)

------

At least we've settled on the build that the faulty code appeared. So what could it be in r28000 that is bad? What other tests can we do to find the problem?

Note: if it would help, I could probably figure out exactly what all of the flashing numbers (possibly using video and pausing to see the number clearly). Is that worth the effort or is this just a random by product of the bad code?

[saratoga]

^^  You don't need to describe the debug menu, we've all used it before.  Just state the final out come, did setting the boost counter to one to disable frequency scaling improve playback?  A simple yes or not will work . . .

[orbidia]

With Official r28000 and boost_counter setting: 1, everything is unusable and the audio is garbled plus all the other weird stuff described in the first post.
With Official r27999 everything works perfectly.

What I was describing was the crazy effect increasing the boost_counter had immediately on the setting screen itself...
Just changing the setting to 1, everything gets very weird.
I thought some of the actual weird numbers that were being displayed would help with the debugging.

[orbidia]

I just tested the latest build r28217. It still has all the same problems. Flac files play back sounding terrible on my fuze.

2 other Fuze v1 owners have reported similar problems (and I have more than one fuze v1 which exhibits the problem!). The problems for the other posters also starting exactly with build r28000 as well! I don't know what other proof is needed that something bad happened with r28000 and the bad code is in all the builds since then.

I understand that Manequin made a non-official build which reverted only the r28000 changes but kept the code for the later builds. And everything works perfectly with that non-official build. It fixed all 3 users problems.

I'm sure there are others who are having subtle problems as well but they may just be getting little annoying pops in the audio or something which they aren't even aware is caused by the bad code introduced in r28000. The problem does affect some fuze v1s more than others - I don't know why.

How can this be fixed with the official current builds?
We've identified the exact build the problem began in (r28000)... What else can I do to help fix the problem so the current build can be used?

Is this going to still be a problem when the next "Stable" rockbox version is released?

[funman]

Please move discussion of this bug on Flyspray