Show HN: Libquiet – transmit data using sound(brian-armstrong.github.io)
brian-armstrong.github.io
Show HN: Libquiet – transmit data using sound
http://brian-armstrong.github.io/quiet/
43 comments
I believe Chromecast uses something similar. While setting it up for my parents I had the receiver switched to a different input and after a little while it asked me to make sure the TV's sound output was not muted.
Edit: ah, another commenter had already confirmed this. That's what you get for not reading all the way through :)
Edit: ah, another commenter had already confirmed this. That's what you get for not reading all the way through :)
This is definitely one of the biggest advantages. Though transmission is obviously much slower, it's still an incredible feature to have in cases where networks don't exist or are too congested, like concerts and sports arenas.
Yeah! I was thinking the same thing -- this could work quite well for pairing.
Thanks for the kind words :)
Thanks for the kind words :)
That would be an interesting application. What could the range be?
Google uses sound for pairing - seems to work okay in reasonably sized room with all kinds of surfaces https://gigaom.com/2014/06/26/chromecast-will-use-ultrasonic...
Wow, so cool.
Wow, this looks like a much better version of something we attempted for a hackathon [1]. I'm probably going to spend the weekend spelunking through this!
Is there a more detailed write up of the inner workings floating around?
[1] https://github.com/rraval/pied-piper
Is there a more detailed write up of the inner workings floating around?
[1] https://github.com/rraval/pied-piper
As a starting point, I'd suggest reading the profiles, which provide all the configuration https://github.com/brian-armstrong/quiet/blob/master/quiet-p...
Quiet's design is typical for what you'd find in a textbook diagram of a modem. It uses liquid SDR to generate the modulated symbols, and then it runs them through an interpolation filter and mixes them up to some carrier frequency.
Quiet's design is typical for what you'd find in a textbook diagram of a modem. It uses liquid SDR to generate the modulated symbols, and then it runs them through an interpolation filter and mixes them up to some carrier frequency.
this is pretty awesome. something similar to this is being used by Silver Push to unify devices to the same owner: http://blog.silverpush.com/silverpush-says-its-using-audio-b...
i'm not a fan of this kind of covert ad tech but i feel that this trend won't be slowing down any time soon...
i'm not a fan of this kind of covert ad tech but i feel that this trend won't be slowing down any time soon...
I love the way people can still use old connection ports (jack for instance) to find new usages.
Made me think about Google Tone : http://googleresearch.blogspot.fr/2015/05/tone-experimental-...
Also made me think about the iPod nano, it only had a single jack port. It was used to charge it and also to transmit data.
Made me think about Google Tone : http://googleresearch.blogspot.fr/2015/05/tone-experimental-...
Also made me think about the iPod nano, it only had a single jack port. It was used to charge it and also to transmit data.
I still have one of the buttonless iPod Shuffles (http://www.macworld.com/article/1139333/iPod_shuffle_design....). I used it regularly for the gym up until I fully switched to streaming services. I still feel it's one of the most zen products Apple has made.
Google Tone made HN nearly a year ago: https://news.ycombinator.com/item?id=9575291
Pretty cool. The issue with ultra sonic transmission is attenuation destroys the signal.
If anyone tried quiet_encode_soundcard and found it glitchy, I'm terribly sorry! I was writing the wrong number of samples to Pa_WriteStream. That bug has been fixed and the fix pushed to master.
It looks like there may also be a bug with the receivers being garbage collected in Firefox in the JS text demo. I'm looking at that now.
It looks like there may also be a bug with the receivers being garbage collected in Firefox in the JS text demo. I'm looking at that now.
Pretty cool library you've put together. Do you plan to build apps or a company on top of it in the future?
Audible transmission worked successfully for me in Chrome but inaudible didn't. Inaudible can get pretty complicated to do robustly because of compression and filtering, as you've mentioned in other comments.
My startup (LISNR) is a content and engagement platform entirely on top of "ultrasonic" audio tones. We started in 2012 and still feel audio transmission tech doesn't get as much attention as it deserves. Especially in use cases where bluetooth beacons have failed to catch on.
Audible transmission worked successfully for me in Chrome but inaudible didn't. Inaudible can get pretty complicated to do robustly because of compression and filtering, as you've mentioned in other comments.
My startup (LISNR) is a content and engagement platform entirely on top of "ultrasonic" audio tones. We started in 2012 and still feel audio transmission tech doesn't get as much attention as it deserves. Especially in use cases where bluetooth beacons have failed to catch on.
Thanks for the feedback. I've generally had good luck in getting the inaudible mode working in desktop Chrome, but I think it needs more tuning to become truly robust.
I don't know that I really plan to do much beyond working on the library. When I started out, I was actually just interested in seeing what sort of bitrate I could achieve on an audio cable but decided to also support air transmission when I realized how similar it would be. I would definitely love to see it get embedded into iOS and Android apps though.
Good luck with your endeavor! Audio data transmission might be "budget tech" but I think it certainly gets the job done.
I don't know that I really plan to do much beyond working on the library. When I started out, I was actually just interested in seeing what sort of bitrate I could achieve on an audio cable but decided to also support air transmission when I realized how similar it would be. I would definitely love to see it get embedded into iOS and Android apps though.
Good luck with your endeavor! Audio data transmission might be "budget tech" but I think it certainly gets the job done.
What's the bitrate and range one can achieve with this? What could be the advantage beyond those of bluetooth (low power) or wifi (range)? What could be applications of this?
The bitrates I've found so far are roughly 40 kbps for cable-based transmission and ~300bps for air transmissions. It should be possible to get even better speeds with more tuning of quiet's profiles. In empirical testing, I've found the air transmissions have a range of a few meters, but it really depends on how the speaker is oriented with respect to the microphone.
As for the advantages, of course traditional radio-based transmissions have many advantages. Quiet has a few though -- for example, with its javascript bindings, you can use quiet to share data between native apps and the browser. You might do this to share what's in your clipboard, share contact info with someone, pair devices etc. Additionally, you can get quiet up and running very quickly, without the need to join any networks.
As for the advantages, of course traditional radio-based transmissions have many advantages. Quiet has a few though -- for example, with its javascript bindings, you can use quiet to share data between native apps and the browser. You might do this to share what's in your clipboard, share contact info with someone, pair devices etc. Additionally, you can get quiet up and running very quickly, without the need to join any networks.
You could also transmit to a whole room full of people without needing to connect to any networks or devices.
Really cool project.
Using ultrasonic sounds to send data isn't new.
Even chromecast is using it to pair to phones without wifi or bluetooth: http://arstechnica.com/gadgets/2014/06/chromecast-will-talk-...
Thanks. I was aware of projects that do similar when I started. I had heard of some TV ad using ultrasonic tones, for example. I figured there should be a nice open library, so anyone could have this tech
Couple this with a System Bus AM Radio [1] for super fun times
[1]: https://github.com/fulldecent/system-bus-radio
[1]: https://github.com/fulldecent/system-bus-radio
There's also minimodem for GNU/Linux systems: http://www.whence.com/minimodem/
This looks really close to what http://www.copsonic.com is using for mobile payment (and other stuff).
Would this work over a compressed (such as VoIP) connection, or even RF radio? Imagine sending a picture over an existing public safety radio network if Internet is disrupted.
I just tried it with speex's wideband setting, and I was able to recover the transmitted message. I had to modify the wav file generator to output in 16-bit PCM instead of float, which speexenc doesn't support.
The narrowband profile also works, but I needed to create a new Quiet profile with a center frequency of 2200Hz.
The narrowband profile also works, but I needed to create a new Quiet profile with a center frequency of 2200Hz.
Think of this as being just another modem connection, just the carrier is audible instead of electrical.
Compression is going to mess with the signal somewhat, and encoded data is not particularly alike to the human speech that most psychoacoustic models are aiming for. But you can get modems to work across some quite poor connections if you keep the bitrate low.
If you don't need to send a bit-accurate binary blob across the network then it's much faster to use such analog modes and accept some corruption. If you wanted to send a picture across a noisy radio network (as emergency-service operation tends to be) I would actually suggest sending a radiofax or a slow-scan TV signal. Lossy compression would distort the picture but the human brain is quite good at dealing with this kind of distortion. This is particularly true of faces - the brain is wired to match faces quickly, which is how we get pareidolia.
https://en.wikipedia.org/wiki/Slow-scan_television
https://en.wikipedia.org/wiki/Radiofax
During WWII the Germans actually used a mode called Hellschreiber that basically sent text as a B+W fax picture, with each line sent twice for resilience. It's not the fastest but it was quite resistant to interference. It's interesting to think of modern improvements we could make nowadays.
http://www.eham.net/articles/11472
Compression is going to mess with the signal somewhat, and encoded data is not particularly alike to the human speech that most psychoacoustic models are aiming for. But you can get modems to work across some quite poor connections if you keep the bitrate low.
If you don't need to send a bit-accurate binary blob across the network then it's much faster to use such analog modes and accept some corruption. If you wanted to send a picture across a noisy radio network (as emergency-service operation tends to be) I would actually suggest sending a radiofax or a slow-scan TV signal. Lossy compression would distort the picture but the human brain is quite good at dealing with this kind of distortion. This is particularly true of faces - the brain is wired to match faces quickly, which is how we get pareidolia.
https://en.wikipedia.org/wiki/Slow-scan_television
https://en.wikipedia.org/wiki/Radiofax
During WWII the Germans actually used a mode called Hellschreiber that basically sent text as a B+W fax picture, with each line sent twice for resilience. It's not the fastest but it was quite resistant to interference. It's interesting to think of modern improvements we could make nowadays.
http://www.eham.net/articles/11472
Way back when we used to scoff at softmodems!
Perhaps using the same encodings as modems do would increase effective bandwidth?
Edit: never mind, looks like it already kinda does.
Perhaps using the same encodings as modems do would increase effective bandwidth?
Edit: never mind, looks like it already kinda does.
[deleted]
Sidechannel bypass for airgaps?
The first time I heard of this technique it was (supposedly?) used for airgapped, infected machines to communicate [0]. I don't remember, though if it was proven in the end that that was actually how the malware communicated. There was some skepticism.
[0] https://en.wikipedia.org/wiki/BadBIOS
[0] https://en.wikipedia.org/wiki/BadBIOS
I thought that the average person could hear from ~20Hz-17kHz (at around 19-20). Wouldn't this mean that the signal would be audible?
Depends on the person. Personally, I can't hear much above 14kHz.
Here's a youtube that runs 20Hz-20kHz if you'd like to check for yourself https://www.youtube.com/watch?v=qNf9nzvnd1k
Here's a youtube that runs 20Hz-20kHz if you'd like to check for yourself https://www.youtube.com/watch?v=qNf9nzvnd1k
Yep that's definitely true, but on average 17kHz is the cut off for 19-20. I know first hand that there are uncommon people, like me.
Through an accident with way too many fireworks, or not enough fireworks depending on how you look at the situation, I hear a random high C noise when it's completely quiet. My hearing in my right ear cuts out at around 15kHz.
But on average. anything under 17kHz is audible to the average teen-young adult.
Through an accident with way too many fireworks, or not enough fireworks depending on how you look at the situation, I hear a random high C noise when it's completely quiet. My hearing in my right ear cuts out at around 15kHz.
But on average. anything under 17kHz is audible to the average teen-young adult.
In your app, the "ultrasonic" signal is still audible to me. On that youtube video, I stop hearing stuff around 17,5kHz.
Youtube compresses audio above 17kHz so it shouldn't be audible at all past that.
Note: It's at some random value that isn't exactly 17kHz, I think it's 17.6kHz? So it no longer making sound for you at 17.5kHz could be because of that, not because of your hearing.
Note: It's at some random value that isn't exactly 17kHz, I think it's 17.6kHz? So it no longer making sound for you at 17.5kHz could be because of that, not because of your hearing.
Perhaps I should have labeled it author-ultrasonic ;)
I haven't really found much data about the distribution of hearing capacities, so it's hard to tune this to be truly ultrasonic. The average sound equipment starts getting really distorted at around 19kHz, which doesn't leave much space above 17,5, unfortunately.
Thanks for trying my demo!
I haven't really found much data about the distribution of hearing capacities, so it's hard to tune this to be truly ultrasonic. The average sound equipment starts getting really distorted at around 19kHz, which doesn't leave much space above 17,5, unfortunately.
Thanks for trying my demo!
My range was from about 160 Hz to about 16 kHz, assuming that those are not the limits of the speakers on my tablet. I am 25 years old.
Q1: Do you have some BER versus SNR measurements, especially for the speaker->mic path through air?
Q2: For ultrasonic: Most cheap ultrasonic transducers are very narrow band around 40KHz. Are there barriers to moving the carrier frequency up to that range?
Q3: After a very quick look at the doc, I didn't see what kind of encoding scheme you are using?
Q2: For ultrasonic: Most cheap ultrasonic transducers are very narrow band around 40KHz. Are there barriers to moving the carrier frequency up to that range?
Q3: After a very quick look at the doc, I didn't see what kind of encoding scheme you are using?
I don't have actual numbers. That'd be a very good thing to check. It uses convolutional codes and viterbi decoding which helps reception and decoding considerably.
I suppose I should really call it nearly ultrasonic. Since I've only been able to play with standard sound hardware, and this hardware always has a low-pass filter that cuts off around 20kHz, that's the absolute highest frequency I've been able to test. When I say 44.1kHz I just mean the sampling frequency -- perhaps I should have been clearer about that, sorry :)
The modulation scheme for the air path is GMSK. For cable transmission, it's OFDM + QAM1024.
I suppose I should really call it nearly ultrasonic. Since I've only been able to play with standard sound hardware, and this hardware always has a low-pass filter that cuts off around 20kHz, that's the absolute highest frequency I've been able to test. When I say 44.1kHz I just mean the sampling frequency -- perhaps I should have been clearer about that, sorry :)
The modulation scheme for the air path is GMSK. For cable transmission, it's OFDM + QAM1024.
You can broadcast data without a network.
Edit: I actually prefer this to the clumsy QR code scanning, maybe I'll use it for device pairing. Would also be a great tool to pair devices which don't have a display.
But the sounds produced remind me of the background noise in a forest.
Which makes me think that maybe if you used this lib to listen to the noises in a forest and then try and look for interesting patterns in that data..
Anyway, cool lib, will bookmark it.