Rockbox

Tasklist

FS#11139 - music pause on buffer refill - FS#10919 not completely solved

Attached to Project: Rockbox
Opened by Ronald Malbosc (Chiyo-chan) - Tuesday, 23 March 2010, 10:26 GMT
Task Type Bugs
Category Music playback
Status Unconfirmed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Hi,

I think that the problem reported on  FS#10919  is still here, or at least not completely solved.
But now, I get the feeling that the pause only happens when the buffer refill is triggered via a track skip. During normal playback, it don't seem to happen any more.

The build I tried it on is r25249.

TIA
This task depends upon

Comment by Torne Wuff (torne) - Tuesday, 23 March 2010, 13:09 GMT
Er, are you skipping past the end of the buffered data?
Comment by Ronald Malbosc (Chiyo-chan) - Tuesday, 23 March 2010, 13:42 GMT
Here is the feeling I get: where there is only a partial track remaining in the buffer, if you let it play normally, it'll play flawlessly, but if you try to go to the next track, the playback will pause.
Comment by Torne Wuff (torne) - Tuesday, 23 March 2010, 17:01 GMT
That's normal (and unavoidable)... if the next track is not buffered yet, then skipping to it will cause an immediate rebuffer, which will include a delay (how long depends what kind of disc you are loading off, whether you have dircache enabled, etc). How else is it supposed to work?

If you let it play normally it starts to rebuffer shortly *in advance* of running out of data, so that there is no gap..
Comment by Ronald Malbosc (Chiyo-chan) - Tuesday, 23 March 2010, 17:26 GMT
It would be normal if the pause was before the next track start.
But I forgot to mention that the pause occurs after a few hundreds ms of the next track.
The action to go to the next track when the next track is not buffered is a little longer, so I presume it's doing something on the disk.
It plays a few hundreds ms of the track, then pause and resume.
Once or twice, I got the feeling that these few hundreds ms were pure audio garbage, but most of the time it's really the start of the new track.

It's exactly the same symptoms that the one I described in  FS#11016  (which was a duplicate of the  FS#10919  I mentioned when opening this bug) excepts that it not longer occurs on normal playback refills.
Comment by Ronald Malbosc (Chiyo-chan) - Tuesday, 30 March 2010, 07:49 GMT
Using the patch I made to get info on the remote (my h300 is in my bag when I'm listening ^^), I've made a few progress into reproducing it.
In fact, it's getting stranger.
If I understand correctly, the 'track count' under the buffering thread debug screen counts the number of track currently in the buffer, including the one playing.
Meaning that 1 means that the next song isn't buffered yet.

The strange thing is that the music pause happens when you skip to the next track when the track count is showing 2.
Then the next track plays for half a second then playback pause and shortly after the status bar shows that rockbox is reading something from the disk.
After that, going to the buffering thread debug screen shows that the buffer is now filled.

When skipping to the next track when the track count is 1 doesn't produce this pause.
The next track skip is a little longer to kick in though, probably waiting for the buffer to have a few pieces of the next track.
Comment by Ronald Malbosc (Chiyo-chan) - Wednesday, 31 March 2010, 09:35 GMT
I've made another interesting dicovery (well maybe it's not really a discovery, I tried to search the wiki about the buffering thread and the returned pages are 3 years old ^^).

The first buffer fill, the one that occurs at startup) and the next ones (buffer RE-fill) don't do the same thing.
The difference lies in how they treat the last track, the one that doesn't completly fit in the buffer.

The first buffer fill will fill the buffer with as much data as possible while the buffer re-fill will simply put a really small part of the track in the buffer, leaving a relatively big part of the buffer empty.
I'm saying that it put a really small part because it would explain the track count being 2 just before AND the few hundred ms I can ear before the playback pause.

Since I've already discovered that this playback pause happens when I activate DB + dircache + WPS with an unicode font (see  FS#11016 ), it should be interesting to see how buffer re-fill works then.
Comment by Ronald Malbosc (Chiyo-chan) - Wednesday, 07 April 2010, 07:12 GMT
I've updated the build on my player monday evening.
The bug is still here.

I've discovered another interesting thing : when dircache is deactivated, the buffer re-fills work as the first buffer fill, meaning that the last track (the one that doesn't fill entirely) gets partially (more than a few ms) buffered.
Comment by Ronald Malbosc (Chiyo-chan) - Friday, 09 April 2010, 20:17 GMT
I tried to make a build with logf support, but something must have gone wrong.
The 2 log entries show in debug screen (show & dump), but none of them seem to work.
show log only clears the screen & dump shows a splash saying that the log file was dumped, but I can't find any file name logf.txt.

Something special needs to be done ?
Comment by Ronald Malbosc (Chiyo-chan) - Friday, 16 April 2010, 12:31 GMT
Another interesting discovery : when tagcache is crashed but dircache is ok, the buffer re-fills works like the first buffer fill.
Comment by Ronald Malbosc (Chiyo-chan) - Monday, 19 April 2010, 07:31 GMT
I though that the first buffer fill is OK because tagcache is still in its initializing stage and not ready yet.
Comment by Ronald Malbosc (Chiyo-chan) - Tuesday, 20 April 2010, 08:05 GMT
All the previous tests where made with tagcache loaded to ram.
This time I tried to disable this (load tagcache to ram): the re-fills worked has it should!
Comment by Ronald Malbosc (Chiyo-chan) - Tuesday, 20 April 2010, 21:46 GMT
Well I must have been sleepy when I made the tests of my previous post.
tagcache not loaded to ram exhibits the same symptoms that when loaded to ram.
Comment by Ronald Malbosc (Chiyo-chan) - Thursday, 22 April 2010, 15:02 GMT
This morning, with tagcache not loaded to ram, it did work as intended.
Comment by Torne Wuff (torne) - Friday, 21 May 2010, 15:40 GMT
I managed to reproduce this, but I can't come up with a consistent way of doing so.

It *looks* like it happens when you skip ahead to a partially buffered handle (i.e. when track count is 2) and the skip results in the watermark for rebuffering being passed; if so, then the problem should happen less often if you use a larger value for the antiskip buffer (as this makes the watermark higher). It won't eliminate it, though, if you have long tracks or switch codecs mid-playlist or similar...

I could be wrong though.

Loading...