I have a MK 1 player and I get long pauses between tracks (after scrolling through 3 the 4th will pause). Really it can be even more frequent than that. I have been getting used to it, but does anyone else have this behaivior? Fixes? Suggestions?

This is expected behaviour. The player caches the bulk of the track that you're listening to, and the start of the next couple (depending on size/memory availability). If you skip tracks, there's generally enough cached to allow playback to start while spinning up the disk.

However, if you skip too many tracks, it's necessary to spin the disks up in order to get the data for the next one. This is probably what you're seeing.

If you go to the player configuration dialog in emplode, you can turn on the disk icon on the player. This will make what's happening more obvious.


Roger - not necessarily speaking for empeg

This depends on the definition of "Long".

To me, the "normal behavior" pauses are quite short. Can you be more specific about the length of the pauses? If they are excessive, it might be indicating some other problem.

___________
Tony Fabris

Yeah. Fair point. How long are these pauses? Up to 5 seconds is about what I'd expect in this situation.


Roger - not necessarily speaking for empeg

My Mk1 never pauses for that long when I skip past the cache. A couple seconds at most.

___________
Tony Fabris

No, I am seeing pauses of up to 5 seconds. And no matter how many times I hit the forward button during the pause, it will only skip 1 song further. I keep the player on now and next visual, and see that I want the 4th song listed...no way will it let me get there. I have to skip 2, wait 3 secs and then hit it again to get to the next song.

Hmm.

Roger says 5 seconds is normal. He's the expert...

Question, though: did this only start happening recently, or has it been that way ever since you got the player? Your description of the Emplode problems in another thread makes me start to get suspicious...

___________
Tony Fabris

Try putting the empeg into pause first. This stops it having to cache the first bits ot the next tracks and allows you to scroll through the playlist faster. There shouldn't be much pause at all when skipping though tracks when paused. I know this isn;t the solution but it will show if the operation is normal.
I agree, 5 seconds should be normal when jumping multiple tracks.

Murray 06000047
Just increasing my post count

The delay depends on what type of disk(s) you've got -- some spin up faster than others.

You can't continue skipping tracks until the disk's spun up, because it's synchronous. Pausing removes the need to spin the disks up, so you can generally keep skipping.

In v2.0, track skipping is asynchronous -- it'll attempt to spin the disks up when you stop skipping tracks, and decide what you want to listen to.


Roger - not necessarily speaking for empeg

He might be the expert, but I've never had this problem.. usually by the time I've skipped past the cache the disk is spun up and the delay is very minimal. When skipping 1 - 3 tracks ahead (or is it 5?) there should be no delay whatsoever, as the starts of those tracks are already cached.

If this isn't the case I would suggest there could be something up with the player.

Rob

Greetings!

Another thing: what software are you running? Do you have any custom settings or running any background software? If you have any memory reserved so the player can't use it, you may make less memory available for caching.

Can you run a system / memory test and see if anything looks "interesting"?

Paul G.
SN# 090000587 (96GB Smoke)

Alright, I did some testing, and the time it takes is in between 2-5 secs, and 5 RARELY happens. So this sounds like normal operation. It is too bad that the memory is soldered on, otherwise I would upgrade.

As for programs running in the background...nada. The only alteration of my Mk 1 is the 4V input jumper switch, and the Startup Image. Everything else is stock. I also have the 4GB unit...so spinup times are probably not that fast.

Thanks for your help!

The mk1 can actually go to 16mb (there are pads for another 4 chips under the board), but you'd need a custom version of the player software & kernel to get this working.

v2.0 improves this as you can skip ahead faster than the disk, and still see track titles, etc. When you settle on a track it'll then cache and start playing it.

Hugo

Hugo, is this kernel readily available, and is the ram available as well? If this is all it takes to increase the cache that can be used then I say I am game to try it out! Or am I going to have to send it in to service to have this done?

Jason
#00018

No, it's not available and is unlikely to become available. You could modify the kernel, but modifying the player might be rather more of a problem. The chips are also no longer made and so might be hard to track down!

Hugo

If there was space for the 16MB of ram...why wasn't that put into the initial design? I can see that the player works magnificently in it's current state, so I would assume it would have been overkill and unnecessary. But if it can limit
the latency, I would think it might be something you would have wanted to do.

In any case, thank you for letting me know, and it is too bad I couldn't just plug a simm in there, but the player works great regardless!

Thanks Hugo!

The memory size of the Mk1 player was determined by the availability of RAM chips at the time of the manufacturing run.

In any case, it sounds like your problem will be solved when software 2.0 comes out.

___________
Tony Fabris

Any timeline speculated with the v. 2.0 release? Also, I saw that someone posted the screenshots, then they were deleted for the emplode software. ARe those available for viewing anywhere?

At the time, the 8MB of dram we had cost us something like $20 or $30 (no, really... would have been cheaper for us to buy simms and desolder the chips).

There was no room for the other chips on the top of the board, and doing 2-sided SMT would have put up the build cost hugely. So we put the pads on there but never fitted chips. They've never been tested, but should work in theory.

We ruled out simms because of (a) space and (b) vibration.

Hugo