Rockbox

I've had this a few times on my gigabeat F. My guess is that the bitrate guessing for flac is sometimes off a bit so the codec doesn't get asked for more decoding in time, but I'm not a specialist in that area.

Yeah, I wasn't sure if I should file this under playback or codecs, since it seems specific to FLAC thus far. But I've only ever used MP3 and FLAC files thus far, so I didn't think that was necessarily representative. Good to hear though it isn't just the iRiver hardware.

When this happens, is the hard drive spinning up to read more data? Does the anti-skip buffer setting help?

I'm not sure. I'll have to try to catch it next time it happens.

I found that option under Settings -> Playback Settings. It's just a list of times. Is there a default setting? Mine just starts at the top of the list which is 5 seconds. And what is the risk of using the largest value (10 minutes) if any? Will I exhaust the player of memory? If there is no risk, shouldn't the default just always be 10 minutes?

I've set the anti-skip buffer to 30s a while ago, but of course now I can't remember if the last time I had a file skip was before or after that...

Mark: the reason it's not set to 10 minutes is that the bigger you set it, the more often the player has to read data from disk, which eats battery.

That's an interesting paradox seemingly. You want an anti-skip buffer so that you don't have to worry about the drive being busy the second you need data. But having a really large anti-skip buffer also means that you cannot spin down the drive like you'd think you'd be able to, since it's constantly trying to keep the buffer full I assume. It seems like the preferred behavior might be to fill the anti-skip buffer and then spin down the drive until you reach 95% of the buffer being exhausted, at which time, you spin the drive back up and fill it again. Of course, this only really gets you anything for rather long buffer times.

That's actually more or less what happens. The disk spins up, and the buffer is filled up to (100% - antiskip). How much that means depends of course on the amount of RAM and the bitrate of whatever you're playing, but it should be well above 90% on most players.

The default appears to be 5s then since the list shows up with a time highlighted from what I selected previously. I'll bump it to 30s and see if it makes any difference (since the pause I am hearing is only ever a few seconds in length).

When this happened, did the FLAC file have an associated CUE file?

I was just playing an MP3/CUE album on my 5G 30GB iPod running r20715, and I had a pause near a transition between tracks in the CUE file. The hold switch was on and the LCD was sleeping. I immediately went to the buffering debug screen. The buffer was about 2/3 full, so it probably wasn't being filled when the pause happened. When I went back and listened to the transition a second time, there was no pause.

I do not use CUE files at all. I tried bumping up the anti-skip buffer to 30s on both my iHP-120 and my H320 but i still hear skips occasionally. I don't have any skips at all on my Sansa C250 and the anti-skip option isn't present at all there (I assume because it's flash based).

I think I see the problem:
1) The anti-skip buffer setting is ignored. It leads to an audio_set_buffer_margin() call in apps/playback.c, which assigns the value to "static size_t buffer_margin". However, that variable is never used. I think it should be used in set_filebuf_watermark(). So, the buffer margin is always just disk spinup time rounded down to the nearest second, plus one second.
2) In set_filebuf_watermark(), I don't like "size_t bytes = id3->bitrate * (1000/8) * seconds;". Sure, the math is correct, but what about when you have a VBR file, and the part at the end of the buffer is at a higher than average bitrate.

You can go to "System -> Debug (Keep Out) -> View buffering thread" to see how the watermark is low and unaffected by the anti-skip setting. There I also watched how MP3 data runs out and the PCM buffer starts getting low as the drive starts to fill the buffer.

I'm attaching a simple patch which uses buffer_margin in the set_filebuf_watermark() calculations. It doesn't do anything about issue 2. Any suggestions regarding that?

Edit: Looking at changes in  FS#9703 , http://svn.rockbox.org/viewvc.cgi/trunk/apps/playback.c?r1=19685&r2=19743 , I am reminded of another issue: the watermark can be bigger than the buffer. I'm now playing a FLAC file on my iPod with 32 megs RAM, and the anti-skip buffer is set to 10 minutes. The watermark is 44 megs, and the hard drive is constantly spinning to keep the buffer full. Everything seems to work, so I guess this could be considered a feature and not a bug. Any comments?

(In my last comment I was probably wrong about there not being a spinup at that point. There wasn't a full buffer of MP3 data left at that point, so the buffer wouldn't have been full after being filled. I also looked at the CUE code and it seems that it couldn't have caused the problem, especially while the LCD is sleeping.)

I noticed the bug about buffer_margin some time ago, yes and pinged Zagor about it (who made the bitrate based watermark). No-one bothered to fix it so far :/

The purpose of the anti skip buffer setting is really to avoid skips in situations where the disk might need extra time to read such as a lot of vibrations.
The regular watermark should be high enough to avoid pauses even without the anti skip buffer setting when the disk can read normally.

Note that the minimum and default anti-skip buffer setting is 5 seconds. So, if the anti-skip buffer time isn't added, the watermark is too small even with default settings. If you want no skipping even without the anti-skip buffer time added, see my point 2) above. The calculation is only really leaving enough data in the buffer for the spinup time at the average bitrate of the file. That's barely enough even for CBR files. Maybe it should multiply by twice id3->bitrate on VBR files?

I think use_buffer_margin-v2.patch should be committed. I will do that in a day or two if nobody gives any reason against it. If anyone wants to commit it sooner, go ahead.

I committed a new version of the use_buffer_margin patch in r20747. I am leaving this task open for now because I don't have an iHP-120 or H320. If you have either of those devices please report here on whether the pauses are gone now.

For what it's worth, I haven't heard any skipping on my H320 since this patch. I moved the anti-skip back to the default 5s also. I'll report here if I hear anything else.