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..
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 :)
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.
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?
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.
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?
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 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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.