talking and listening

Dear Diary,
Today it finally happened :) Kinda.

So as of last Friday night's hacking, if you choose "test recording", talkLock will record audio and post it (in short chunks) over and over until you choose "Big Red Button". If you choose "get audio", it will get audio from the server and play it over and over until you choose "Big Red Button".

But I was the only one with a java phone to test it!

So I wrote a little shell script on my Mac using a copy of ffplay that I compiled with amr-nb support. I used to curl to fetch audio from the server and feed it to ffplay. Unfortunately ffplay doesn't exit when it finishes playing a sound, so I backgrounded ffplay. This kind of fork-bombed my Mac :o So I had to make my script look for pids for ffplay processes and kill them after playing. This was slow and insane, but I was able to talk into my phone after choosing "test recording", and start my script on the Mac, and see the ffplay visualization of what I said, as well as hear it :) It was choppy, or should I say there were dropouts in the audio of up around a second. But it was doing the thing!

Muahahahahahaha!!!

The horrible and ugly thing I finally figured out from some professor's website, was a trick using a new class that implements Runnable. So I declared a quit() method, and a run() method that did the whole record and POST thing. Then in my main midlet code, I instantiated my Runnable as puttit. The trick is that you pass your Runnable as an argument to a new thread, like "Thread putting = new Thread(puttit);". Then I could call putting.start() to record and POST, and puttit.quit() to make the run() method stop. Whew.

So I didn't have to do anything with mutexes or synchronized or wait or notify. I'm glad of that, especially after reading Roedy Green say to avoid that paradigm.

The most fun though, was saying in a long drawn out monotone, "feeeeeeeddddbbaaaaaacccckkkk" into the phone, which was very close to the Mac. This of course caused a feedback loop as the Mac sound output went back into the phone again, getting more and more distorted and tinny and strange with every iteration :) Wonderful, great fun!

So the performance isn't all there yet, and the code is probably very inefficient, and using "Big Red Button" stops the presses, but the program is unstable afterwards... More hackin'.