The sound transmission protocol that I am using is very slow - 8-16 B/s, depending on configuration parameters. It can be directly used for sending files, but I think this kind of transfer rate is not very practical. There are some other project that I have seen [1],[2] that might achieve better transfer rate.
This is very cool, because in theory it makes the barrier to entry into a meshnet, effectively zero.
Is it any different conceptually than extending the handshake from analog modems to include the data? From what I hear it sounds like <handshake>{data}.
I assume you can't have an "open" connection because the sound is the transmission medium, so it would have to be constantly talking to keep the line open.
> Is it any different conceptually than extending the handshake from analog modems to include the data?
By "include the data" do you refer to the transmitted file itself being included in the sound? If yes - you can include the file in the sound, but the transmission will be too long, because transfer rate is very slow.
About what is heard as sound: <marker>{SDP data}. All peers initially listen for the <marker> because it is computationally cheaper. When the <marker> is received, then they start listening to the SDP data, which consumes more resources.
Glad I was hearing it correctly (generally). So based on what you write here, it sounds like it can only be one way - which makes sense given the architecture. I'd be curious if it could be made as a continuous two way connection - my guess is yes, but it would take FTDT or FDM to coordinate right?
Yes, it's one-way communication. I guess, extending to two-way can involve any of the practices used in modem communication. The biggest issue though would be dealing with the noise and making it reliable.
You say your data throughput is relatively slow, which makes sense, but it would be super cool to exchange phone numbers/contacts with this. Imagine meeting another geek and exchanging contacts this way! Basically all phones have the hardware required.
13 comments
[ 3.6 ms ] story [ 35.5 ms ] thread[1] https://github.com/quiet/quiet
[2] http://www.whence.com/minimodem/
Is it any different conceptually than extending the handshake from analog modems to include the data? From what I hear it sounds like <handshake>{data}.
I assume you can't have an "open" connection because the sound is the transmission medium, so it would have to be constantly talking to keep the line open.
A lot of cool possibilities here!
By "include the data" do you refer to the transmitted file itself being included in the sound? If yes - you can include the file in the sound, but the transmission will be too long, because transfer rate is very slow.
About what is heard as sound: <marker>{SDP data}. All peers initially listen for the <marker> because it is computationally cheaper. When the <marker> is received, then they start listening to the SDP data, which consumes more resources.
But it seems most problems you could apply this to, you may as well just use Bluetooth or BLE.