The socketeer	
-------------

wants to know if it went well...

It interprets the command and intercepts the obvious syntax errors. After that it creates the action. 
There shall be a semaphore in there, together with some success indicator. This indicator shall be of type "volatile bool", for that I don't need any tumbersome locking. One might consider some kind of return string; be it for success or failure. Or return value instead?
Might be better for keeping (nearly) all text creation in one place: the socketeer.

What kinds of return value are possible?

-success/failure
-unsigned long int for actually reached seeking position? No, we talk in seconds here: double (OK, float would be enough).
-error code: unsigned char... or int

better look directly at the actions:

-IN_PAUSE
	when there is sth. to pause (that is playing or already paused): simple success
	when no track loaded, then it makes no sense: failure
	when stopped? What means stopped? Normally paused at 0... or what?
-IN_PLAY
	tricky: this is the create device/load track and start actions combined
	mixer knows directly if device creation went ok; should check for file existence, too: no problem.
	the there is the actual loading of the file... there comes the decoder thread who should signal the OK
	PROBLEM: both the mixer and the socketeer need to know
	SOLUTION: socketeer gets the signal and creates an action solely to inform the mixer
	FURTHER PROBLEM: can I be sure that the socketeer will still be there to inform? Sure, it waits for confirmation and the client should, too. But should I cover the case when the connection is broken? Is this a problem at all? Maybe not. The next read attempt from the socket happens after the waiting and notify action creation.
IN_LOAD
IN_STOP 5 
IN_START 6

IN_SEEK 20 //absolute seek
IN_RSEEK 21 //relative seek
IN_BIND 22 //bind <input> <output>
IN_UNBIND 23 //unbind <input> <output>
IN_VOLUME 24
IN_BASS 25
IN_MID 26
IN_TREBLE 27
IN_SPEED 28
IN_EQ 29
IN_FOLLOW 30
IN_NOFOLLOW 31

//the border: 100
INOUT 100

OUT_PAUSE 153
OUT_START 154
OUT_LOAD 155 
OUT_STOP 156 //may be different from pause... may close an output file and open new one on restart 
OUT_PLAY 157

//the big border: 200

OVERALL 200

SUSPEND 201 //of the whole process...
QUIT 202 //obvious
ADD_IN 203
ADD_OUT 204
REM_IN 205
REM_OUT 206
GETSTAT 207
RESUME 208
CLOSE 209 //close socketeer thread 


BlaBla... so, general system: socketeer waits for confirmation on a semaphore with according error code variable; maybe an additional variable for some return value. Need it for seeking. Some string? Want to avoid that; socketeer should make the strings.
For actions that mixer needs to have knowledge, socketeer creates a notify action. Additionally this way socketeer should itself handle combined actions; keeping the mixer simple.

For now the seeking action is an exception in needing to provide some return value since the actual seeking position may differ for various reasons from the desired one.

socketeer
{
	...
	sem_t succer;
	volatile int errcode;
	volatile double value;
	action.semph = &succer;
	action.errcode = &errcode;
	action.retval = &value;
	
	sem_wait(&succer)

	if(command was play)
	{
		actions->push_back(new action);
		actions->back().type = IN_LOAD_NOTIFY;
		actions->push_back(new action);
		actions->back().type = IN_START;
	}
	
}



I'll just consider load() and seek() for asynchronous action; in principle should set_eq follow.

new intermediate states for an input:

LOADING
SEEKING

mixer does not touch inputs in these states until NOTIFY_IN_LOAD or NOTIFY_IN_SEEK are given; then the state changes to STOPPED or PAUSED/PLAYING ... oh... I need SEEKING_PLAY and SEEKING_PAUSE; in the second case the buffer should be cleared, too.

Nice about the concept of notify actions that it's easy to add NOTIFY_IN_LOAD_FAILURE... that should definetely be in the final code.

Another idea: imagine some error watcher in style of the socketeer concering the communication with the mixer... decoder error -> notify action... may be too late... and futile.
