3 ms·

The SIP stack implementation in Python is good. But RTP part - Python can't keep up with real time requirement of RTP, bursting out packets every few millisecon

The SIP stack implementation in Python is good. But RTP part - Python can't keep up with real time requirement of RTP, bursting out packets every few milliseconds. Even after depending on C code for encoding/decoding. There once was an attempt to code softphone (shtoom - https://sourceforge.net/projects/shtoom/files/ https://sourceforge.net/projects/shtoom/files/ ) in pure python by Anthony Baxter and was later abandoned. There are some jobs that python can't cut it.

jacobush 8y ago
The most common implementation of Python can't cut it. But other implementations might, such as PyPy. Cython almost certainly could, but it's a super-set of the Python language so maybe it shouldn't count. I am thinking of
devxpy 8y ago
Oh boy, I just wrote a 100 line client and another 100 line server that is able to do real time voice communication, comparable to the likes of telegram. (In python) Albeit it uses portaudio (python-soundevice) for the audio IO which is not written in python, and opus which isn't written in Python either. But all the glue and udp communication is pure python. And P.S. - pulseaudio uses more CPU than my thingy. Talking about production, I suspect the guys at OnBeep are making use of python a lot, just looking at their GitHub repo https://github.com/OnBeep https://github.com/OnBeep (The python opus bindings are created by them) I'm just tired of people underestimating the speed of python. Its often a matter of not using it correctly...
- godsongera 8y ago
  This is different than doing pure python implementation. Python acting as glue is most suitable solution when heavy lifting is done by C code. I have used pjsip/pjsua lib with python bindings which performs beautifully.
  - devxpy 8y ago
    Maybe "pure" python can't do fast sound processing, I can accept that. You have to at least use scipy/numpy. But his claim of "Python can't keep up with real-time requirement of RTP, bursting out packets every few milliseconds" seems bogus to me.
devxpy 8y ago
Oh, and ftr - I'm "bursting out packets" at 10ms intervals. I have tried 5 and the problem still wasn't speed, it was the cracking noise caused by such small samples

jacobush 8y ago

The most common implementation of Python can't cut it. But other implementations might, such as PyPy. Cython almost certainly could, but it's a super-set of the Python language so maybe it shouldn't count. I am thinking of

devxpy 8y ago

Oh boy, I just wrote a 100 line client and another 100 line server that is able to do real time voice communication, comparable to the likes of telegram. (In python) Albeit it uses portaudio (python-soundevice) for the audio IO which is not written in python, and opus which isn't written in Python either. But all the glue and udp communication is pure python. And P.S. - pulseaudio uses more CPU than my thingy. Talking about production, I suspect the guys at OnBeep are making use of python a lot, just looking at their GitHub repo https://github.com/OnBeep https://github.com/OnBeep (The python opus bindings are created by them) I'm just tired of people underestimating the speed of python. Its often a matter of not using it correctly...

godsongera 8y ago
This is different than doing pure python implementation. Python acting as glue is most suitable solution when heavy lifting is done by C code. I have used pjsip/pjsua lib with python bindings which performs beautifully.
- devxpy 8y ago
  Maybe "pure" python can't do fast sound processing, I can accept that. You have to at least use scipy/numpy. But his claim of "Python can't keep up with real-time requirement of RTP, bursting out packets every few milliseconds" seems bogus to me.

devxpy 8y ago

Oh, and ftr - I'm "bursting out packets" at 10ms intervals. I have tried 5 and the problem still wasn't speed, it was the cracking noise caused by such small samples