March 2nd, 2005

audio scheduler subsystem

i rewrote my audio scheduler subsystem tonight that i run on the server. it didnt end up being quite portable, but it's definitely on that route. i used to have sound entry points spawned directly from cron. now instead, i have doing all the spawning, and cron just posts info to the messages log, which swatch watches. any other things i want watched from swatch are watched from messages already, so now all the events are based off one file. i also consolidated all the files into one new tree, /usr/local/gowave. i renamed the files to be more generic sounding, and then tokenized their input parameters so that it's not completely retarded anymore; two tokens are passed: the stub of the wave file to be played, which is also the stub of the lock file, and the duration to sleep after playing. by adding this duration, i have a crude throttling method now. if i get pinged, it plays a ping. but if i get 50,000 pings in 60 seconds, it will play 15 ping waves, because it sleeps 4 seconds for every time it plays. it wont drop 50,000 pings into the queueing system i wrote in. that would suck, it would take days to finish, and that data is invalid by that point. yeah, so i wrote in a queuing system. it's all about atomic locks. i actually dont believe these locks are atomic, but they shouldnt lead to many race conditions the way i am doing it. i am using && (and) statements to lock the files, do the action, and unlock the file. this, coupled with the queue name, which i decided would be YYYYmmddHHMMSS$$, $$ being the pid of the calling process, and then .wav. so as events are written from each seperate subshell, i get a queueing directory that might contain two files: 2003030223450513456.wav and 2003030223450613459.wav. the queue reaper runs every 0.25 seconds (they finally added decimalized seconds to sleep! finally, i dont have to run max idle loop runners and crank my load average. even at 4 times a second, i'm doing millions of cycles less per second, and still getting very very high performance), so in the above example, given the seconds did incremement in the filename, its a no brainer which will run first (the reaper just does a lowest number first sort). if they both write in the same second, then whichever process id ($$) was lower will run first. i feel like, whatever, they are going to be heard withing a few seconds of each other... good enough for this function. if i need the files to be played in a certain order, hrmm... actually, there's still a bug, even with concatenated and statements.. if they get written with the same seconds, indeed the pid will truely randomize things. well, i could always hard code those entries, i.e. just take the pid out and do the queueing name calls by hand. name1.wav && name2.wav && name3.wav. bleh. anyways, there's a master lock file that everything looks at first. i named it SUPERlock cause i didnt have a better name. anything that plays music or what-have-you will toggle SUPERlock first so that queued info events dont flood the system afterwards.

so, if i ever get the bloody thing more complete in terms of lameo nerdboy options, then i'll package it up and toss it on the web server and have my first official software distribution :) actually, i never did release the apache auto indexer i wrote in bash, due to it being written in bash.. this audio scheduler is also written in bash. augh!