[Discuss-gnuradio] [UHD] Introducing the Python API

[Martin Braun]

Hi all,

some people have already heard the rumour that we're working on a Python
API for UHD that does not involve gr-uhd. And yes, it's true. A minute
ago, I published our current development branch on github:

https://github.com/EttusResearch/uhd/tree/python-api

We'll be doing some more development on this branch before we're merging
it, but most importantly, we'd like to get some feedback from the
greater community.

The biggest thing missing is more documentation, but it already includes
some examples. It's definitely ready for testing!
If you have feedback, post it either in this thread, or on github:
https://github.com/EttusResearch/uhd/issues/105

I've tried to preempt some questions:

- Does it support Python 2 and 3? Yes.
- Does it use SWIG? No, it uses Boost.Python. We didn't want to add
another dependency to UHD (i.e., SWIG) and Boost was already a
dependency of UHD. It also doesn't require the C API.
- How does this relate to the Python API in gr-uhd? It serves an
entirely different purpose. This Python API is for people writing
standalone applications for USRPs that *don't* use GNU Radio. gr-uhd is
staying the way it is, and is going nowhere. If you're using GNU Radio,
you probably don't care about this.
- Are the UHD Python API and the gr-uhd Python API compatible? Short
answer: No. Long answer: There are very few cases where it makes sense
to mix these APIs, so no. However, this means that a TimeSpec from the
Boost.Python API is not convertible into a time_spec_t from the gr-uhd API.
- When will it be released? TBD, but if we hear a lot of encouragement
that'll drive things along faster. It'll go into master branch whenever
it's considered stable enough, and then in the first major release after
that merge.
- Does it support RFNoC API? Not yet, but it's not hard to add. We
wanted to get the basics (i.e. multi_usrp API) right first.
- What's the streaming performance? Worse than straight C++. Better than
I would have thought, thanks to numpy. We have no benchmarks yet.
Overall, recv() calls are pretty efficient if you've preallocated a
numpy array, because we can cast that to a straight pointer (and also
skip any type checking!!!!!!) and then it's not that different from a
recv() call in a C++ app. However, consuming the data is limited by how
fast you can handle that in Python.


We're really looking forward to feedback from the community.

Cheers,
Martin