TCP/IP over audio
anfractuosity.com
anfractuosity.com
Is this a false memory or can someone else confirm seeing this?
I think the Commodore Cassette drive was 50 bytes/sec?
It's possible that the BBC broadcasted data in the same way (conceptually, even if not in format) on their TV programme.
I wrote a prototype proxy in Go that can split network traffic over two Internet connections using some hacked-together tun code[0] and everything happens in userspace.
that's literally how TCP/IP was invented. This stuff - pure, analog audio - went all the way up to 28.8kbps, which was the limit of the line bandwidth. Why not just take those protocols and put them into a speaker and microphone. Why bother writing new protocols? Just start with modem protocols and play with the frequencies.
Home Internet connectivity was literally born out of TCP/IP over audio...
This guy used 17 and 18 kHz as carriers. That is within the hearing range of young people, but a quick experiment shows that either my desktop speakers cannot reproduce 17 kHz, or I have recently become too old to hear 17 kHz.
Given two separate examples of running code, the question is really what percentage of laptops can do this. It's possible that some systems have filters but so far I haven't found one.
It's easy to find out -- go here:
Enter any frequency you want. Chances are if you're over 40, you can't hear 17 KHz. I'm 68 and I can't hear anything over 6 KHz.
> ... or I have recently become too old ...
It usually takes longer than that. :)
(Maybe I should get better speakers...)
Maybe, but you can test your hearing range more easily by putting on a set of headphones and experimenting with the linked signal generator -- reasonable quality audio headphones should easily be able to exceed your own hearing range on the high end.
And chances are typical computer speakers should also be able to exceed a normal hearing range.
If you're in your mid-20s (and you're on HN, so you probably are), it's not terribly unlikely that you've recently lost that part of your range. In my experience (back when I was young enough to hear those frequencies), even crappy speakers can usually go up to 20kHz easily. Very low frequencies are another story.
Only downstream was 56.6k PCM, upstream was 33.6k analog-modulated, so two consumer modems hooked together would only be capable of 33.6k.
There was a later V.92 standard that improved upstream speed, but is was a bit wonky as it sacrificed download speed to do it, I'm not sure how much it was really used.
Of course the chip could lie about connecting at 56K I suppose.
At the ISP I worked at back in the mid-late 90s, I definitely remember us having to upgrade the lines and buy a bunch of fancy new rack mounted modem equipment to support 56k. IIR, the equipment and lines could also handle single and dual channel ISDN connections, which we charged a pretty penny for. But the customer had to have a digital connection at their end. Also, IIR, the actual limit was 53k for some regulatory reason.
Here's some period reading
http://windowsitpro.com/networking/ive-connected-two-compute...
http://www.eetimes.com/document.asp?doc_id=1275915
http://support.apple.com/kb/TA21865?viewlocale=en_US
http://windowsitpro.com/networking/ive-connected-two-compute...
http://lowendmac.com/56k/hype.shtml#unidirectional
Of course I might be wrong, I've forgotten almost everything about the ISP business.
fun note: Before that we had built several racks of custom dial-in hardware out of unboxed external USR 33.6 modems, racked and fan cooled, with long power strips along both sides for power.
Troubleshooting was accomplished by turning up the volume on a suspect modem and waiting for somebody to dial in and listening to a couple fails (we couldn't dial into it directly due to how the incoming telephone calls were routed). A trip down to the local computer shop to buy another modem, crack the case open and voila, fixed.
We eventually were forced to sell the company with the advent of DSL, which, even if we could afford the head-end equipment (which we couldn't) it wouldn't put us in practical competition with the phone companies who were better positioned to offer the service.
The line from your customer to the central office could NOT be digital, because if it were, it meant you are most likely connected to a SLC (aka remote terminal).
The goal of a SLC was to serve a remote area at low cost, by avoiding the need to deploy tons of copper. Most SLCs achieved this by taking a T1 (traditionally 24 POTS lines) and performing an analog-to-digital conversion AND compression (instead of giving you 64KB of bandwidth per channel, you got 16KB) to increase the number of voice lines that could be served.
So instead of deploying 96 pairs of copper, for 10 miles, at a cost of $$$$$ per mile, you deployed 2-4 pairs of copper for 10 miles at $ per mile plus the fixed cost of $$ for the purchase/lease of a SLC.
(The downside is the occasional line break caused by a car accident or hungry squirrel, would take down an entire neighborhood instead of just one customer)
On the provider side, you needed a provider that would deliver you PRIs with echo cancellation turned OFF on your channels.
Echo cancellation helped telecom providers, again, by saving bandwidth. With the advent of packet-switched networks, your voice calls were converted to digital audio, and sliced into chunks of 64KB, and delivered as packets to the remote switch.
Silence suppression was a common feature of packet-switched networks -- instead of delivering 64KB packets of silence, you delivered nothing, which allowed providers to reduce the aggregate amount of bandwidth they needed to service all the calls transiting their network.
With echo cancellation, it further increased the amount of packets the provider could drop to the floor which reduced their overall bandwidth needs. Your provider most likely marketed this new technology as "better quality voice calls" (remember the AT&T commercials inviting you to test the quality of their 'new digital network' for yourself, by calling 10-10-288-something and listening to a clip of Whitney Houston singing?)
The problem is, echo cancellation generates false positives on modem calls, and the subsequent silence suppression would cause 56K calls to retrain down to a level that would eventually not be effected by the echo cans, resulting in a 31.2Kbps or 33.6Kbps call.
This was a highly annoying discovery for providers who invested in brand new 56K-capable modem equipment.
Normally, you could just ask your provider to turn off the echo cans, but after the Telecom Act of 1996, a flood of new providers entered the market who were merely just reselling other larger carriers. This was a problem as your reseller probably didn't know what echo cans were, let alone had the "pull" to ask the underlying provider to turn it off on your behalf.
As an ISP, if you couldn't get echo cans turned off, then your only option was to cancel and find a new provider.
In order to support 56k speeds, the exchange (or road-side box) had to be upgraded. Normal exchanges used a simple 8-bit DAC and ADC, but when a 56k modem was attached it would have to switch to a different mode. Effectively, the remote modem was moved from the ISP to the exchange, with the digital part of the POTS network transmitting de-modem-ed data, rather than a digital representation of an analogue signal encoding digital data, which is what happens with slower speeds.
So yes, the 56k signal was transmitted over an analogue line, but no the 56k signal was not transmitted over the main POTS network. Work beyond 56k was not pursued because the underlying digital telephone network could not actually transmit data at a higher rate.
This is also where the 64kb/s speed of an ADSL line comes from by the way. That just extends the digital part of the POTS network to the house. ADSL allows a slightly higher data rate (64kb/s rather than 56kb/s) because it has a side channel that carries the control signals such as dialling and flow control, whereas 56k modems had to send flow control and error correction in-band.
http://commons.wikimedia.org/wiki/File:Akustikkoppler_CCC_Da...
And it supports 300bps and 1200bps speeds.
I'm not sure how different that technique is from what is posted in this article.
Technically PPP is a point to point protocol which makes everything easier (no real addressing, no routing and so on). This protocol would be more comparable to wifi.
So instead of tuning your radio to 7.070 MHz and clicking on the computer waterfall at 1200 Hz (aka operating at 7.0712 MHz) you just unplug the radio from the computer, use speaker and mic instead of something plugged into speaker and mic jacks and click on 18 KHz or whatever.
In the early days of PSK-31 and other modes you did demos at radio club meetings and whatever by just letting it rip over the speakers. Loud and annoying but works pretty well across a room or further.
The main limitation is most SSB communications radios cut out around 3400 Hz at the high end so the software that is written for sound card digital modes cuts out somewhere above that, but sometimes not as high as 25 KHz or whatever, because 99% of the users and devs will never fool around with ultrasound.
Because I like to use a HF modulation mode called Olivia I mostly use an old version of DM780 software (from when it was free) and multipsk (free) although I could use FLDIGI (which is also free). In my infinite spare time I'll see what unnatural limits have been built into the software. This topic of ultrasound networking comes up on HN like clockwork every week or so, so I'll report back next time.
(Edited to add, one thing I like about multipsk is the, um, innovative UI. Go to images.google.com and take a look.)
I think that I actually don't know any more than you about it.
What happens when packets are dropped in TCP? A hard-to-predict amount of delay. And retransmission of audio data that you might just throw out anyway. (There are alternatives to discarding the data that should have already been heard, like temporal compression, but that's hard to do right, too.)
Instead, for realtime applications, you make sure each packet is usable by itself, and make your system gracefully degrade in face of packet loss.
(Or, if you're from the insane world that designed Fax-over-IP, you transmit 2 or 3 packets for each packet, and hope that staves off packet loss.)
* All packets arrive. (Reliable transport). * All packets that arrive are in order. (Sequential transport).
Unfortunately, both of these aren't so necessary for real time audio (and somewhat less so, video). In fact, they get in the way.
Missing packets can often be replaced in VoIP settings with various kinds of interpolation. And out of order data can be buffered and used to build the interpolated data before playback. Interestingly enough, even packets that have been damaged still often are usable to VoIP applications, since they still contain some payload that can be used to improve the signal.
By the way, I'm using Linux Mint 15 and fairly experienced with Debian-based Linux systems.
Would be very interesting to understand how audio attenuation impacts the TCP/IP connection.
I'll see if I can dig out a pcap file I took using it, which should give you an idea of the latencies involved.
[Edit] I've just updated the page with a wireshark screenshot which shows the latencies and also a link to the pcap file.
Something which I'm keen to look at doing is extending it beyond 2-FSK, to improve the throughput.
To get up to 23kHz I used a sample rate of 48kHz.
It's not a low-pass filter per se, the limit is imposed by the Nyquist–Shannon sampling theorem (http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_samplin...), which essentially limits the frequency spectrum to 1/2 the clock rate. Good-quality audio from a sound card is clocked at 44 KHz, which means the audio range extends only to 22 KHz.
But you can clock a modern sound card at a rate much faster than 44 KHz, so the above might be only the normal limit, not the extreme.
That's what TV broadcasting does. But it's radio (electromagnetic) waves, not sound waves.