Topic: [BOUNTY - 25 BTC] Audio/Modem-based communication library - page 2. (Read 11891 times)

Hello roman.z,etothepi and other people.

I am mostly a webdeveloper by trade, but I tinker a lot with audio as well (amongst other things, creating 100% code-generated song covers known as '/predfate2lq]Bytebeat'), and might aspire to become a full-fledged synthesizer developer or something of the likes in the future.



This truly is a very interesting idea. I would give it a shot myself, if it were not that roman.z was already doing such great work already; I don't want to make a competition about this and rather think that it's better to collaborate.

Some thoughts I stumbled upon while thinking about from your solution:
-Are you using mono or stereo audio cables right now? From the source cpde it seems to me you're not. Most computers have a built-in stereo input/output, and this would mean that you can effectively double the amount of carrier waves, and thus double the speed.
-You might want to look into QAM instead of using QPSK/8PSK, which basically adds amplitude-shift-keying on top of the phase-key shifting, greatly enhancing the amount of constellations (and thus the amount of data throughput)


Have a nice day,

~W-M

Regarding smartphone<->PC communication: it's indeed an interesting problem. I'll think on it...

Awesome!  Those are very encouraging results.  I am busily working on the Armory 0.92 release, but after that I will have some time to see if I can reproduce your results locally.   If so, I think you deserve a bounty!    I encourage anyone else subscribed to this thread to collaborate with roman.z and see if you can get his solution working and verify that it works.  I pay out once I can use the solution to move a 2MB file between two laptops reliably, as long as the performance is somewhat close to what you just described.

Overachiever's goal:  can you find the right cables to move data back and forth between a smartphone or tablet?  How difficult would it be to demonstrate that you get sufficient performance?  I like the idea of taking a tx on your phone to the safe-deposit box, plugging in a 2-way cable between the phone and computer, and letting them do their thing.  Or two smartphones -- one online one offline.  Granted, android dev is a little out of scope for this bounty, but if we can at least propose a feasible path to getting there and expect that its performance will be acceptable, I think this solution will be 110% complete!

Good news, every one

I have used today a proper audio cable (instead of a headset) to connect between my PC's audio output and input, so the noise went down dramatically.
This way I was able to achieve 36kbps (after ECC) to successfully transmit 64kB

...

Using 36kpbs MODEM throughput, we can transmit 5MB = 40Mb in ~1111 seconds = 18.5 minutes.

$ ./test.sh
+ set -e
+ dd if=/dev/urandom of=data.send bs=1024 count=64
64+0 records in
64+0 records out
65536 bytes (66 kB) copied, 0.00955402 s, 6.9 MB/s
+ python send.py
Running MODEM @ 40.0 kbps
Encoded 65536 bytes
$ arecord rx.int16 -q -f S16_LE -c 1 -r 32000
$ aplay tx.int16 -q -f S16_LE -c 1 -r 32000
Took 17.27 seconds
+ python recv.py
2014-07-09 08:38:23,480 INFO         Carrier detected at ~58.0 ms @ 1.0 kHz: coherence=100.000%, amplitude=0.402
2014-07-09 08:38:23,483 INFO         Carrier starts at 57.500 ms
2014-07-09 08:38:24,058 INFO         Prefix OK
2014-07-09 08:38:24,058 INFO         Frequency error: -0.02 ppm
2014-07-09 08:38:24,146 INFO                1.0 kHz: Noise sigma=0.0040, SNR=47.9 dB
2014-07-09 08:38:24,235 INFO                2.0 kHz: Noise sigma=0.0034, SNR=49.5 dB
2014-07-09 08:38:24,323 INFO                3.0 kHz: Noise sigma=0.0026, SNR=51.8 dB
2014-07-09 08:38:24,411 INFO                4.0 kHz: Noise sigma=0.0027, SNR=51.4 dB
2014-07-09 08:38:24,500 INFO                5.0 kHz: Noise sigma=0.0032, SNR=50.0 dB
2014-07-09 08:38:24,588 INFO                6.0 kHz: Noise sigma=0.0025, SNR=52.0 dB
2014-07-09 08:38:24,676 INFO                7.0 kHz: Noise sigma=0.0034, SNR=49.4 dB
2014-07-09 08:38:24,765 INFO                8.0 kHz: Noise sigma=0.0042, SNR=47.6 dB
2014-07-09 08:38:24,853 INFO                9.0 kHz: Noise sigma=0.0075, SNR=42.5 dB
2014-07-09 08:38:24,941 INFO               10.0 kHz: Noise sigma=0.0197, SNR=34.1 dB
2014-07-09 08:38:24,941 INFO         Demodulation started
2014-07-09 08:38:36,076 INFO         Demodulated 616560 bits : 77.070 kB @ 11.134 seconds
2014-07-09 08:38:37,469 INFO         Decoded 65.536 kB
+ python errors.py data.recv data.send
0/524288 bit error rate: 0.000%

By the way, is the BTC bounty still open?

$ source env/bin/activate
$ pip install matplotlib
$ PYLAB=1 python recv.py
Carrier detected at ~2242.0 ms @ 10.0 kHz: coherence=99.411%, amplitude=0.400
Carrier starts at 2241.688 ms
Prefix OK
Frequency error: 1.52 ppm
       8.0 kHz: Noise sigma=0.0790, SNR=22.0 dB
       9.0 kHz: Noise sigma=0.0407, SNR=27.8 dB
      10.0 kHz: Noise sigma=0.0348, SNR=29.2 dB
      11.0 kHz: Noise sigma=0.0288, SNR=30.8 dB
Decoded 5 blocks = 1150 bytes (ECC overhead 9.8%)
Decoded 1024 bytes
$ python errors.py data.send data.recv
0/8192 bit error rate: 0.000%

$ python show.py rx.int16

OTOH, QR-video would work.  But that's significantly more complex than using static QR codes and there's very few libraries out there to choose from.

Am pretty sure even etotheipi has changed his mind about QR codes.

$ virtualenv env
$ source env/bin/activate
$ pip install reedsolo numpy
$ python recv.py

Attribution is fine.  Adding their logo and acknowledgment to our website would probably be fine, too, if we actually integrate the solution into Armory.  If that's easiest for you, do it. 

Quick Update:

OpenAL isn't open source anymore. It's mainly maintained under a proprietary license for Windows only. There is a fork of the original implementation that's somehow maintained but I've decided to move on to PortAudio, an open source cross platform audio library.

PortAudio comes with built in ASIO support, which is a low latency cross platform audio driver under a proprietary license. However the SDK and drivers are free to download and use, and the license is free of fees and royalties. They essentially only ask to be mentioned and have their logo added to product boxes and websites.

If that's not ok, I'll dump ASIO. However I think it would allow easier cross platform deployment to have a unified driver. Waiting on your input.

I see no reason to spend any effort on securing the channel, beyond making sure that the offline device is getting data from the correct online device (no injection).  But given the SNR of a direct audio cable, I'm not concerned about that either.  This is purely a bandwidth issue.

Compression would be great, except I wouldn't count on it to help very much, since the transactions are mostly hashes which aren't compressible.  I would guess you'd get no more than 5%-10% compression.  So again, the real bottleneck here is how many bits-per-second you can reliably push over the audio channel.

It's entirely possible to secure the channel however. My primary intention was to compress the data to be sent and uncompress it on the other side, since the bottleneck is channel bandwidth rather than CPU cycles, however, it could be used without compression and a SSL handshake kind of setup to secure the channel. That would be kinda slow however.