Parallel recording, serial playback: how it works
Last week, while visiting the Hacker Dojo in Mountain View, someone asked me how you can actually deal with multiple overlapping radio calls. How can you turn a bunch of simultaneous conversations into meaningful results? This is how it works.
First of all, I consume a large swath of radio spectrum. The idea is to pull in enough of the band to have all of the channels which interest me. This creates a pretty large stream of data arriving from my radio. Assuming 32 bits per sample and a 4 MHz window, that's 16 MB/sec or 128 Mbps.
So now this firehose of data arrives at the computer, and I have to slice it up. Using a bunch of filters and other CPU-intensive constructs, I carve out the pieces I actually care about. For reference, the Santa Clara city system alone has 7 channels. Systems like the one used by Alameda County are much bigger.
For each slice of data, that then goes through additional processing and eventually through a FM demodulation stage to yield audio. That audio then gets squished down into MP3 format or similar and is saved.
Imagine this happening in parallel and now you can see how it's possible to record multiple transmissions at the same time. There's a lot of secret sauce involved in making it start and stop cleanly, but the actual audio recording is not particularly difficult.
All of this only explains what is happening on the back end. Here's what happens when the user sees it.
In the usual situation, a user has their browser pointed at the main list page, and it's playing a call. When it reaches the end of that call, it looks to see if another is known, and if so, it immediately starts playing that one. While playback is occurring, more calls can and will pop on as they are committed to the backend.
During busy times, there will be more than one second of audio recorded per second of real time. Perhaps the police, fire, and street departments are all working some big thing like a gas leak. The user plays them back one at a time, draining the backlog at one second per second.
The reason this works out is that crazy bursts of traffic are just that: bursts. Eventually, it calms down, and the incoming rate of data is now less than one second of audio recorded per second of real time. The user's playback continues, and sooner or later they catch up completely.
At this point, there is nothing left to play back. The scanner "app" (it's a web page...) patiently waits for more calls to arrive. Once that happens, the process starts over.
It's hard to describe this in words, but it's easy to get by using it.