This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11608 - Fuze v1 playback issues
Attached to Project:
Rockbox
Opened by Orbidia (orbidia) - Tuesday, 07 September 2010, 01:42 GMT+2
Last edited by Fred Bauer (freddyb) - Tuesday, 07 December 2010, 16:45 GMT+2
Opened by Orbidia (orbidia) - Tuesday, 07 September 2010, 01:42 GMT+2
Last edited by Fred Bauer (freddyb) - Tuesday, 07 December 2010, 16:45 GMT+2
|
DetailsSansa Fuze v1
Build r27996 r28001 and r28016 A few days ago, I installed the new 2.0 rockbox firmware on the fuze so that I could use the USB mode and not go into the official firmware anymore. The USB mode seems to work well enough. But in build r27996 the thermometer indicating the playback position in the song did not work when using many of the themes (XL Fuzed for example). So then I tried r28001 and r28016 the next couple days. Now, not only does the playback bar not work, but a lot of the time, the 320 mp3 files don't play back at all. If I first turn on the player, and try to play a song, it works okay. But if I stop the song and try playing another song, often it will just show 0:00 for elapsed and 0:00 for remaining and nothing happens. One time, the song did play but the numer for time elapsed remaining kept jumping to random numbers. Also, the battery gauge would jump between 98% to strange random numbers above 10000% It crashed once just trying to playback. I've tried the last could builds on 3 different fuze v1 and they all had similar problems. I'm back to r27996 because at least it plays the music. It seems something generally broke in the last few builds and I was just trying to report the specific problems in case no one was aware of them. |
This task depends upon
Closed by Fred Bauer (freddyb)
Tuesday, 07 December 2010, 16:45 GMT+2
Reason for closing: Fixed
Additional comments about closing: Fixed in r28616 by switching CPU to asynchronous mode when boosted.
Tuesday, 07 December 2010, 16:45 GMT+2
Reason for closing: Fixed
Additional comments about closing: Fixed in r28616 by switching CPU to asynchronous mode when boosted.
- playing a track
- stopping with long play
- playing another track from the filetree
With r28016
Also force CPU frequency to 284MHz in debug menu and see if it helps
"Data abort
at 30688D00
FSR 0x8
(domain 0, fault 8)
address 0xEA000002"
Actually installed rockbox version: r28060
BTW Where can I find older daily builds? Current stable (3.6) unfortunately has broken recording - http://www.rockbox.org/tracker/task/11548
For daily builds go to "current build" on the left of website and then "Daily builds", but they only go back to 4 days.
Can someone who experiences the problem make his own build and then look for the address of data abort in the .map files?
I am pulling code from svn now, and I will be learning to compile it in few minutes, if I succeed, I will search for the addres you wrote about.
PS I'm sorry if there are mistakes in my posts, english is not my native language.
FS#11533. Builds before that commit seem to work fine.However, as I don't have access to my computer and no regular access to the internet at the moment, I cannot nail it down to a specific revision.
Does this happen on all your ogg/vorbis files or just some? Are they very low bitrate?
It's on all my ogg files. Most of them I encoded myself with ~256 kbps VBR. I also tried samples from http://nigelcoldwell.co.uk/audio/ and all of them were played as noise too.
I've got r27995 from Manequin and it was almost good. Most of the time it worked well, but sometimes it just suddenly played noise instead of music. But if I rewinded track a bit it was back to normal.
It was random - the same track sometimes played without any problems and sometimes it broke.
There is one more symptom - at the begining of each track elapsed time shows random numbers and then after a while (2-3s) it's back to normal. It didn't happen in r27995.
I'm also using r27995 and have similar issues as Jakub. I guess I'll have to convert all my files on player to mp3 for some time :/
BTW you can save your modifications like this:
$ svn diff > ~/backup.diff
$ svn revert -R .
$ patch -p1 < ~/disable_cpufreq.diff
......
$ svn revert -R .
$ patch -p0 < ~/backup.diff
r28000 introduces problems on several individual targets. Somehow those problems are not reproducible by the main developer for this target. Therefor he cannot fix those issues right now. This can happen.
r28000 was made to reduce the power consumption of the target and allows higher battery runtime.
So, it is finally a question whether our Trunk focusses on stability or runtime for the discussed target.
I would prefer stability over runtime for all users. A patch that allows better runtime could be provided for those who are able to build rockbox on their own and who are not affected by the issue described above in this flyspray entry. The flyspray entry that contains such patch can be used to find a solution that also works for the users with a problematic hardware.
If there is no consens the final decision should be made by the rockbox steering board. That's what it's for.
also i think trunk is for developers, not stability
USB was disabled for several targets (sansas PP? also ipods?) in releases but left activated in trunk so development could continue
-> we can do the same thing
Also please don't mention the RSB because I take that as an insult
The RSB is only needed when there is a conflict and I see no conflict here, only developers who were not aware of this bug report, but nobody looked like they had a problem with me (and i certainly don't have a problem with the other devs)
(BTW thanks for trying to sum this up, it can be useful since the information was spread on this bug report, the forums, the mailing list, and in my head)
Please keep this bug for technical discussion.
If you have a problem with me not wanting to revert r28000 then it's not a technical issue and should be brought to the mailing list (not the forums because they are much harder to follow)
My 2 Fuzev1 work fine with mp3 and vorbis
Sorry, if you got this wrong. I definately do not want to insult you -- I just wanted to search for a way to receive a general guideline how to proceed with stability vs. functionality.
Btw, you mentioned the USB thing. An idea to cope with issue might be to make a release w/o r28000 and keep r28000 on Trunk. Or -- even more -- to revert it on Trunk until 3.7 has been delivered.
Maybe we can discuss and decide this in irc very quickly :)
Last non-technical post from my side in this thread.
One of them in particular does not work well at all with the r28000 changes.
Flac playback on this player is totally distorted with beeps and buzzing. Also I get a lot of very strange number flashing as described in the original post.
Maybe some people can try this:
Start a Flac song playing and simply fast forward through a bunch of the song and then rewind to near the beginning. On my player, it may seem to be alright at first but after 5-10 times of FF/Rewind, random large numbers start flashing where the Played Time/Remaining Time is located.
I also detailed how changing the CPU frequency itself with r28000 and up immediately causes weird random numbers on the setting screen.
And then it will usually crash later with a similar report as Manequin.
Funman, if you would be willing to test it out, I don't mind sending you my "bad apple" Fuze v1.
E-mail me to discuss that option.
Hopefully, the issue can then be resolved before the final Rockbox 3.7.
I'm not working on this bug anymore, ask Llorean or rasher on IRC to see this bug fixed.
Also ask them if they can fix it without reducing the battery life of some hours. Short answer: they can't.
Battery life is important of course, but it's for nothing when most of my music can't be played.
If it help to narrow it down to some particular batch - mine is BH0807AXWK-4GB.
orbidia: do those fuzes run with the same settings? If not, what are the differences?
I realize Rockbox developers put a lot of time and energy into coding rockbox.
We users truly appreciate all the hard work. Its a wonderful piece of software. I love Rockbox Fuze so much, I bought 7 of them (many gifts) because me and my family plan on using them for many years. Between the sound quality of the Sansa and the Rockbox software, I don't need any of the new touchscreen stuff which is all the rage.
***** Without Rockbox, the Fuze would be pointless. *****
I could probably just use the Official r27999 or Manequin's later build with reverted changes and not bother upgrading ever again. I guess I could have just not said anything and been happy enough. I wasn't trying to cause upsetment.
But I guess I still want to use future Rockbox versions...
One of my Fuzes doesn't exhibit the problem. But when I played around with it, I did manage to make it glitch in a similar manner to my Fuze that does show the problem. I wouldn't have even noticed it if it wasn't for my "Bad Apple" Fuze. So I suspect this problem could be causing slight problems for some people but they are unaware of it. It is true that 3 different people are reporting problems that exhibit similar but different symptoms stemming from the same battery life code. Unfortunately, its not consistent so it will be more difficult to track down - especially when a developer apparently doesn't have a fuze that exhibits the problems!
Now, I personally haven't had a problem with the battery life on the Fuze. It could always be better but I'm satisfied enough. But I'm assuming a lot of work went into the code to make the battery life longer. I assume that's where the tensions come from.
I'm sorry that there are Fuzes out there that don't work well with the battery life savings.
If it turns out to just be a bug in the battery life savings code and it can be fixed - great! But if its something particular to a bunch of Fuzes and we can't use Rockbox on them... well, I'd rather have a lower battery life.
What to do?
If Rockbox 3.7 is around the corner, I don't understand why the battery savings code would still be included when more than one person has reported some bugs from that specific code. I'm sure a bunch of people who don't run daily builds will suddenly have problems with the Rockbox 3.7 "Stable" release. I guess that depends on how many "bad apple" fuze v1s actually exist.
Obviously, I'm all for Rockbox 3.7 without the battery savings code.
If the developers want to put the code back into the daily builds so people can test for a fix. I don't mind that at all. I guess I'll be happy enough as long as the Stable versions work correctly. But if the developers don't have a "bad apple" fuze to test... nothing will get fixed. It seems we're between a rock and a hard place.
I'm sure my Fuze v1 is one of the worst offenders. So the most I can do is offer my "bad apple" Fuze v1 as a loaner/trade to a developer. I could also shoot video and post on youtube or something if that would help.
If it helps, my fuze v1 batch is BI0910BMYK-8GB
Where do we go from here?
arg, my fuzev1 doesnt have any problems with svn also
When I test them, I just delete the entire .rockbox folder and copy the latest build over. So they would all be running the same default settings.
I believe I tried both the old firmware and the new USB enabled firmware and they both had the same problems.
I'm beginning to wonder if this has something to do with the quality of the battery itself? Like there's a threshold where on some players, the battery is not supplying enough juice with the new code? So maybe the memory generates errors which eventually corrupts and crashes the player. I don't know - this is just an idea. I guess the answer would be in exactly what the r28000 code changed in rockbox? And apparently, it has something to do with battery life savings.
I have one fuze that works quite well and one that works very badly. I think my sister has one that was also quite buggy. That's when I thought they all worked badly (but I was wrong about that). I haven't tested above r27996 on my Mom's or the other backup fuze... (That's all five Fuze v1 that I have available.)
Mine (working fine so far) is BH0806AXWK-4GB, so it's quite close.
I compiled r28220 myself, renamed .rockbox to .rockbox_old and installed the new .rockbox (So I've got default settings, and did the first tests using that, but have since changed theme & font).
BH0805AVUK-4GB - r28235
In Rockbox, you could also try to go to:
System -> Debug -> CPU Frequency
and change "boost_counter:" from 0 to 1 or above. On my Fuze, with r27999 and below it is stable. But with r28000 and above, I immediately get crazy flashing numbers on the setting. I described it in detail in my forum post Reply #22: http://forums.rockbox.org/index.php?topic=25809.15
Could this problem be that as the battery gets old, it puts out a bit less voltage and battery life savings code makes it unstable? Even more significant to the "oldness" of the battery would be how often it was used, how it was charged, etc. Some people have a better battery charging regimen than others.
If that is the case, then potentially all the Fuzes will react badly with that battery saving code as the battery gets older... So it may be that my battery has been more abused than others? This could be possible.
So a couple more people have reported having the problem. Manequin already made an unofficial build which fixed the problem. What is happening with the official builds? Will at least Rockbox 3.7 have a fixed version?
Reverting the commit that broke this isn't really a fix as it seems noone understands why it broke stuff on only some fuzes, that said, the release will probably have that commit reverted unless a proper fix is implemented.
Thanks for responding.
The "lower voltage" battery idea was just pure speculation on my part. Its too bad noone knows why the battery optimization code doesn't work properly on some fuzes.
Either way, if Rockbox has a proper "fix" or it just has "reverted" code, I look forward to when the official builds (or final v3.7) will work properly for me again.
Hopefully, someone reports here when a change has been posted in the official builds regarding this problem so I can try it out.
Obviously, the developers have already worked out the possibilities, so I'll just let it go now.
I have tested a variety of Ogg Vorbis audio, from Q7 files both encoded by me and by Jamendo to 22050Hz 56kbps podcasts, and they all sound like this:
http://dl.dropbox.com/u/389421/r28288-ogg.ogg
MP3 audio doesn't seem to be problematic, nor do the other codecs, but I haven't throughly tested them.
I will try to test other formats and see if there is any influence there and report any observations here.
All my AMS players work fine, so I can't test.
I repeatedly received a "Divide by zero at 30687778" error when trying to write wav, with or without dsp, although not at the same place.
Also, before crashing the progress indicator displayed weird stuff like "( of 188080", "- of 188080" or a very large integer, abnormal values which were "corrected" when the progress indicator iterated.
Upon reboot, the test.wav file is always 0 bites in size.
As to the contents of floor1.c, the C code in there is way beyond my skills, but the only explicit division that I could find and for which the divisor could be zero is in render_point(), line 197.
Could you try test_disk and see if that works?
Also, it might be neat to know if WAV files played on the device sound as bad as compressed audio.
It looks like the noises and pops are greatly aggravated compared to regular playback, you can hear it here:
http://dl.dropbox.com/u/389421/30sec_ogg_test.ogg
In the mean time I've managed to pull down the audio files that are used for the codec benchmark and test them. This is what I've found:
64aache gives a "codec failure" immediately after starting playback. test_codec->write wav ends in about one second with no error message, and the resulting wav file also contains about one second of audio.
ape_c1000 - ape_c4000 all give white noise when played back. With test codec I got mixed results. Several times it locked up the player with no error message. One time ape_c3000 resulted in a "Divide by zero at 30681A84", which corresponds to "0x30681168 entropy_decode" from apps/codecs/libdemac.a(entropy.o). When ape_c3000 and ape_c5000 succeed, and the wavs were white noise, solid for c5000 and with short interruptions for c3000. You can hear the resulting audio below, but set the volume *VERY LOW* before opening them.
http://dl.dropbox.com/u/389421/ape_c3000_test.ogg
http://dl.dropbox.com/u/389421/ape_c5000_test.ogg
Musepack resulted in an error each time. The error messages were the same for playback and test codec, and they didn't change with subsequent runs.
mpc_096:
Data abort at 30680FCC
FSR 0x8 (domain 0, fault 8)
address 0xB0689689
mpc_128:
Data abort at 306814EC
FSR 0x8 (domain 0, fault 8)
address 0xB0689FC2
mpc_170:
Data abort at 306814EC
FSR 0x8 (domain 0, fault 8)
address 0xB068B441
mpc_224:
Data abort at 306814EC
FSR 0x8 (domain 0, fault 8)
address 0xB06893A0
mpc_300:
Data abort at 306814EC
FSR 0x8 (domain 0, fault 8)
address 0xB06897FC
mpc_350:
Data abort at 30681B6C
FSR 0x8 (domain 0, fault 8)
address 0xB068D831
All the errors correspond to "0x30680dbc mpc_decoder_read_bitstream_sv7" from apps/codecs/libmusepack.a(mpc_decoder.o)
For the other files/codecs playback seems to be ok, but I didn't do a very through check, nor did I try test codec.
I don't know what to make of this, but it doesn't seem to be related to the audio output side.
I have been playing with Rockbox 3.7 for about an hour now. I don't know if there was a fix or a revert to the r28000 problem code for the Fuze.
All I know is that I have the latest stable version. When I boot up, I see Ver. 3.7 and everything is VERY STABLE. I've tried a number of FLAC tracks which had major problems playing back on the builds over r28000. The sound is now as phenomenal as I expect from Rockbox.
I also tried the FF/RW trick and I don't get any weird numbers at all in the Played/Remaining Time fields as I described in the original post.
Everything works great again.
If the problem was corrected with a revert, and someone wants to try to actually fix the original battery saving code, I will be happy to test any build to make sure it works on my particularly sensitive fuze v1.
I just wanted to say Thank You for making Rockbox and also especially Thank You for resolving this specific problem for r3.7.
Quote:
"Comment by Rafaël Carré (funman) - Sunday, 12 September 2010, 17:07 GMT+1
Please detail what happens.
Also force CPU frequency to 284MHz in debug menu and see if it helps"
FS#11597). On mine the mp3's play ok but vorbis is messed up.Thanks a lot Fred!
Does this mean the "async fix" is contained in the current builds?
I'm testing the current build r28650 and everything seems ok.
So if re28650 has the battery saving optimizations of r28000 but uses the async fix, then I guess this is a true fix if it works for everyone else.
The question is:
Does putting the fuze in async use up more battery life than the r28000 optimizations saved?
Are there any other side effects of async operation?
So I think you may have fixed the problem.
Maybe we can all now enjoy the effort Funman put into the battery life optimizations.
But it still needs to be tested whether async cpu with battery optimizations (r28650 and greater) has better or worse battery life than sync without battery optimizations (Rockbox 3.7).
Also it should be tested if there are any other side effects of async operation - although I haven't seen any yet with somewhat brief testing. I will continue stress test different things like crossfeed/eq with FLAC etc which will load up CPU cycles.
What is the most stressful situation in Rockbox for the CPU? Just load up all the audio filters possible and play a demanding FLAC? Would that be a good way to test?