Several notes: a) priority queue is for playing sound events LATE. Its use depends upon a tunable parameter (lateness) that determines HOW LATE an event sound can be played. If you have 32 channels and 100 events come in, and lateness is 1 second (maybe this should be 5 seconds) then the remaining 100-32 = 68 event sounds will be played (when the other sounds finish) for up to a second, after which they'll be dumped from the queue. b) in handling states, - reserve (a small number of) channels (4 would do, 8 are overkill) - assign one permanent sound to each channel. This is a set of randomly sampled slices that change randomly. e.g., a brook is 8 1-second slices that get glued randomly together. - the things that can change about a state are a) spatial position beta = 0.5 means chan1, chan2 unchanged (raw) beta = 0.0 means chan2, no chan1. beta = 1.0 means chan1, no chan2. short chan1, chan2; chan1 = (chan1*min(beta,0.5)*2); chan2 = (chan2*min(1.0-beta,0.5)*2); where 0.0 <= beta <= 1.0 b) overall volume short sig; sig = (int)((double)sig*alpha); where 0.0<=alpha<=1.0 0.0: absolute silence 1.0: original volume c) next step is a dummy procedure that sends sound requests to the player. for events - event number (priority) for states - state number - intensity - position just sleep and send, sleep and send. d) next step after that is to make sure you can listen to SEVERAL of these. several sleepers at the same time. e) make up a few dummy sounds to start. Don't worry about quality yet. f) step after these is to write a feeder (replacing sleep and send) that - parses tcpdump - maps certain kinds of packets to events. - sends to player. g) think about possibility of rethinking what the main of the player does so that it - listens for tcp connections - allows any feeder process to start up and connect to it.