Rockbox Technical Forums
Support and General Use => Audio Playback, Database and Playlists => Topic started by: littlenick on February 23, 2010, 01:52:49 PM
-
Hi,
I am new here and not really a techie ( :-[).
Just (barely) managed to get rockbox (version r 24861-100222) on my iriver h120. While mp3-files play without a hitch (so far)
Rockbox version r 24861-100222 gives me a gap in the middle of the song when spinning up the disc to fill the buffer when playing back ogg-files (ca. 220-280 kbps). So I am getting gapless playback between the songs, but new gaps every 15 min or so when the hdd spins up!
Your help is being appreciated - cheers!
Thomas
-
If it happens only when the disk spins up, then you need to increase the anti-skip buffer length setting, under Playback Settings. Try increasing it gradually until the skips go away.
-
Hi torne,
thank you for your answer. The Rolling Stones run o.k. with a 15 sec. Anti-skip buffer but my Buddha Bar Vol.2 still has a gap in the middle of a track even with the anti-skip buffer increased to a 5 (!) minutes (both were ripped with the same audiograbber settings (.ogg quality 8.30 -> ca. 254 kbps, actually often closer to 300 kbps).
Does Rockbox really rebuffer only so scarcely before the end of the buffered data so it uses the anti-skip too? Never had this problem with mp3 files.
Any other ideas?
The same files used to play without any undue problem with iriver firmware (but of course used to have this annoying gap in between two tracks).
By the way - isn't there a trade-in for using excessive Anti-Skip-Buffers?
-
The anti-skip setting determines the point at which rebuffering begins. If you select 5 minutes, then it should rebuffer when there is 5 minutes of compressed audio remaining, so as long as it doesn't take more than 5 minutes for the disk to spin up and return data... :)
Your results suggest to me that the things which work OK with a 15-sec anti skip threshold are indeed just skipping for that reason, and you should probably leave it on 15 seconds. The tracks which still have skipping issues with a 5 minute threshold must have a different problem... Does the skipping still occur at the same time as the disk spins up, or is it just a random skip in the music mid-track?
And yes, the higher you set the threshold, the more often rebuffering occurs for the same amount of data, so the battery will run down faster. Setting it to 15 seconds will not have a measurable effect on overall battery life for lossy codecs (it might possibly if you use FLAC/etc, but you'd have to measure it to see).
-
The Rolling Stones run o.k. with a 15 sec. Anti-skip buffer but my Buddha Bar Vol.2 still has a gap in the middle of a track even with the anti-skip buffer increased to a 5 (!) minutes (both were ripped with the same audiograbber settings (.ogg quality 8.30 -> ca. 254 kbps, actually often closer to 300 kbps).
Does Rockbox really rebuffer only so scarcely before the end of the buffered data so it uses the anti-skip too? Never had this problem with mp3 files.
Any other ideas?
Is the gap always at the same place in the song?
-
Correction to my previous post:
The gap does occur both with .ogg and mp3 files!!!
It was just that I didn`t perceive it before when listening casually while doing the dishes in the kitchen.
The gap is an estimated 0.5 to 1 second in length and occurs (starting the music from a "fixed" point like the beginning of a folder) always at the same point of the song. It occurs only during rebuffering - probably due to the preferred kbps-rate I use - at approximately 15 minutes after starting the playback and then the next gap occurs approximately 15 min. later, when the second rebuffering is due - wherever in the track this is.
The gap is unaffected by anti-skip buffer - that is, it occurs in the same way whether anti skip is 5 sec or 5 min.!
Album art is not an issue, since most of my files don´t have any. Just mention this because on a different forum I've read that album art was supposed to be the reason for skipping (?!). I rip my CDs with audiograbber - enter the respective song titles manually or from a database, which a friend of mine installed on my pc
Anyway - the gap occurs also with music files (mp3) I bought through commercial download from a renowned internet online store :o);.
Hey - am I the only one ever to experience this? It's really a pity I started on rockbox a couple of days ago and already was beginning to become a big fan. Or is it hardware-related?
-
If it happens with all files its probably something wrong with the hard drive. Maybe a failing motor that makes it take a very long time to spin up.
-
Most recent update on the issue of gap on rebuffering:
The gap occurs also on a friend's river ihp120 (same rockbox version).
While the gap occurs the run-time counter seems to halt for a moment (?) - although I wouldn't swear by it.
Both players work perfectly normal with normal iriver firmware.
The gap occurs with the following file types:
mp3 - files from CD-ripping with audiograbber 1.83 encoded by LameEnc DLL Version 1.32 (24/9/2008) Engine 3.98; settings: VBR = 0, joint stereo;
ogg-Vorbis files from CD-ripping with audiograbber 1.83 encoded by Ogg Vorbis Official dll's; quality setting: 8.30;
mp3 - files bought from an online store; VBR quality ca. 256kbps on average;
wma - files from CD-ripping using windows media player (could be version11 or higher if I remember it right); 192 kbps CBR;
The gap does not occur (well I could not yet detect any although I've tried) with mp3 files I generated via line-in (old-vinyl records) using an iriver h340 and original iriver firmware; record-setting: CBR 256 kbps;
The only difference of conceivable importance I can think of is that line-in files have a duration that is longer than playback of a buffer-filling.
The gap also does not occur anymore after enabling crossfade (I used "mix" as fade-out mode).
I am talking here about a gap that occurs somewhere in the middle of a track (well - wherever rebuffering occurs).
Of course this is not a cure I seriously consider for listening to Beethoven sinfonies.
Am I the first one to report this issue?
Has anyone made similar observations?
Anyone here who can help me?
Cheers!
Thomas
-
It happens to me, too. Version 3.4 did not have this, but now I get it even with mp3. When the buffer is almost empty and the HDD starts spinning to read and fill it up, it looks like it should start a couple of seconds earlier to prevent this from happening.
-
I hesitate to add to this discussion because I've not done any quantitative analysis at *all* but I've had this on my iPod Video since updating to 3.5 from 3.4. It doesn't happen on every rebuffering, but I have a mix of ogg and mp3 files so it is possible that it only happens on oggs. I have not modified my playback buffer because, frankly, it doesn't bother me that much. I also get a quarter- to half-second pause and it's always while the hdd is running. It's right in the middle of the buffering, or perhaps right at the start. Playback resumes before buffering is complete.
I will pay more attention to the types of files, and their bitrates, from here on out and report accordingly.
-
Just collecting codecs/etc is not likely to track this problem down. More specific information is almost certainly needed: we need an exact procedure to reproduce it. If you are just playing mp3/ogg/etc you are doing more or less the same thing as the vast majority of users (including me) so that's not really enough.. (I haven't had any gaps).
Do any of you know how to use the buffering status debug screen? Can you set the anti-skip buffer to a long time (such as five minutes) and then watch the debug screen while that time approaches, and see what happens? When there is five minutes of data remaining, it should spin up the drive, and then start to refill the buffer at that point. Specific observations on what happens here, and when the skipping occurs in this sequence, might help us track down what's going on.
Yotto/kpapr1: you need to try increasing the anti-skip buffer setting. If increasing that setting a little makes the problem go away, then your disk just spins up too slowly for the default value and you do not have the problem being discussed here. There is only a bug if the problem persists when the anti-skip setting is already set very high.
-
I have found this: If I set anti-skip to 15s then the problem is not solved. HOWEVER, if I also set the spindown time to 20s then the problem is gone. Can you peole try it and see if this works for you, too?
Thanks
Costas
***************** UPDATE *****************
It also works with spindown time of 16s but NOT with 15s or less
-
Does it matter what you set the anti-skip buffer time to? i.e. if you put it back to 5 seconds, but leave spindown on 20 seconds, does that work?
-
No, I tried it and it doesn't work. It has to be 15s, it will probably work with more, but not with less.
-
The interesting thing is that the spindown time is supposed to be irrelevant while buffering. The disk does not spin down while buffering is in progress, and when buffering completes the disk spins down immediately regardless of time.
What about if you set the anti-skip buffer to something larger, like 1 minute, but leave the spindown on 20 seconds? I'm wondering if perhaps it is not correctly inhibiting the automatic spindown...
-
I tried a 30s anti-skip with 16s spindown and it failed from time to time. I also tried a 30s anti-skip with 31s spindown and after many test it did fail on one occasion. However the 15s anti-skip with the 16s spindown works fine till now.
-
It happens on my H120 too. This with a low-bitrate file, needing 10-15% boost to play (using default settings). It looks like the codec thread is blocked from reading while the disk spins up, causing the PCM buffer to run dry. That enabling crossfade fixes it makes sense then, since the PCM buffer is much larger in that case.
It wouldn't surprise me if this affects most/all swcodec targets with a hard drive...
-
A possible explanation, but that doesn't explain why this has only happened recently :(
I changed the ATA driver recently-ish, but the changes would not cause spinup to take longer, or affect whether the driver yields...
-
I think I found the problem, and the fix is in r24968. Haven't looked up when it was introduced though.
Edit: It was introduced in r23680.
-
So if the issue is new and didn't exist in version 3.4 the solution would be easy:
Just where can I find version 3.4 please? In the old releases archive I found only things related up version 2.5.
I am really embarrassed to ask so stupid questions.
-
Try a current build as Lear thinks the problem has been fixed.
-
Aha, I had noticed that usefl didn't update any more in the buffering status... well done Lear
-
There's now an stable release update to fix this