andrepxx
commented
2 years ago It actually works fairly well - certainly well enough for spare-time projects. I even use it in a relatively "large" open-source audio application, that you can find on my GitHub, which has so far been cloned around 50k times.
The problem is: Go is not really made for real-time processing, so there are no guarantees. Your results may vary depending on the audio interface you use, your kernel version, the version of Go compiler that you use, which may make different optimizations or have differences in the Go runtime affecting garbage collection performance, Goroutine scheduling, etc.
So would I use it for a commercial audio application: Hell no! Unless you work in a completely controlled environment (e. g. an appliance where you flash a completely "frozen" firmware image) and are okay with "freezing" the version of the Go compiler, kernel image, etc., you basically have no guarantees. It will likely work well enough ... usually. The problem is, there may be a breaking change in an upcoming compiler version and you will run into problems - unless you're able to stick to the version that "worked".
It also depends on what you compare this to. For example, this will work way better than, say, most Python bindings for audio. If Go isn't good enough for your audio purpose, there's really not much left other than going with C or (a very restricted subset of) C++ or - if you're really experimental - perhaps Rust, which was constructed around the ideas of guarantees / predictability.
Have you tried using this for realtime processing? Before I try it out, I'm wondering if it's possible to get glitch free audio.