It's not faster than before, but now splay uses the same trick like all other decoders which uses less than 15% on a P166. (eg: x11amp,freeamp,kmp3) When decoding an mp3 which is passed to /dev/dsp you can sleep while the sample is played. The decoder simply calls a usleep(x) until the sample is played. This is the reason why "top" thinks it uses less cpu times. Now kmpg uses the same trick like freeamp,x11amp,kmp3.
"top" shows that kmpg uses much memory. But thats only the underlying implementation of POSIX threads in linux. It shows for every thread the memory usages of the "global" application. Each thread only adds 10 KB of memory. So nothing to worry about.
Inter process communication. If you klick in kfm on a mp3 it is inserted in the playlist. But The ipc stops you from starting new kmpgs as seperate processes. Release it and you can start kmpg as a single process. The "new player" does not create kmpg as a process but as a new instance in the current process. You need "new player" if you want to mix mp3.
- If you want to hear musik: close the ipc forever and start a new kmpg process.
Thats a drawback of the "sleep trick". The splay decoder does not know about it that the pcm data is written to the hd. (which is faster as the /dev/dsp) But in fact the threaded buffer in splay is a bit smarter. He only calls usleep if a small buffer of 12kb if filled. (8kb socket buffer and 4 kb internal audiobuffer). The threaded ringbuffer in kmpg (its has a size of 1mb) tries to empty this as fast as possible, thus it should be considerably faster, but not as fast as it could be.