前言：Chirp在iPhone上掀起了有聲傳輸文件的序幕，我們再也不需要彩信、藍牙配對、IM來傳送數據。它通過“嘰嘰喳喳”的小鳥叫聲來分享數據，簡單有趣，而且可以快速的實現一對多的分享。
此外支付寶曾經試推過“聲波支付”，利用手機發送超聲波至終端作爲交易密碼進一步完成交易。然而支付寶的技術目前只是使用在了支付上，而需要可接受聲波支付的特定售貨機方可使用。
《Advanced Sound for Games and Interactive Apps - WebAudio API》的作者Boris Smus用HTML5的Web Audio API實現了一個基於Web的超聲波互聯方案，通過這種方式不需要安裝任何客戶端，也不需要藍牙或者NFC的支持，就能夠將兩臺用瀏覽器上網的設備連接到一起並傳遞圖片、音樂、視頻等文件。這個idea很酷，幫助我們在Web的功能和應用層面邁進了一大步（這種想法也許你都想所未想，聞所未聞），下面我們就一起來看看具體的原理和實現過程。
……………………………………✄……………………………………華麗的分隔線
你口袋裏的手機是一個酷炫的、美觀的、有很多功能的工具。但是當它想要和其它設備對話時，例如電視或者筆記本，用戶體驗就大幅下降。Bill Buxton關於這個主題有一個極富感染力的演講，描述了高科技演化的三個階段：
1、設備工作：功能的完整性和穩定性
2、 設備流暢：良好的用戶體驗
3、 許多設備在一起工作
我們已經隨着iPhone的發佈，正式的進入了第2個階段，但是連接設備是一件讓人痛苦的事情。有許多方法來實現這一點：藍牙、藍牙LE、WiFi直連、通過本地WiFi網絡發現等等。這篇文章通過一個完全讓人意想不到的角度來解決這個問題：利用超聲波來廣播和在相鄰設備間發送數據。最重要的是，這種方法採用Web Audio API，使得純Web應用的連接成爲可能。
設備的通天塔
Airplay 和 Chromecast是解決同一生態系統（例如蘋果或谷歌）內設備連接問題的偉大方法 ，但是普遍問題仍然難以得到解決。
因爲有許多可能的技術途徑，所以可能碰巧你要連接的設備間沒有共同的方法。即便兩個設備都有藍牙，其中一個或許需要配置，但是另外一個卻不支持，或者是支持不同版本的標準。現在這對於藍牙來說尤其普遍，許多設備硬件上支持藍牙4.0（又名BTLE），但是很多設備卻因爲各種原因不支持這個最新的協議。
在Web上這種情況甚至更糟，因爲低級別設備的連接API因爲安全沙盒方面的原因並沒有提供。而由於Web的發展非常慢，所以很難想像這種情況能夠在短時間內得到解決。
通過有趣的方式傳輸數據
Electric Imp提供的Blinkup是一種跨端通信的有趣方式。它使用了一系列閃光來在智能手機和Imp – 一種形似小型SD卡並帶有光線傳感器的設備間傳輸數據。
撥號調制解調器做了類似的事情。它們在模擬電話線上編碼和解碼數字數據。還記得那些煩人的連接噪音嗎？撥號調制解調器會打開揚聲器來讓用戶瞭解正在進行握手。如果你忘記了這些，可以在這兒複習一下。即使在今天的模擬電話裏，你在鍵盤上按下數字鍵時聽到的聲音也相當於電話系統用於模擬數字轉換的頻率。這個轉換使用了雙音多頻信號（DTMF）。
你的手機和周圍的其它很多設備都有揚聲器和麥克風。這兩種硬件可以用聲音來發送和接收數據，類似於調制解調器在電話線路上所做的事情。更妙的是，如果操作系統支持發送和接收的頻率足夠高，我們可以創建一個無聲的數據通道。
用聲音傳輸數據
我應該注意到通過聲音編碼數據並不新穎。音頻水印的創意就是把簽名編碼到音樂中，聽衆通過人類的方式並無法識別，但是卻能夠被另外一臺設備所理解。這是一種防止盜版的聰明方式。
大多數普通的揚聲器能夠產生44.1KHz採樣率的聲音（這導致最高的頻率爲22KHz - 根據香農採樣定理）。這讓我們將數據不僅編碼爲聲音，還會產生成人無法聽到的音頻。不過兒童和動物仍然有可能會聽到：）
技術上需要注意的是，麥克風有時候與揚聲器並不兼容，尤其是在手機上，因爲它們經常會針對人們的通話進行優化，通過更低的採樣率來讓聲音效果更佳。在另外一些情況下，即便硬件兼容，固件也需要運行在低採樣率上來保證電量供應。如果是這樣的話，設備將無法接收聲波，同時基於聲音的連接將只能單向進行。
SONICNET.JS，一個Web Audio的實現
爲了說明這些概念，我搭建了一個JavaScript庫，用於通過聲音發送和接收數據。我的做法沒有學習複雜的音頻水印技術，甚至比DTMF更爲簡便。基本上，你可以指定使用一個範圍的頻率，以及可以傳送的字母集合。頻譜被分成對應於所指定開始和結束字母之間的範圍，每個字母/代碼對應整個頻率範圍內的一部分。
發送端將需要發送的每個字符轉換爲對應頻率範圍的中點值，並且在一個時間間隔內發送該頻率。接收端會對信號進行不連續的傅立葉變換（宇捷注：我的本科專業就是信息與通信工程，學過數字信號處理的朋友應該對此非常瞭解），並且尋找指定頻率範圍內的峯值。在找到一個信號間隔內的峯值後，它會將頻率轉換回字符。這基本上是一個單音多頻信號（STMF）的方案。
有一個發送時機的問題：在發送端，應該多長時間發送一個字符；在接收端，應該多長時間接收？我們用了一個簡單的方案來規避相鄰的重複字符。
我設計了一個類似於socket的API用於聲波通信。客戶端代碼看起來如下所示：
ssocket = new SonicSocket({alphabet: '0123456789'});
function onButton() {
ssocket.send('31415');
}服務端看起來像這樣：
sserver = new SonicServer({alphabet: '0123456789'});
sserver.on('message', function(message) {
//Expect message to be '31415'.
console.log(message);
});
sserver.start();JS庫支持github。
當然，使用它需要一個Web Audio的實現（大多數在發送端使用OscillatorNode ，在接收端用AnalyserNode ）。我已經嘗試過Macbook上Chrome到Chrome，以及Mac Chrome到Android Chrome的傳輸案例。
我寫了一對示例來說明這個想法。它們出現在本文開頭所演示的視頻裏。第一個示例讓你可以從一臺設備上發送表情到另外一臺。它使用了一個很小的字符集，僅僅包括6個字符，每個對應1種表情。你可以從6種表情中挑選一個，對應的字符將會通過聲波網絡發送出去，在另一端被接收和展示出來。
一種對sonicnet.js更爲現實的應用是這個聊天應用，生成不重複的5位數令牌並且用它來在2臺設備間創建連接。這在配對服務器的幫助下完成，在這兩臺設備間通過WebSocket來建立代理連接。一旦連接建立後，對話本身將通過WebSocket發送。服務端代碼託管在nodejitsu上。
結論和期望
Web Audio API已經可以演變到讓這樣的應用成爲可能，這是重大的進步。我迷上了sonicnet.js物聯網上的實現。這是純Web技術，可以用來對設備進行配對。無處不在的瀏覽器和音頻硬件相結合將會是一個巨大的勝利，甚至在硬件層面，Web平臺完全不需要等待藍牙或其它近場連接技術的成熟。
如果這篇文章已經激起了你的興趣，你可以嘗試使用sonicnet.js來編寫一個應用。就像我前文提到的一樣，接收高頻音頻因爲硬件/固件限制並不是在所有的設備上都可用，所以我很想知道哪些可用，而哪些不可以。我的期望是，大多數手機應該只能發送，而大多數筆記本可以同時接收和發送。如果你在你的設備上嘗試了表情演示，請填寫這份表格。在寫這篇文章的時候，Android平臺上Chrome Beta版本並不支持實時輸入，所以從手機傳輸數據到筆記本是唯一的選擇。
相關鏈接：