Second considerations, about threads and priorities

POSIX defines thread scheduling priorities, Linux doesn't do that.
But Linux has gettid(), which gives me the thread's scheduling PID and I can use setpriority for adding nice levels.
So I'll have to make a wrapper over the POSIX thread priorities and the Linux hack and then have the folowing scheme for most cocksure dermixd:

1. Start dermixd with the desired (negative) nice level of its most important task, which is to produce audio.
2. Mixer and audio output threads will keep that priority.
	Option: Mixer drops priority, too, to really make output the most important.
	        In that case, mixer should spawn an extra creator thread before dropping, so that this creator thread can create new outputs with the correct priority.
	        Alternatively one could just define the default output from the command line as the important one...
3. Input and socket threads drop priority, so that they don't interfere with output work.
   This is important for background action like scanning.

First Performance considerations

While programming DerMixD as a kind of reimplementation of the ideas on mixplayd using heavy C++ and multithreading I always have in mind that I don't want to code a bloated and slow mixplayd hoax. Therefore, I have a look from times to times to how much of my CPU the two consume.

Early tests against mixplayd-0.55 with mpg123 (both my hacked variants, I must confess) showed that normal playback of one track uses about 12-15% of my CPU together with X and some other sleeping apps ("measured" using gkrellm).

Oh - CPU means here the Pentium-II-Mobile/366MHz in my Toshiba Portege 7020ct.

Just today (05.03.2005) I had a brief look at DerMixD-1.0.0-alpha1.6 and mixplayd-0.60; mixplayd using madplay (not optimized for speed). Test object was "Joints & Jam" from the Black Eyed Peas, rather high quality mp3 encoded to 5480576 bytes.

Assuming that changes in my software setup (new Linux kernel for instance) have no big impact, I see that mixplayd managed to keep its average CPU of about 12% in spite of using the madplay decoder that _is_ clearly slower than mpg123 (i suspect that it may have been some % less in the early days or mixplayd really got some serious tuning).
Nevertheless, I noted happily that DerMixD yields around 8% for the same task, even with a watching client. 
One the one hand this is nice - the 1,3MB vs. 0.5MB static binary mass doesn't seem to make too much headache - but on the other hand, this lower usage is most likely just because of the more efficient decoder. I'll have to compare the OGG playback or create an alternative madplay_input for a hint on the mixer overhead.
Another thing one should not forget is that mixplayd interfaces in a very simple and brutal way with the decoder - that surely is less work that the mpg123_input does, but it also misses some possibilities that made me code DerMixD in the first place.

I'm not aiming for a significantly more cpu friendly program - tough task with all these complicated ideas, but I clearly want to avoid a significantly more cpu stressing program. For now it looks like I can achieve this goal. I'll see what a simple OGG input device adds to that (as simple as mixplayds... no EQ, no seeking in living instance - or even using libvorbis to read and possibly plug some EQ in?).
