15 years ago, nobody "needed" broadband. Dialup was, "good enough."

Today, try doing anything other than text-only email over 56Kb dialup.

Broadband uptake enabled a new class of Internet sites and services. Google is betting that history will repeat itself by kicking speeds up by two orders of magnitude. It also has the beneficial side-effect of lighting a fire under AT&T's slothful ass.

Also keep in mind that GFiber offerings are symmetric. That means you get to upload your photos and videos at 1Gb/sec as well, and not through the 768Kb straw that DSL and cable providers decided was "good enough" for consumer-class Internet.

How about a smartphone app that encodes steganographic audio in your photographs? If you upload your photos, the spies get your audio too!

You could do this using FRS walkie talkies, as long as they have microphone and earphone connections. Or analog telephones. It's been tested multiple times on ham FM walkie talkies. Anything that carries voice should work. The bandwidth is only 1.25 kHz and I think the low end starts at about 700 Hz.

There is a video of the codec vs. SSB on the same radio link here. You can also take any radio links you have at hand and run the FreeDV program. This is an evening project to set up without a business case, and at least some companies appreciate people who take the initiative to do this sort of thing.

I can get the soundrack of your entire lifetime on a 32G micro-SD card.

Since I did this talk, a lot of information about AMBE has been revealed and there is a receive-only implementation in Open Source. The patents in general run out by 2015. But AMBE is still a relatively low-performance codec compared to ours.

Sorry. When I say "1200 Baud", I am in general thinking of the TAPR TNC 2, which was never built for voice but can do it, to a degree, with this codec. It's sort of a Bell 212 modem on half-duplex radio. There were many commercial products based on the TNC 2 design and many hams have them on hand. It's a good demo to put speech through a pair of them, not really practical because the latency is high.

MOS is only for people who want to pay a lot of money. Of the automated processes, the one available to us isn't validated for less than 4K bps codecs.

It would be a great improvement to MOS if there was an open version of POQLA. But the actual customer base for the codec have never even heard of MOS and thus we aren't volunteering to write that. The folks who want to put it in expensive government support systems yet aren't willing to help with testing don't get our sympathy.

Correct. It's made for radio, and indeed you need to go connection-based rather than datagram-based to keep the header overhead smaller than the payload.

We avoid some techniques that would make the noise performance worse. The HF version of the codec doesn't vector quantitize, and doesn't do any delta coding between frames. The current FEC is Golay and we are investigating low-density parity codes.

There is a lot yet unheard about the Ratheon codec, regarding its actual noise performance and how well the listener can distinguish different speakers.

No really.

I took a pass at Python 3 a while back. The amount of hoops I needed to jump through, to deal with compilation errors around Unicode handling, was terrifying. It was simply a poor user experience.

Python 2.7 just works. Sure, it's a nightmare past a certain scale point. But until you get into the dregs of OO it really is executable pseudocode.

Python 3 is some other language that lost that property.

The big problem is that we don't ship languages with telemetry that reports when they fail to work. So things that are completely obvious to outsiders never make it to inner circles. Not that I can really see any way for Python 3 to mend its errors.

Hi.

the Nyquist limit of the audio sampling hardware of a cell phone over instruction rate of a modern CPU is a pretty small fraction.

The "audio" in question is most likely all below 24 kHz, that being the Nyquist limit for the 48 kHz sampling hardware, unless it happens that some phones can actually sample faster, and have microphones that can respond to higher frequencies.

The instruction rate of the CPUs in question is many times that frequency.

It doesn't sound likely.

Using multiple cores turns out to help the attack (by shifting down the signal frequencies).

Say what? Through what mechanism would multiple cores shift down the frequency? And what about parallel instruction streams contributing to noise?