Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#8260 - Audio skips when buffer usefl empties

Attached to Project: Rockbox
Opened by Andrea (Jag86) - Saturday, 01 December 2007, 11:09 GMT+2
Last edited by Nicolas Pennequin (nicolas_p) - Friday, 09 May 2008, 02:30 GMT+2
Task Type Bugs
Category Music playback
Status Closed
Assigned To Nicolas Pennequin (nicolas_p)
Player type iPod Mini
Severity Low
Priority Normal
Reported Version current build
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

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.
This task depends upon

Closed by  Nicolas Pennequin (nicolas_p)
Friday, 09 May 2008, 02:30 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  r17426
Comment by Jeremy Nickurak (atrus) - Tuesday, 04 December 2007, 06:14 GMT+2
Sounds like an issue I'm having on my Sansa e280
Comment by Darren Carter (darren) - Tuesday, 11 December 2007, 02:46 GMT+2
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 ).
Comment by Andrea (Jag86) - Tuesday, 11 December 2007, 10:36 GMT+2
I've read your task. Yes, probably the problems are related. I've never tried flac files though.
Comment by Andrea (Jag86) - Monday, 17 December 2007, 10:36 GMT+2
I guess r15940 has been released even for this bug, so I've tested it. Unfortunately it doesn't fix :(
Comment by Andrea (Jag86) - Friday, 21 December 2007, 11:41 GMT+2
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.
Comment by Andrea (Jag86) - Friday, 21 December 2007, 15:50 GMT+2
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.
Comment by Nicolas Pennequin (nicolas_p) - Friday, 21 December 2007, 15:57 GMT+2
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...
Comment by Andrea (Jag86) - Friday, 21 December 2007, 16:18 GMT+2
I see. Thank you for your support ;)
Comment by Andrea (Jag86) - Wednesday, 26 December 2007, 16:36 GMT+2
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.
Comment by Nicolas Pennequin (nicolas_p) - Wednesday, 09 January 2008, 01:38 GMT+2
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.
Comment by Andrea (Jag86) - Wednesday, 09 January 2008, 11:05 GMT+2
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.
Comment by Andrea (Jag86) - Wednesday, 09 January 2008, 11:56 GMT+2
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.
Comment by Bryan Childs (GodEater) - Wednesday, 16 January 2008, 22:09 GMT+2
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.
Comment by Andrea (Jag86) - Thursday, 17 January 2008, 18:56 GMT+2
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 :(
Comment by Bryan Childs (GodEater) - Thursday, 17 January 2008, 21:12 GMT+2
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.
Comment by Andrea (Jag86) - Thursday, 17 January 2008, 21:25 GMT+2
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.
Comment by Sergey Babichev (bsl84) - Sunday, 20 January 2008, 09:58 GMT+2
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.
Comment by Nicolas Pennequin (nicolas_p) - Saturday, 09 February 2008, 19:15 GMT+2
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
   revert_r15444.patch (5 KiB)
Comment by Andrea (Jag86) - Sunday, 10 February 2008, 14:48 GMT+2
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!
Comment by Nicolas Pennequin (nicolas_p) - Sunday, 10 February 2008, 14:56 GMT+2
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.
Comment by Nicolas Pennequin (nicolas_p) - Sunday, 10 February 2008, 20:55 GMT+2
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?
   revert_r15444_sync.patch (4.5 KiB)
Comment by Andrea (Jag86) - Monday, 11 February 2008, 11:57 GMT+2
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.
Comment by Andrea (Jag86) - Monday, 11 February 2008, 17:03 GMT+2
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
Comment by Steve Bavin (pondlife) - Tuesday, 25 March 2008, 13:36 GMT+2
Is this problem still occuring with a clean SVN after r16791?
Comment by Andrea (Jag86) - Tuesday, 25 March 2008, 16:09 GMT+2
I've tried r16790 and r16796, both with the same problem. So I've patched r16796, no problems.
Comment by Nicolas Pennequin (nicolas_p) - Thursday, 17 April 2008, 18:53 GMT+2
is this still a problem?
Comment by Andrea (Jag86) - Wednesday, 23 April 2008, 15:43 GMT+2
Yes, just tried r17223 and the problem is still there
Comment by Steve Bavin (pondlife) - Wednesday, 23 April 2008, 15:48 GMT+2
Andrea, please could you attach your config.cfg file?
Comment by Andrea (Jag86) - Wednesday, 23 April 2008, 16:20 GMT+2
Sure, here you are.
Tagcache and Dircache are enabled and I've already tried to disable them without success
   config.cfg (0.4 KiB)

Loading...