Menu

Python and the Evolution of Python Audio Tools

As I've transitioned Python Audio Tools from working primarily with audio metadata (track tags, playback parameters, etc.) to handling audio data itself (FLAC decoding, track resampling, etc.) I've come to better understand what Python is good at, and what it still struggles with.

Python is very good at reading in chunks of data, binary or otherwise, parsing them and doing some work with them. It's proven to be fast, reliable and maintainable.

Python is not very good at doing lots and lots of little calculations. ReplayGain playback only works because I can run it in its own thread, despite the simplicity of actually applying it. FLAC decoding, resampling and ReplayGain calculation are all embarassingly slow, despite the use of profiling and C extension modules to speed up the process.

Since software that's too slow isn't practical, I'm going to need a new tactic in order to keep developing stuff that's useful. I could develop bigger and better C modules to do that calculation work. But if I'm doing all the heavy-lifting in C, Python becomes extraneous. I could try to make Python itself much faster and submit some patches, but I suspect there aren't a lot of Really Obvious Speedups I could find. I could try getting my code to run on a "faster Python" like PyPy, but that's some seriously experimental stuff I can't assume everyone will have. I could wait around for hardware to become fast enough to give my Python implementations value, but I might be waiting a long time.

I will continue to ponder this problem. Whether I can solve it and how will determine whether Python Audio Tools will ever evolve beyond their humble metadata-heavy origins into something with a wider purpose.

Posted by Brian Langenberger 2007-12-05

Log in to post a comment.

MongoDB Logo MongoDB