[question] Go and jackd

[avlapp]

How mature is this library? There is not too much activity lately right?

A bit offtopic, but how well suited is Go for developing proaudio applications (with jackd)?

Does the language being used influence the latency for instance, or is that the concern of jackd?

[xthexder]

I wrote this in 2015 as a way to experiment with audio processing in Go, and haven't really touched it since, except for merging a few external PRs.

I was able to get processing delays and latency comparable with something written natively in C,. I was using it in https://github.com/xthexder/rawstreamer, which was fairly stable at the time, but Go has since changed some things with how the garbage collector and native C interact.

I think the latest master is still working thanks to others' contributions, but I haven't been using it myself to verify any stability.

[avlapp]

Thanks for your comment. Maybe you could keep this question open, so others might chime in. Label it as question for instance.

[xthexder]

¯\_(ツ)_/¯

[avlapp]

While others told me on IRC that Go wasn't well suited, some interesting insights where shared recently by siXy in #go-nuts:

For audio go's GC is good enough, if you write your code correctly. Audio is essentially always slightly buffered, and a go GC pause these days is below 100 microseconds, which is more than good enough for the soft-realtime needs of pro audio.

People get a little bit over excited by the idea of realtime being mandatory for audio - that was true back in the 90s, but with modern computers much less so. Occasional small sub 1ms pauses are acceptable, when handled correctly. There are applications with a very hard realtime requirement where a 100us pause won't work - but this isn't that.

(About VCRack use of threads) What that is really saying is something along the lines of "Previously we had this system where the main audio thread was sometimes blocked waiting for a long time, while an other background thread produced data for it". That was never a good architecture to begin with - the talk about threads is something of a red herring there, it's the "synchronization" bit that's bad. In go terms, this would be: Ensure that your main audio processing goroutine is never blocked waiting for data from some other goroutine. And yeah, that's something you need to do. But they are using a bunch of technical-sounding cruft to make this sound more impressive of a feat than it really is.

There is also this https://github.com/andrepxx/go-dsp-guitar/blob/master/doc/performance.md from @andrepxx

edit: this seems to be a important writing on the Internet about Real-time audio programming, which contains probably some outdated info if we've to believe the comments above: http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing