A WiFi microphone adapter Part 1

I assisted with recording a Christmas Eve carol performance. All the usual guff: set up microphones, set up mixer, connect cables, patch into PA system in building, level check, attach recorder, check record levels, record performance. Then take it all apart at end.

The single most annoying part of this procedure is laying out the cables and duct-taping them to the floor so audience doesn't trip over them. It got me thinking. Why not use radio mikes?

Obviously the quick solution was to replace the six microphones with radio mikes. Did a quick check and realised this would not be cheap. So replacement ruled out.

What about a radio adapter for the mikes? No, still hundreds of dollars per mike.

The other painful part for me at least because of the duplication of effort was the mixer and recording process. Once the performance was over I had to transfer the recording to my MacBook and process all the audio once again. And then I realised how badly mixed the audio was and it was almost unusable. Despite being complimented by one of the audience about how good the PA was, I had really messed up the mix for the recorder. My efforts at re-mixing are here: http://www.stmaryssingers.com/recordings/

If I had been able to plug the mikes into a WiFi adapter and feed the resultant packets straight into a digital audio workstation (DAW), thus recording each mike individually, and then mix the mikes and feed the resultant mix to the PA, I would have then had the luxury of a proper (re-)mix for the website recordings.

The idea of building my own WiFi mike adapter was prompted by the SEAforth 40C18 chip sitting next to my laptop. Why not use it for this? The blurb says the chip is ideal for audio and wireless applications.

My first thought was to program a fully self-contained audio to WiFi adapter. Surely it would be a simple matter to pipe audio to one of the ADCs and program the rest of the cores to send the digital packets out over a WiFi socket to my awaiting MacBook? A closer reading of the specs and blurb reveals that the chip isn't fast enough to synthesise WiFi frequencies directly and the designers expect one to use the chip to control an RF chip of some sort. I also remembered that radio is a PITA, even a moving foot or hand can have sufficient capacitance to throw off the signal. I started investigating prices of radio modules.

My initial thought was to use WiFi but I remembered there are two other protocols in the 2.4GHz band: Bluetooth and Zigbee (formerly Home RF). Zigbee was quickly ruled out because it is aimed at quite low data rates, basically for remote device data transfer and control. I also initially ruled out Bluetooth because the 10 meter range was not enough for a remote microphone. I later realised that I was reading the early Bluetooth spec and the more recent version probably has the same range as WiFi.

The other requirement for a mike adapter is battery operation which means low power consumption. Once again I thought I was home and hosed when I found an article in Elektor December 2008 for a wireless headphone kit. But the power consumption is over 100mA for transmitter module which is used. The modules are otherwise perfect for my requirements. Except for price! They are a couple of hundred dollars each.

So once again, I looked for other possibilities. I found a link to a Sony PSP being used to transmit audio over HTTP but it turned out to be a PSP with a WiFi dongle attached to the USB port.

And then it hit me how silly I had been. Bluetooth and WiFi dongles are less than $10 these days. So all I have to do is output data packets to the USB bus and the dongle can take care of the RF problems.

I was still undecided whether to use Bluetooth or WiFi. Revised Bluetooth has almost the same range as WiFi but BT is intended to run at much lower power levels so BT should be lighter on the batteries. But I found an article in Circuit Cellar Jan 2009 for an audio over Internet adapter. It sends streamed audio packets using UDP protocol over Ethernet. It's almost what I want. Most relevantly it gives full details of how to program the PC side of the system. The author, Valens, turns the audio stream into a VSTi virtual instrument and nearly all DAWs can handle VSTi these days.

So I have the C source for Valens' adapter and the C++ source for a VSTi plugin to handle the adapter. Not sure how much extra circuitry will be needed to handle the audio input. I will use one of my NT5 condenser mikes for audio input but it needs 48V phantom power. I vaguely remember an article in one of the electronics hobbyist mags for an audio mixer so presumably I can find 'phantom power' circuitry somewhere in that. Actually a phantom power XLR audio socket is the last thing I need to worry about. Any random audio input would be OK. And in fact even that isn't needed till the end. I could probably allocate a couple of the cores to generate a 440Hz sine wave and use that till the WiFi section is sorted out.

Note to self: having an internally generated audio signal could be very useful when the adapter is actually being used on a sound stage or whatever. Setting each adapter to a different note could also be useful. Each adapter will need a unique identifier for its data so can use the same ID to set audio note. (C-scale or 12 chromatics perhaps.)

