I have those memories too! I'm certainly not claiming to have invented the idea of dial-up. The idea for this library is to provide a soft modem, highly configurable (thanks to liquid DSP), which comes "batteries-included" with a TCP stack (thanks to lwip). The examples shown in the README can even run on a nearly-ultrasonic modem profile whose spectrum content lies >= 19kHz
In this case, I assume they can beat the old modem bandwidth by cramming modulation in more ranges of frequency, with no need to adhering to the frequency range of the voice phone line.
I don't feel like your reply really explained the confusion. I'll go ahead and be the dense one haha.
Can you further explain the difference in your example? I assume you mean that the bulk of the dial-up data was sent over non-audible ranges? Ie, we couldn't hear the actual data transfering, but we could hear the monitoring tones?
You're not being dense, not at all. I was in a hurry and not clear enough:
Sound is different of audio signal.
Audio signal is whatever way you arrange to represent signals in the audio range of frequencies and, usually, dynamic rang. Sound is a physical phenomenon caused by variation of pressure on air that we can listen to.
So, the transfer was usually done by audio signals, transmitted electrically via copper wire (and, sometimes, magnetic coupling in some modems). You could, of course, convert these audio signals to sound by picking up the phone (or wiring the modem to the sound card), but this was just for you to listen to. The communication was not depended on sound itself.
I've been working on something similar[1] for a few years. Don't forget that you can use tun/tap devices to avoid re-implementing TCP/IP, and to gain interoperability with OS services!
Interesting, I had looked around for similar libraries when I started but didn't find many. It looks like ours differ in terms of FEC and configurability.
I look forward to the inevitable HN 'What is this thing?' post in ten years when somebody implements this in a one-off system then leaves the company. "Here is a recording of the two devices talking, one in the left channel and the other in the right. Can we figure out what they're saying?"
Clever, an audio soft-modem. Was there a reason to not implement this as an actual modem with a frequency band assigned to either channel and then to run SLIP or PPP over it?
The goal of this library is to provide the familiar sockets interface over a non-traditional eth, in this case sound.
Can you expand on your question? I think I understand what you're saying but I don't quite see what it would accomplish.
And this is an "actual" modem, whatever that means. If you mean an IETF/RFC modem spec, there are many reasons. Those specs are focused on narrowband POTS limitations, which we don't face over a less-restricted channel. Implementing those features might be interesting from a vintage perspective but would require substantial work to achieve compatibility for relatively little gain.
If you did it as a traditional modem then one could hook up any old piece of software to the appropriate character devices and you'd be off to the races. Not everything is sockets, and there are simple and relatively easy to use wrappers around a standardized serial character interface to turn such a connection into one supporting all of the regular internet protocols. It seems - but I may be wrong about this - that this solved something at a different layer than what I would have expected.
Ah, yeah, that makes sense. My plans for this library are mostly focused on using the sockets directly, with the library linked by both peers. I'm really interested in being able to use this as a simple UDP client/server.
Perhaps - my plan is to use this on iOS and Android where I suspect SLIP and PPP interop is not as straightforward. By bundling everything in with the app, there won't be any kernel dependencies, aside from the sound card.
I built a similar internet-over-voice system for a hackathon a couple of years ago. A mobile app started a call, sent a URL over the line via DTMF tones, the server fetched the page, converted each response character to a frequency, saved it all as a sound file, and played it back over the line.
The app would listen to the call, decode the sound via FFT and display the resultant data as a web page. I found decent results by increasing the pitch variance between notes. The interesting thing about GSM/low-quality audio is that, since quality is known, it might be possible to account for it in a more specific way.
The idea was to provide a means of internet access on a device with no mobile data plan.
Of course, the worst case scenario is just sending everything as DTMF tones, but getting a tweet out would take like an hour
GSM is definitely possible, but you'd struggle to get more than 2kbit/second (and that'd be over a good connection). You'd probably need FEC to pull it off.
There's dialup over GSM. Though those modems does this by piping data through a software modem and then onto the GSM channel, however it requests a clear channel, so no transcoding is done by the network or the phone (the lossy GSM codecs arn't suitable for this)
If someone wants to play with lower bandwidth data (text, basic file transfer) over sound, it's a pretty active area in the world of amateur radio. You can download the open-source program fldigi (http://www.w1hkj.com/modes/index.htm) on 2 computers, point speakers and microphones at each other, and try sending text (or files/images). The "flmsg" program will send pre-formatted stanzas which get converted into standard forms.
That being said, doing things like TCP/IP and other data is rather difficult on radio, mainly due to the duplex requirements and frequency spacing. But in pure audio, much more possible.
This is an interesting point. And in fact, the mechanisms that libquiet uses to encode/decode come from liquid dsp, which is in fact intended for use over RF.
The setup process for our Cocoon home security device (https://cocoon.life) uses an audio transfer from the phone to pass wifi details and a token to bootstrap setup and a trust relationship.
After some time spent tuning and with some forward error correction, the reliability is good and it's not too harsh on the ears. Response from beta testers has been pretty positive.
I've been prototyping a dail-up concept (like CSD) over 2G networks. Combined with heavy server-side compressing, the goal is to achieve speeds faster than GPRS in areas that have no data coverage to speak of. TCP over sound was the first part. I'll have to study this implementation.
Note that your audio will get fed through the AMR codec and then limited by the bandwidth available to that. For best results reverse-engineer the codec so your symbols are maximally distinguished by it.
It should not be possible to exceed the carrier's CSD rate over the link, but it's an interesting way of circumventing their billing.
More interesting IMO would be to embed data stream into normal audio stream within human-audible range. Something like MP3 steganography, but decodable after air transfer. Had anyone tried that?
I can imagine some interesting potential applications, including weird ones.
However it is technically trivial to encode "hidden" data at inaudible frequencies (>25 kHz) along with a song/whatever in the audible range and recover the data with a high pass filter. You would have to explain, however, the need for >48kHz sample rate.
Another, stealthier option would be to encode information in the background noise of a recording, but this would require more complex encoding/filtering techniques.
I wonder would it be possible - like in steganography - to hide the waveform in ambient noise or music so that it's not perceptible if used with speakers and microphone within audible ranges?
If anyone is curious about the modulation and error correction techniques supported by this modem, you can try out https://quiet.github.io/quiet-profile-lab/ in your browser, which uses Web Audio to interact with your sound card. This runs at a frame level, about one layer below the UDP/TCP provided by quiet-lwip, but all of the modem characteristics are the same.
Was there not a PoC recently (~months ago) of someone who did similar over a speaker/microphone but outside the audible range of ears? It was a PoC of the Flame malware capability to jump airgapped PCs
Not sure if this is what you meant, but Chromecast's guest mode will pair using ultrasound. The guy who worked on it has some code using the WebAudio API on github and his linked blog:
No there was an article on here several months ago that I couldn't find when searching where someone wrote a PoC for the transmission of data via near-ultrasonic sounds from a computer speaker and microphone. I don't think it was this [1] one, but it shows the concept being used.
Maybe I'm misintepreting the OP's work and not realising how it differs in some subtle way? I get that they've put TCP/UDP over it, but is there something else I'm oblivious to?
Slightly unrelated but curious; have there been any attempts to transfer data as sound? I don't mean sound converted to electricity, or to represent 0s and 1s, but using a specific frequency range to represent 1, another range to represent 2, another for 3... I don't know the terms for these things.
Using vibrations instead of electrons to transmit data over a wire?
(The 0 and 1 version is binary audio FSK, but you could also choose to have more frequency levels, such as 4 or 10 or 20 different levels.)
People studying this don't usually distinguish between whether the waves are emitted into space as audio or whether they're encoded as electricity. The main reason for that is that we have devices (speakers and microphones) that convert directly between audio and electricity in both directions, so the design of a system that uses a wave represented as electric signals and a system that uses a wave represented as sound is "equivalent" in some way (even if they face somewhat different practical considerations, like different kinds of background noise).
Edit: oh, there's a more detailed Wikipedia article on non-binary FSK, called "multiple FSK".
My father always referred to TV remotes as "ker-chunkers" because of his experience with an early TV remote that would make a noise like a tuning fork when pressed then the TV knob would make an audible "ker-chunk" as the channel changed.
A place I worked at in the early 2000's used these in custom-designed acoustic telemetry systems deployed in the ocean (I don't remember which company we bought them from - the website I linked to is just an example of the type of device, but it is very similar). The system needed a way of communicating with devices that were dropped into the ocean and typical radio waves don't travel well in sea water. Acoustic modems were used instead, as sound travels well in water.
>I don't mean sound converted to electricity, or to represent 0s and 1s, but using a specific frequency range to represent 1, another range to represent 2, another for 3... I don't know the terms for these things.
Yup, a company I co-founded http://chirp.io has been using this technique (well, MFSK) to share data over the air, between mobile and embedded devices for a while now.
I'm curious, did you selected audible frequencies (1760hz-10.5khz) because there were the only ones technically feasible with the current popular mics/speakers or because you actually wanted users to hear the data?
I have played with minimodem to do this (FSK) and while cool, it is an unpleasant noise. I managed to transmit at inaudible frequencies but certainly it was very very unreliable with normal consumer hardware.
I recommend running the receiver on a non-mobile device if you try this. Unfortunately running a receiver smoothly from a mobile browser is fairly difficult.
I posted that link a few months ago and it was pretty well-received. Today's submission is more iterating -- the one in the link offers a basic frame-only interface but today's submission is a full network stack
I considered the cross-tab case but couldn't think of an obvious way to implement that. They'd have to get mic permissions, at any rate
Oops, I guess I forgot I approved the mic on that domain already. That's a fair point and it would keep user privacy intact. Excellent demonstrations either way. It's like an audio QR code. Very inspiring!
I know which app you're talking about. I've played with it a little, it seems to just transfer a link/identifier by sound to then download the file via the internet.
Oh yeah, somehow I cant find that app any more. Guess complete data transfer would be prone to error given the medium is sound waves. hence they stuck to link.
