I am Django/Python backend, PyTorch user, and React, iOS a bit. I am not interested to code at C/C++ level
Supposed I would like to make 2 simple applications written in Python with my Librem Phones as follows
Does Librem Phone SDK support on this?
Yes, the L5 should support ad-hoc networks. It also could probably use bluetooth, at least at close range. I doubt purism will write the software needed for it, but it isnât actually that complicated to set up. For energy savings, I would strongly suggest at least using cython or pypy for the programs, since cpython is pretty terribly inefficient and the CPUs a power hog.
Trivial. Audio routing is done in userspace. Route it via aplay to speex-enc (to compress/denoise it), route it to a stream encryption program, route that via a data channel to the other phone, reverse the process. If you want to send it over the voice channel, either use an encryption scheme that wonât mind some signal degradation, or use a transmission protocol layer which wonât suffer degradation (would potentially require resending data).
Iâm not sure which approach would get better results. The loss-tolerant version will be faster and take less audio bandwidth (just sound like static/clicks/pops on the line), but might not decode into intelligible audio on the other end. The lossless version would take more CPU power and probably have higher latency. In neither case would it require writing software from scratch, you can just use a userspace dial-up modem program to negotiate the digital layer, which will handle resending data.
The slightly harder part would be automatically enabling encryption if both ends support it. Best bet there would be to automatically send a ultra high frequency tone in a specific pattern, and analyze the call to listen for that tone to start negotiation⌠That would be non trivial to implement, but still possible. The simpler method would be a button to push to enable it, or to enable it on a number-by-number basis.
Just a hint - working with multiple audio processors in a pipeline to me is way more easier using gstreamer. You can write your own plugin which will do handshakes, adaptive negotiation, etc. and thereâs huge collection of existing plugins of which you may find almost all necessary to achieve your goals.
@lperkins2 Your answer reminds me the networking class I took 10 years ago. Hope SDK has Python wrapper for me. Since Librem 5 user in Thailand would be only I and my co-founder. I donât need any generic way to exchange or transmit public key over voice network. I will hardcode in the application itself and physically install them from my end. This project is not only for fun, but also my freedom
@ruff Thank you for sharing
Oh, this is so cool! I can see this working with starting an unencrypted voice call, and seeing on a status line whether or not the keys are current and trusted. âOK, letâs go encrypted!â Press a button and it negotiates the encrypted stream. Maxwell Smart should have had it so good!
So there are 2 separate, but related, features. One is identity verification (keys are current and trusted), which requires having previously exchanged keys or otherwise verified the other userâs identity. The other is channel encryption (no one can listen in), which doesnât require any authentication, just a DH key exchange. In theory, the L5 can do both.
Is this basically the same idea as a dial-up modem? Encrypt some voice/video data, then convert it to audio and squeeze it through a voice call, before reversing the process at the other end.
The idea of a dial-up modem gets a bit blurred in the mobile phone world, because dial-up networking was quickly replaced with more dedicated data channels, for efficiency, culminating in the latest high-speed networking. Apart from billing considerations, I donât think any currently-used mobile phone is without some means of establishing a data connection that could be used instead of a voice call.
But voice calls have the advantage of being able to use telephone numbers, which act as globally-unique identifiers. For data connections, you have to find another way of linking up, and you probably have to traverse NAT at both ends, too.
Perhaps itâs possible to do something where an initial handshake and NAT hole-punching occurs using a voice call or a SMS text message, before handing off to a data connection for the actual call.
Yes, exactly the same idea as a âdial-upâ connection. Convert the digital data into beeps, then interpret the beeps on the other end. Thereâs standard programs for doing it, should be able to handle 56kbps at least, which is enough for voice.
Nice thing is you can use it to transfer files and the like too, without paying for data usage if your phone service doesnât include data free.
With all the chatter here, I am going to have fun with my 15" Librem Laptop when I order it next year.
I seriously enjoy being a polymath and lifelong learner. What you guys are talking about could be very fun.
I donât think thatâs possible. 56k works on landlines because digital telephone exchanges encode the call audio at a little above that rate. Standards for mobile phones define lower bitrates.
Back in the day, you could use Circuit Switched Data, which is kinda sorta a dial-up connection, and get up to 9.6kbps, billed per unit time like an ordinary phone call. Otherwise, according to the article I just linked to, it looks like you would get no more than 2.4kbps if you encoded the data into a voice call using a modem. Iâm guessing thatâs based on calls using Full Rate or Enhanced Full Rate.
Nowadays, you might be able to squeeze a bit more data through a voice call, because there seem to be higher bit-rate standards, like AMR-WB and AMR-WB+, but you wonât reach 56kbps and youâre not guaranteed that the call will use these standards.
[Thanks for a fun diversion into reading about this stuff!]
I hadnât considered that the voice channel is (obviously) digitized too. Land lines generally are too, for that matter. This means even modern techniques like using multiple pitches of beeps simultaneously cannot get more bandwidth out than the underlying digital carrier. So yeah, itâs gonna be limited by that. Of course, we can still compress the heck out of the signal. Voice mostly requires the 1800-2000 Hz range, so a high pass/low pass filter to only include that range and a good block size should get acceptable audio quality out the other side (at the cost of slightly higher latency and significantly increased CPU drain).
@lperkins2 Where I can find Python Voice SDK you mentioned?
What I have seen before they are C/C++
Do I need to buy L5 first and then be able to get access to Python SourceCode?
I expect my use case from developer experience be like Android, iOS. But the different thing is I donât need a simulator. I just push binary code or python source into it and run with pyenv on L5
I would be very happy to start record my L5 Python developer journey with its hardware
I have laggy T400, but still rock. So I would focus on L5 since I am going to experiment them. The reason why I have to buy more than 1 device is I might be the only L5 user in Thailand
Not python specific. My usual toolbox is ffmpeg, sox, and alsa-utils (+ jack2, but thatâs just because I hate pulseaudio). Each of these tools are stream processors, they take data on standard in (or a file) and do something to it, then send it to standard out (or a file). You can do simple testing just by using bash IO redirection. For real use, I usually use the subprocess module in python, so that I can deal with underruns, jack (or pulseaudio) integration, and so on.
Note that real-time voice requires real-time process scheduling, which takes very careful planning in a reference counted language like CPython. You can use it to set up real-time friendly programs easily enough, but itâs nearly impossible to get real-time audio using python directly.