Techie vs diplomat

Overheard a conversation between a Physics major and an "International Relations" major:

Techie: "I know how to calculate the volume of oil going through a pipeline of a given volume for a given period".

Diplomat: "And I know who to ask when I need to know the volume of oil etc."

Objective-J is a seriously interesting language

I'm working my way through the Objective-J tutorials at the moment. OJ is absolutely brilliant. It has simply(!) transposed the Objective-C syntax into Javascript. And the result is stunning. In-browser apps which look and feel like Mac OS X apps. All the years of OC accumulated knowledge and the ubiquity of JS in every browser. Glad I spent some time learning OC. I thought it was wasted with my chances of getting work programming in OC being close to zero. But with the incredible popularity of the iPhone and the iTouch and now with OJ, OC(-like) programming is going to hit the charts with a bullet.

And I've already got a great (but big!) app I can develop in OJ.

A music OCR/OMR chip?

What if one were to program a SEAForth 40C18 with just the recogniser routines of Audiveris? There's some quite heavy lifting in Audiveris which could easily take advantage of the 40 cores in the chip. I've never met a 100 lines of Java that couldn't be reduced to one line in Perl. I wonder if one could get a similar reduction in Forth. I haven't looked inside Audiveris yet but I bet most of the 100,000 lines of code are the GUI and the object interfaces. Algorithms tend to be compact, for a couple of reasons: big ones are difficult to understand hence humans don't think them up; and big algorithms are slow; the fewer lines of code, the faster it runs. Anyway, now that I've received my 40C18 I will have to find something to do with it when I've got past the Hello World tutorials.

Lowering one's expenses on public transport

I was quite stunned to see a guy come through the electronic ticket barrier at my local station this morning and hand his ticket to another guy waiting there who immediately went back through the barrier to catch a train. Weekly tickets here in Sydney allow unlimited journeys through the rail system within the zone for the ticket.

I don't know how these guys linked up but I could easily see it happening via Facebook or whatever. If you could arrange your starting and stopping times at work or wherever you could share the cost of a weekly ticket amongst a crowd of people, all of it legal (well probably not within the T&C for the ticket but how are you going to check?). No doubt the rail management hate it but how are they going to stop this happening?

I wonder if there is already an online 'ticket pooling' service, like car-pooling but you share your weekly/monthly/yearly ticket. Let the computer work out how to allocate people to a ticket. It would require incredible discipline but if you are struggling for every dollar, you need such discipline to survive. (I remember the luxury when I first started to earn a pay-packet of deliberately not budgeting when I went supermarket shopping. Being from a single-parent family and not rich, my job each Wednesday night was to scan the newspaper for specials at the various supermarkets at the local shopping mall. I then worked out the shopping lists for each store and my mother, sister and I shared the shopping load. It halved our food expenses but it was very time consuming.)

Learning not to be paranoid

I worked out why colleague was so cool towards me when I started a new project. I thought he just didn't like me. But no, it's not about me. Turns out he was in the midst of job-hunting. He found the new job and is leaving this week.

I've seen this behaviour so many times in my working career but my basic paranoia always makes me think it's personal. It almost never is. Usually it's job-hunting, sometimes it's a sick or dying relative, once it was gambling.

The best time was when I was the IT manager for a company and I was fighting with the CFO who kept blaming me for the financial state of the company. (An independent auditor had blamed the GM and CFO and exonerated me.) But he decided to make me redundant (a 'nice' way of firing me) anyway. I went above his head and asked the GM to intervene but he acted as though it wasn't his problem. Once again my paranoia told me it was about me. But as I was walking to the exit on my last day there, the GM walked out with me. He'd been fired by his boss. The bastard CFO got away clean.

A possible UBM

Better get this idea down before it gets lost in the haze. Louis Savain's UBM looks like the way computing is heading. IntellaSys' SEAForth chip looks very much like what Savain says a parallel processing CPU (MIMD) ought to look like. Are the processing elements of COSA implementable in 64 words of RAM and 64 words of ROM?

The problem is that the devel tools for the SEAForth are primitive. There's no way a non-specialist is going to write parallel programs for the SEAForth using circuit emulators and Forth. So the task, if I care to take it, is to implement a graphical COSA devel environ which targets the SEAForth. Or hosts the IDE itself? Is that feasible?