Rockbox Development > New Ports
Sansa Fuze+
pamaury:
Indeed, I can reproduce it with long names, thanks for noticing. That should help me hunt the bug !
megal0maniac:
The WPS issue also presents itself when the track coming up has a long name.
Garbage audio
This is what I have.
For reference sake, the song is called Austere by The Joy Formidable.
There is no pitch change from the original.
To reproduce this issue, I play any of the songs from this album. The files themselves are fine and play everywhere else. (including Rockbox on my Clip+) The tracks are MP3 VBR, ranging from 170 - 200 kbps.
The strange thing, is that after you play one of these files, the phenomenon occurs with every other mp3 file you play afterwards.
The only way to fix it is to restart a couple of times (shut down properly, then turn back on) or I've found that it stops when playing a FLAC file.
I have gotten these "problem files" to play correctly on my Fuze+, but I'm not sure how.
This has been an issue since a build which was current in Early Jan.
Also, sometimes when playing FLAC, the player suddenly freezes.
Unfun :(
EDIT: Also, that spike on the left channel as the track starts is non existent in the file.
pamaury:
I think I have fixed the WPS issue. Please test and report back. I will try to reproduce the sound issue but I haven't run into it so far.
Is it consistently reproducable ? Can you provide a file for us to test ?
megal0maniac:
It seems to be, just by playing the file. Or any of the files from the album.
I just haven't been able to find out exactly how to make it go away.
I'm busy uploading a file, it lives at http://atinyhedgehog.za.net/03-the_joy_formidable-austere.mp3 :)
Left the filename intact just to be safe. Haven't had much time to play around.
Post Merge: February 02, 2012, 03:43:41 PMWPS issue seems to be sorted. A little glitchy when the title first appears, but hardly anything that needs to be fixed.
What was wrong?
pamaury:
The bug is briefly explained in the commit message: I used the data co-processor to copy some pixels but my implementation yields during the copy instead of busy waiting. And during that yield, another screen update might occur resulting in some registers of the lcd being changed before sending the data to the lcd. One solution could be to use a mutex but I preferred to simply replace the use of the co-processor by a call to memcpy.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version