Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons learnt building a real-time audio application in Python

vangemert.dev

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Lessons learnt building a real-time audio application in Python

#21

Post by CyberDildonics »

camtarn wrote: post #2

"It turns out that the round-trip time from an audio interface, through a computer (DAW) and back to the speakers takes a few hundreds of milliseconds, making direct audio processing impossible using consumer hardware." - uh, what? Real-time audio processing has been a thing for at least a couple of decades. It doesn't work by default on Windows, but you can get free drivers (ASIO4All) which make it work on pretty mu…

When you see someone using python for something as real time and latency sensitive as audio don't you expect more wacky red flags on top of the fact that python is going to 50x to 100x slower than a native program?

Crazy numbers on top of a dictionary of arrays? It's all there.

Re: Lessons learnt building a real-time audio application in Python

#22

Post by helpfulContrib »

PhunkyPhil wrote: post #3
camtarn wrote: post #2

"It turns out that the round-trip time from an audio interface, through a computer (DAW) and back to the speakers takes a few hundreds of milliseconds, making direct audio processing impossible using consumer hardware." - uh, what? Real-time audio processing has been a thing for at least a couple of decades. It doesn't work by default on Windows, but you can get free drivers (ASIO4All) which make it work on pretty mu…

+1. In Ableton on Windows you can get your latency down to ~40ms without a dedicated sound card using ASIO. Mac's drivers are even better with sub ~20 ms on my m2 pro IIRC.

[dead]

Re: Lessons learnt building a real-time audio application in Python

#23

Post by physicsguy »

I love Python a lot and I’m first to criticise people complaining about performance when it’s irrelevant (if you’re doing long calculations in NumPy or whatever then the Python overhead is small relative to the hot path).

But as others have said, it’s not a great tool for real time audio since that overhead starts to be a larger % of the time spent. You might want to try compiling parts of it with Cython and using the C API of numpy with that (you can do cimport numpy in your Python code and it’ll remove much of the overhead as it’ll call the C functions directly rather than their wrappers).

Re: Lessons learnt building a real-time audio application in Python

#24

Post by camtarn »

CyberDildonics wrote: post #21
camtarn wrote: post #2

"It turns out that the round-trip time from an audio interface, through a computer (DAW) and back to the speakers takes a few hundreds of milliseconds, making direct audio processing impossible using consumer hardware." - uh, what? Real-time audio processing has been a thing for at least a couple of decades. It doesn't work by default on Windows, but you can get free drivers (ASIO4All) which make it work on pretty mu…

When you see someone using python for something as real time and latency sensitive as audio don't you expect more wacky red flags on top of the fact that python is going to 50x to 100x slower than a native program? Crazy numbers on top of a dictionary of arrays? It's all there.

Not necessarily. "I convinced this language/system to do something it really wasn't designed to do by optimising everything" is a well established genre of article :)

Re: Lessons learnt building a real-time audio application in Python

#25

Post by spmvg »

physicsguy wrote: post #23

I love Python a lot and I’m first to criticise people complaining about performance when it’s irrelevant (if you’re doing long calculations in NumPy or whatever then the Python overhead is small relative to the hot path). But as others have said, it’s not a great tool for real time audio since that overhead starts to be a larger % of the time spent. You might want to try compiling parts of it with Cython and using th…

Cython and related tools will be the direction to take if performance becomes a bottleneck indeed! Interestingly enough, the audio callback is being handled fast enough on my not-impressive laptop and CPU usage has been low on average (<1%), so Python trickery hasn't been needed yet

Re: Lessons learnt building a real-time audio application in Python

#26

Post by spmvg »

CyberDildonics wrote: post #21
camtarn wrote: post #2

"It turns out that the round-trip time from an audio interface, through a computer (DAW) and back to the speakers takes a few hundreds of milliseconds, making direct audio processing impossible using consumer hardware." - uh, what? Real-time audio processing has been a thing for at least a couple of decades. It doesn't work by default on Windows, but you can get free drivers (ASIO4All) which make it work on pretty mu…

When you see someone using python for something as real time and latency sensitive as audio don't you expect more wacky red flags on top of the fact that python is going to 50x to 100x slower than a native program? Crazy numbers on top of a dictionary of arrays? It's all there.

Half the fun of this project has been doing it in Python and performance hasn't been an issue so far, which says something about how fast Python is already. And indeed native would be ~50x-100x faster.

I must defend the design choice for the dictionary of arrays though, this has been a very conscious choice:

  - The "dictionary-of-arrays" approach allows lookups in constant time O(1), irrespectively of how much data has already been stored (compared to one big array)
  - The dictionary structure allows me to throw away data in the middle easily (without having to handle growing arrays), because the "dictionary-of-arrays" has already been chunked. The audio looper will use only some parts of the recorded audio, leaving big parts in between unused.

Re: Lessons learnt building a real-time audio application in Python

#27

Post by spmvg »

camtarn wrote: post #24
CyberDildonics wrote: post #21

Earlier quoted context omitted.

When you see someone using python for something as real time and latency sensitive as audio don't you expect more wacky red flags on top of the fact that python is going to 50x to 100x slower than a native program? Crazy numbers on top of a dictionary of arrays? It's all there.

Not necessarily. "I convinced this language/system to do something it really wasn't designed to do by optimising everything" is a well established genre of article :)

:)

Re: Lessons learnt building a real-time audio application in Python

#28

Post by spmvg »

kibibu wrote: post #20
spmvg wrote: post #13

Earlier quoted context omitted.

Debugging an existing DAW to see how they do it under the hood is an interesting idea. Haven't done that yet. About another interface: I do want to keep the application supporting cheaper interfaces such as the Scarlett, because the target audience (hobby musicians) will be using those. Still would be a nice upgrade for me!

Can take a peek at how Tracktion engine does it too

Tracktion looks like an interesting project, thanks for pointing me to this!

Re: Lessons learnt building a real-time audio application in Python

#29

Post by pjmlp »

camtarn wrote: post #2

"It turns out that the round-trip time from an audio interface, through a computer (DAW) and back to the speakers takes a few hundreds of milliseconds, making direct audio processing impossible using consumer hardware." - uh, what? Real-time audio processing has been a thing for at least a couple of decades. It doesn't work by default on Windows, but you can get free drivers (ASIO4All) which make it work on pretty mu…

The damage that Python not having a JIT has done.

At least BASIC was designed for native code compilation from day one, and after the 8 bit home computers generation passed by, getting compilers for 16 bit home computers was rather easy.

30 years later, people insist in using bytecode interpreted language for the wrong use cases.

Re: Lessons learnt building a real-time audio application in Python

#30

Post by pjmlp »

CyberDildonics wrote: post #21
camtarn wrote: post #2

"It turns out that the round-trip time from an audio interface, through a computer (DAW) and back to the speakers takes a few hundreds of milliseconds, making direct audio processing impossible using consumer hardware." - uh, what? Real-time audio processing has been a thing for at least a couple of decades. It doesn't work by default on Windows, but you can get free drivers (ASIO4All) which make it work on pretty mu…

When you see someone using python for something as real time and latency sensitive as audio don't you expect more wacky red flags on top of the fact that python is going to 50x to 100x slower than a native program? Crazy numbers on top of a dictionary of arrays? It's all there.

It is really a hammer for a screw.
Post reply on HN