Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To
    nicolas_p
  • Operating System iPod Mini
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Jag86 - 2007-12-01
Last edited by nicolas_p - 2008-05-09

FS#8260 - Audio skips when buffer usefl empties

My iPod mini 2G has a problem with MP3s playback (I’ve only tried MP3s). After about 4-5 tracks, audio skips for about a quarter of second (sounds like a glitch), doesn’t matter where the playback is arrived. However in the buffer debug menu I found that the skip occurs when the bar “usefl” is near to zero and it’s going to refill with new data of next songs in playlist. I’ve tested the r15857, but it’s from about the r15840 that the problem occurs.
One more thing, sometimes audio skips even when I add some songs in the current playlist while playing other files.

Closed by  nicolas_p
2008-05-09 00:30
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

r17426

atrus commented on 2007-12-04 05:14

Sounds like an issue I’m having on my Sansa e280

I’m having issues with my 4G iPod Photo. Seems to be buffer related as well, and also occurred around the same rev. I posted a bug ( FS#8296 ).

Jag86 commented on 2007-12-11 09:36

I’ve read your task. Yes, probably the problems are related. I’ve never tried flac files though.

Jag86 commented on 2007-12-17 09:36

I guess r15940 has been released even for this bug, so I’ve tested it. Unfortunately it doesn’t fix :(

Jag86 commented on 2007-12-21 10:41

I tried r15806, with a fresh install, since Darren has said it goes well for him. The problem is still there. I’m gonna try older releases and report.

Jag86 commented on 2007-12-21 14:50

Uhm, nothing. Tried r15731, the oldest available. Maybe it’s really a problem related with MoB, but it’s just a guess. I should try the release just before MoB, but I don’t know where I can find it.

I think we can safely assume it’s MoB related. After the big commit there were some changes in how these situations are handled. I guess it’s a matter of perfecting the refilling behaviour, so there’s no need for you to go to too much trouble finding the particular revision it started with…

Jag86 commented on 2007-12-21 15:18

I see. Thank you for your support ;)

Jag86 commented on 2007-12-26 15:36

Ok, I found out that the bug has started from the r15444, which doesn’t introduce any change on buffer managing but on disk spinning as far as I understood. In my opinion, MoB isn’t the real cause of this bug.

This issue seems to be related to thread priority and chunksize. A temporary workaround is to set the default chunksize in buffering.c to 32k instead of the current 16k. However the real solution is to make thread priority dynamic to prevent the codec thread from starving the buffering thread.

Jag86 commented on 2008-01-09 10:05

Uhm, I will try this workaround with one of the most new releases (currently I’m using r15443). For the complete solution I trust in your capacitites because I’m not so good in programming even if I partially understood what you mean.

Jag86 commented on 2008-01-09 10:56

I’m sorry, I’ve tried temporary workaround but it doesn’t change anything :( I’ve noticed one more thing though: from r15444, in debug menu, under “disk info” section, the voice “Spinup time” is always more than about 1300ms, while for older releases (such as 15443 I’m using) it’s about 400-500ms. Maybe this is not important, it’s just another info.

The testing that I’ve done into this issue seems to suggest that the level of stuttering increases with the depth of the directory tree that the music files are buried in.

I made a test directory off the root of the player with around 70 files in, and couldn’t get any stuttering at all when playing back the files in it.

When I moved the entire directory to about four folders deep into my music hierarchy though - the stuttering was apparent straight away.

Jag86 commented on 2008-01-17 17:56

Thanks for your suggestion Bryan, I’ve tried to put about 10 tracks in my iPod root with the last release, but the problem still occurs :(

What sort of tracks were they? (MP3, FLAC, WMA, etc.)

I’ve only tried this with “reasonable” quality MP3s (vbr, around 192kbs), and I *cannot* get my ipod to stutter if the tracks are just off the root.

Jag86 commented on 2008-01-17 20:25

I’ve tried only MP3s encoded with lame 3.93 with V0 (about 260kbps) placed directly in root. However, with releases older than r15444 and with Winamp/foobar they play well.

bsl84 commented on 2008-01-20 08:58

I confirm this or very similar bug on X5, not on IPod

After booting RB or select track from file browser very frequently there are very annoying stuttering, pauses for 2-3 seconds, play for second, again pause and so on for 30-50 seconds.
When I switch to debug|view buffering thread there are near empty buffer filling (second and third line). CPU is running at 124 MHz instead of 45.

Builds before near 1 of october 2007 does not have such behavior.

It has been reported that this issue started with r15444 [1]. Here is a patch that reverts r15444. Please try it out and tell me if the issue disappears.

[1] http://svn.rockbox.org/viewvc.cgi?view=rev&revision=15444

Jag86 commented on 2008-02-10 13:48

Ok, I tried r16258 + this patch and the bug’s finally gone away! Furthermore I tried r16267 and 16258, both without patch, to see if the bug was resolved by something else, but the sound glitches were still there.

Important: from r16259 some changes in “firmware/target/arm/ipod/power-ipod.c” were introduced, so if you try to patch newest releases it shows errors in some code lines.

I can confirm that this bug was introduced with r15444.

I wish to thank NicoP and all other people for their precious help!

The problem is that this patch can’t be considered a proper fix, as it introduced useful changes. We still need to find why these changes caused undesirable side effects.
I’ll sync it later today.

Here is an update which isn’t quite a sync, as one hunk was removed. Could someone try this patch against a recent SVN and tell me if it still solves the problem?

Jag86 commented on 2008-02-11 10:57

I’ve tried r16276 + 2nd patch and it works. However I’ve seen there’s been a recent change in “firmware/drivers/ata.c” with r16278 and I haven’t tried it with or without patch yet. I’ll test it later today.

Jag86 commented on 2008-02-11 16:03

Tested r16280 without patch, there’s again the bug.
With patch r16280 works well, even if it shows 2 warning messages while patching file ata.c:

Hunk #1 succeeded at 950 (offset 1 line)
Hunk #2 succeeded at 1156 (offset 2 line)

I’ve checked this file and it seems that patch is applied though. Maybe just a matter of offset in code lines

Is this problem still occuring with a clean SVN after r16791?

Jag86 commented on 2008-03-25 15:09

I’ve tried r16790 and r16796, both with the same problem. So I’ve patched r16796, no problems.

is this still a problem?

Jag86 commented on 2008-04-23 13:43

Yes, just tried r17223 and the problem is still there

Andrea, please could you attach your config.cfg file?

Jag86 commented on 2008-04-23 14:20

Sure, here you are.
Tagcache and Dircache are enabled and I’ve already tried to disable them without success

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing