Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#10115 : playback of FLAC files on iRiver iHP-120 and H320 pauses periodically



FS#10115 - playback of FLAC files on iRiver iHP-120 and H320 pauses periodically

Attached to Project: Rockbox
Opened by Mark Nipper (nipsy) - Thursday, 09 April 2009, 14:57 GMT
Last edited by Boris Gjenero (dreamlayers) - Friday, 08 May 2009, 04:45 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System Iriver H100 series
Severity Low
Priority Normal
Reported Version Version 3.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


This has happened a decent number of times on both players when playing back FLAC files. Unfortunately, it's not consistent either. I've had a song pause for a few seconds during playback in a spot, rewind after the song finishes, and the next time through it plays through the entire song with no stutters. I got my H320 first, but within a few songs of using my iHP-120 I also just got, this problem happened.

I searched elsewhere and didn't see any mention of this. I'm not sure if it's a general Rockbox issue across players or specific to the iRiver players. Let me know if I can do anything to try to help debug this. I thought it also might have been just the hard drives in the units delaying playback while they were trying to spin up or some such, but I'm not sure how much Rockbox is caching during playback and what the drive activity looks like during normal usage.

It's worth mentioning that no other plugins were running at the time of these incidents. I've got a minimal installation on both players.
This task depends upon

Closed by  Boris Gjenero (dreamlayers)
Friday, 08 May 2009, 04:45 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in r20747
Comment by Frank Gevaerts (fg) - Thursday, 09 April 2009, 15:16 GMT
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.
Comment by Mark Nipper (nipsy) - Thursday, 09 April 2009, 15:19 GMT
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.
Comment by Boris Gjenero (dreamlayers) - Friday, 10 April 2009, 16:46 GMT
When this happens, is the hard drive spinning up to read more data? Does the anti-skip buffer setting help?
Comment by Mark Nipper (nipsy) - Friday, 10 April 2009, 16:53 GMT
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?
Comment by Frank Gevaerts (fg) - Friday, 10 April 2009, 17:11 GMT
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.
Comment by Mark Nipper (nipsy) - Friday, 10 April 2009, 17:22 GMT
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.
Comment by Frank Gevaerts (fg) - Friday, 10 April 2009, 17:28 GMT
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.
Comment by Mark Nipper (nipsy) - Friday, 10 April 2009, 17:33 GMT
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).
Comment by Boris Gjenero (dreamlayers) - Thursday, 16 April 2009, 20:14 GMT
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.
Comment by Mark Nipper (nipsy) - Thursday, 16 April 2009, 21:41 GMT
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).
Comment by Boris Gjenero (dreamlayers) - Friday, 17 April 2009, 00:56 GMT
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 , , 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.)
Comment by Thomas Martitz (kugel.) - Friday, 17 April 2009, 05:33 GMT
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 :/
Comment by Nils Wallménius (nls) - Friday, 17 April 2009, 11:47 GMT
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.
Comment by Boris Gjenero (dreamlayers) - Friday, 17 April 2009, 13:52 GMT
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.
Comment by Boris Gjenero (dreamlayers) - Sunday, 19 April 2009, 19:43 GMT
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.
Comment by Mark Nipper (nipsy) - Friday, 24 April 2009, 18:35 GMT
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.