I am running rjlov's dynamic volume adjustment "release 1.0 kernel for Mk1 players" on my empeg and I experience a very annoying pause between tracks.

I notice the pause occurring if I listen to the majority of an average length song then advance to the next track... the pause occurs if I advance one more track, sometimes lasting 2-3 seconds. Has anyone experienced this? Does this happen with the empeg 1.0 release?

Thanks.

Craig Elliott
elliott@g-cnet.com

There can be a pause if you outrun the software's read-ahead cache. This is most likely not caused by Rjlov's kernel (although if Rjlov's stuff screwed something up, in theory it could alter the cache behavior, but I don't think he screwed anything up).

The pause is normal in cases where you skip ahead more than one or two songs. However, if the pause consistently happens every single time you hit the "next" button, then you might be looking at disk troubles where it's having a problem filling the cache. Can you give ups more details about how to induce the pause problem?

___________
Tony Fabris

The caching algorithm (to explain it simply) reads the bulk of the track that you're listening to, and some of the start of the next track. This is so that if you skip a single track, there's no pause.

If you skip two tracks, it has to spin up the disk in order to get the music. This will cause the behaviour you describe.

Obviously, the caching algorithm is more complicated than that, but you get the idea.


Roger - not necessarily speaking for empeg

Something else I thought of...

Whether or not it pauses for a long time is going to depend on whether the disk drive is spun up or not. For instance, if you tell it to skip ahead but the disk is turned off, it will have to spin up the drive before it can get the next file. This can definitely take a couple of seconds. But after the disk is spun up, it will remain spun up for a little while as you settle on a track to listen to.

If you want to watch this behavior in action, turn on the disk indicator icon (it's an option in Emplode).

___________
Tony Fabris

I'm sure it caches more than one track ahead - I thought it stored the starts of several tracks ahead and a couple behind, such that the disk would usually be spun up by the time you ran out of data when skipping multiple tracks.

Rob

It just might be possible for the code I've put in to lose a block of audio (about 1/40 of a second) if the player is having trouble supplying enough data. Nothing of the order of 2 seconds, though.

Richard.

Maybe there's something amiss, but my player will pretty clearly not have the start of the next track cached some of the time.

More specifically, when one track finishes and the next one starts, there's a window of several seconds where the player is playing from cache, but the disk hasn't even started to spin. If you hit 'next' then, you'll get a pause.



-Zandr
Mk.I #150
Mk.II #39

The mk2 caches 2 (3?) ahead and the current track - we dropped the "track behind" caching as it was almost never used. The mk1, as it has less memory, just caches the next track.

Hugo

Ahh! So there would be a concrete advantage to extra memory on the Mk 1

Assuming of course that the use of extra memory isn't locked out by a kernel/application compilation time difference?

... and I do use track behind; I thought it had got slower using this (sob)

One of the few remaining Mk1 owners... #00015