MK2 w/2.00b3

When first activating a playlist on the player, the first track begins playing, and the sound is very jittery (stop-start-stop-start..) as the hard drive whirrs away, presumably doing read-ahead. If I pause until the drive stops being accessed, and then continue, no more jitters. Ditto if I just backarrow to replay the once-jittered song after the drive stops seeking.

More jitters whenever the drive is active, such as after hitting the forward arrow a couple of times to seek to a tune not currently buffered.

WAIT.. this is with the voladj kernel loaded.
I'll re-insert the original v2b3 kernel and retest.

Edited by mlord on 18/10/01 06:12 PM.

Okay.. it happens with the stock kernel too.

To hear jitter, I have to hit the track-fwd button until I can hear the disk seeking (my ear against the player on the desktop) while it plays a track .. tons of interrupted segments of music whenever the drive is seeking about.

Playlist size doesn't matter either (I originally thought it did).. thousands or 8 tracks in the playlist, doesn't matter.

Ugh.

Okay.. I went into emplode and nuked most of my (rather large) custom playlists, sync'd, and..

The player locked up solid afterwards.

So, power-cycled, and now.. no more jitters (so far).

I'll try re-adding my playlists again now.

UPDATE: my (huge) custom playlists are back in,
and the player is (so far) jitter free. Go Figure.

Could this be another symptom of player's tune buffer space being somehow eaten up (see Leaky Player thread)?

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

I think the "Leaky Player" thing looks more like an attempt to seek to a timecode value inside a VBR MP3 file that doesn't exist. Memory leaks do not usually announce themselves so politely, in my experience

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

I think the "Leaky Player" thing looks more like an attempt to seek to a timecode value inside a VBR MP3 file that doesn't exist. Memory leaks do not usually announce themselves so politely, in my experience

I agree about the politeness of memory leaks, but the tunes in case are CBR. Also note the line

VM: killing process player

and

Abnormal player termination

Player received signal 9

(Aha, it would not necessarily mean exhausted memory; but then, the signal that killed it was SIGKILL, not SIGSEGV or SIGBUS...) I am puzzled . Let's hope guys@empeg are not.

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

When first activating a playlist on the player, the first track begins playing, and the sound is very jittery (stop-start-stop-start..) as the hard drive whirrs away, presumably doing read-ahead. If I pause until the drive stops being accessed, and then continue, no more jitters. Ditto if I just backarrow to replay the once-jittered song after the drive stops seeking.


I'm noticing this on the initial load of the player from a cold boot state.

As well...

I've noticed it once or twice when I completely dump the players memory and have to reload from disk. Everytime it's happened, the Disk indicator is accessing. Casual playing doesn't seem to cause it, but if it appears like if the player needs alot of data, the decoder takes a second place...

A KILL -9 to a process is the uncatchable kill, and in this case it's being sent by the system itself to the player. The system component responsible is the Virtual memory manager (VM) so you may be right about the leak after all - it only does a kill on the process if it's own process swapping is being threatened.

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

Exactly. The player gets killed by VM manager using SIGKILL because memory got eaten slowly, as opposed to being killed using SIGSEGV or even SIGBUS, which usually happen when derefferencing a pointer with wildly wrong content.

But, how come that memory stays 'eaten' after the player restart? Is it possible that something else eats it (I am running virgin system currently)? Perhaps player leaves behind shared memory segments or something. Let's check...

Well, I tried to run the player from the shell, but is soon got blocked. Perhaps I used the wrong option for 'don't open the serial port'. Anyway, it stopped when its status line on VFD displayed

Starting server...

What server!?

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

IIRC, the VM just picks a process arbitrarily to kill -- it's not fussy. Obviously, on the empeg, there's not a lot running, so statistically, it's gonna get the player.



-- roger

IIRC, the VM just picks a process arbitrarily to kill -- it's not fussy. Obviously, on the empeg, there's not a lot running, so statistically, it's gonna get the player.

I am not sure for Linux, but on some other Unices that is difinitely tha case. Moreover, in my case player got killed again seconds after restart. So, either the player requested all of the memory immediately, or something else ate it. Since I am running a 'virgin' system for the moment, the question is: what else could be allocating the memory?

I am not familiar with particular implementation of threads, but see that multiple player threads each have their own PID. Is it possible for threads to die/be killed independently leaving their brethern behind as garbage? Does the player use shared memory segments that it could fail to deallocate in the moment of death (though I don't know why should it if threads share address space).

BTW, the bug from Leaky Player? thread has not reappeared, so it might be related to a particular tune. Of course, I failed to note the tune playing when it happened...


Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green