Playback problems: mid-song skip

[jmr]

Player: Sansa Fuze V1
Rockbox Build r27166-100628

As of late (sometime after the release of 3.6, I can't pinpoint which build) I've been encountering sporadic playback glitches.  From time to time, mid-song, my player will jump to another song from the same drive for what I'm guessing is the length of the playback buffer, before returning to the original song.  The affected MP3s are seemingly random, and it doesn't happen all of the time; if I cycle the power and start an affected song over, it plays through fine.

I've noticed that if it happens in a song more than once, it always 'jumps' to the same song.  Also, if a mid-song jump occurs, it is often followed seconds later by a ~0.25 second skip ahead.

I formatted the player last night (using the OF) and reloaded all of my songs (again, using the original firmware), but it's still happening. 

As luck would happen, this glitch happened again as I was typing this post:

-shuffling through all songs in my database:
listening to 'Soft and Common Grave'  - CBR 192 MP3 on internal memory
at 0:33 - jumps to middle of  'Who Needs Sleep'  - VBR 196 MP3 on internal memory
returns to normal at 0:34
0:53 - jumps to 'Who Needs Sleep' again, this time slightly later in the song.
returns to normal at 0:55
1:33 - minor skip in song
I restarted the player and loaded 'Soft and Common Grave' again, this time it played through without issue. 

EDIT: It's also REALLLLLY annoying when it jumps from a quiet song to a really loud one, as it seems the replay-gain value doesn't get affected... my player just jumped from a quiet piano number (replay gain of -.80 db) to a Yakuza Heart Attack song (which has a replay gain of -17.25 dB).  Frightened the, err, crap out of me.

[funman]

This is a known issue, check today IRC logs for how you can help

[suprman2020]

Has this issue been fixed? I reverted back to 3.6 because the problem started getting real annoying.

[mannequin]

yes, it seems to be a serious issue, at least on my Fuze. does the "original" 3.6 release work OK cause i can't pinpoint when it started either.

[funman]

It's still being investigated

3.6 should be ok, I don't know what "original" 3.6 is so I can't tell about it

[bor_ka]

I believe I've got this problem - been discussing it with ranma on IRC for some days.

To be short - I've added code to panic if the incorrect sector was read from the internal memory. It 100% panics with the 4bit wide mode.  Detection was based on "watermarks" (in fact, just sector numbers) added to every sector of selected files. Build 27064 and earlier seems to be unaffected. 27065 and later - affected. Building in thumb mode resulted in more glitches / panics.

Solution is to work with quarter clock (instead of half clock) for internal memory, as was proposed by ranma on irc. Tested about 40 songs where there were panics - all clear.

P.S. Since ranma is busy until the next week, can anybody test this patch http://pastebin.com/iwYJykKb ?

P.P.S. I've made some disk tests.

4bit and quarterspeed
test_disk SPEED TEST
CPU clock: 62000000 Hz
--------------------
Create:  20 files/s
Open:    50 files/s
Dirscan: 5927 files/s
Delete:  29 files/s
--------------------
Create (512,A): 114 KB/s
Write  (512,A): 120 KB/s
Read   (512,A): 582 KB/s
--------------------
Create (512,U): 117 KB/s
Write  (512,U): 119 KB/s
Read   (512,U): 585 KB/s
--------------------
Create (4096,A): 814 KB/s
Write  (4096,A): 899 KB/s
Read   (4096,A): 2960 KB/s
--------------------
Create (4096,U): 914 KB/s
Write  (4096,U): 918 KB/s
Read   (4096,U): 2866 KB/s
--------------------
Create (1048576,A): 955 KB/s
Write  (1048576,A): 965 KB/s
Read   (1048576,A): 3271 KB/s
--------------------
Create (1048576,U): 543 KB/s
Write  (1048576,U): 559 KB/s
Read   (1048576,U): 3200 KB/s

no 4bit and halfspeed
test_disk SPEED TEST
CPU clock: 62000000 Hz
--------------------
Create:  19 files/s
Open:    48 files/s
Dirscan: 5534 files/s
Delete:  30 files/s
--------------------
Create (512,A): 145 KB/s
Write  (512,A): 144 KB/s
Read   (512,A): 551 KB/s
--------------------
Create (512,U): 149 KB/s
Write  (512,U): 149 KB/s
Read   (512,U): 548 KB/s
--------------------
Create (4096,A): 674 KB/s
Write  (4096,A): 684 KB/s
Read   (4096,A): 2128 KB/s
--------------------
Create (4096,U): 744 KB/s
Write  (4096,U): 745 KB/s
Read   (4096,U): 2092 KB/s
--------------------
Create (1048576,A): 831 KB/s
Write  (1048576,A): 828 KB/s
Read   (1048576,A): 2298 KB/s
--------------------
Create (1048576,U): 654 KB/s
Write  (1048576,U): 616 KB/s
Read   (1048576,U): 2275 KB/s

[ranma]

I still think this is possibly timing-related and the real bug may be elsewhere.
I'm going to look for a fuze on ebay, so I can try to reproduce this problem myself.

[bor_ka]

Ranma, apparently, the bug is not 100% reproducible, since funman, for example, haven't seen it with his fuze v1. So, the chances are good, that you will not reproduce it either.

Can I help debugging it? No JTAG, though

[BJH]

I can observe the same kind of glitches as described by jmr on my Clip+. Firmware is r26960. Seems to happen on internal memory and sd-card.

[funman]

BJH, your problem is not related to this thread.

The Clip+ and Fuzev1 use different code so please report it on the tracker

I have disabled wide bus again in r27495 so read corruption should be gone completely

[BJH]

funman, I'll try a current build before writing a bug report, it may be fixed already. Just thought it could be helpful to pinpoint the problem, since the symptoms are exactly the same...

[ranma]

Ranma, apparently, the bug is not 100% reproducible, since funman, for example, haven't seen it with his fuze v1. So, the chances are good, that you will not reproduce it either.

Can I help debugging it? No JTAG, though

We'll see, I had a successful bid on a 4gb fuze v1 on ebay earlier today.
How exactly did you implement the read check?
IIRC you said you added the sector number to each sector (at the end?)?
Doesn't that affect the playback and directory reading etc. quite badly?

[bor_ka]

I implemented the sector check in this way:

First of all, I added watermarks only to the mp3 files: I knew the album and songs, where skips happend. So, I wrote a small program to read fat, walk through the file's sectors and change them. I used cygwin and some direct fat access library. It was hell, since I was fighting with cygwin and this library bugs. The code is terrible (since I had not written a line of code for ten years or like), but if you are interested, I will send it to you. It took the most time

The next thing I made I looked up starting clusters of my "test" files in the disk editor and used it as a condition in fat.c to check only them on read (didn't want to panic on non-watermarked files). For some reason letoh32 wasn't working for me, so I made manual le int reading. Like this http://pastebin.com/Z8EYHMVE

I added this guard after two transfer()s in fat_readwrite().


And yes, it did affect the playback very badly - I wasn't able to listen to the watermarked files But it wasn't needed, since there were easily detectable panics instead of audible glitches.