I can't see that the ethernet's interrupts are not being serviced since emplode can work when the player is playing.

I think the ethernet interrupts are being serviced regularly and probably don't take a hit of the empeg-player thread scheduling as they are more or less part of the kernel.

I thought that Hugo? said that only 30% of the CPU was being utilized.

Yes, but it still doesn't mean that 70% of the time would be freely available to "normal" processes. I believe the empeg-player utilizes all the CPU power it can get, but in theory it would also work with only ~30% of the total CPU time. Good example is to run "/empeg/bin/player -s- &", leave it background and start typing some shell commands. In worst case, it can take several seconds for the bash shell to get any time beyond the empeg-player.

Of course, all this can be handled properly by modifying the other applications to use real time scheduling also to share the time more equally. Although, the program has to be thought out properly before starting to play with the real time priorities as they can easily lock up the whole empeg quite easily (yes, has happened to me ).

Kim