Rust for real time audio analysis | Hacker News Reader

Rust for real time audio analysis

tzaeru.com

72 pointsblacksmythe19 comments

How do you handle real-time thread priorities and CPU affinity? I work in soft real-time software as well (feedback control for humanoid robots) and I've been wanting to play around with Rust for real-time programming for a while. Given that your workload is parallel I would imagine CPU pinning is pretty important for making your deadlines. Since my current job involves maintaining a bunch of natively bridged code to add real-time scheduling to a non-realtime environment (Java) I don't wanna muck around with it until the language itself adds the stuff needed to the native API.

I've been watching this RFC[1] for years waiting for some notion of progress of support for this in the language itself. Doesn't seem to be a lot of focus on it right now.

[1]: https://github.com/rust-lang/rfcs/issues/819

This crate provides the functionality: https://github.com/Elzair/core_affinity_rs

It takes a couple of seconds to add this crate to your project. I don't see what the problem is?

Well for one, that crate's first commit is from September from this year so it's quite new and I didn't know about it.

That's the sort of information I was looking for with my question.

Secondly, though, while it handles affinity it still doesn't handle priority.

If you know how to do that in C, you can call the same functions from Rust (you'll find them in libc crate or you'll need `bindgen` to convert a C header to Rust).

The Rust ecosystem is still young, but on the upside maintainers are active and keen to expand their crates, so there's a high chance they'll add the feature you need if you just ask.

From my understanding (and also mentioned by someone in the comments on the RFC I linked), while you can do things to the threads by just directly calling through to C, what you end up with is a thread that doesn't have all of the Rust runtime niceties set up on it correctly.

I'm just waiting for a full featured version of this functionality to be available in the language, but I was also sort of curious to see what OP's solution to the problem was.

And like I mentioned originally, my day job is to maintain code that does the same thing but for Java. I don't wanna have to maintain it in two languages even if one is just a pet project. Since Rust is billing itself as a systems language it makes sense that this will be a feature eventually, and I'm willing to wait patiently. It's not holding me back from anything, it's just a personal curiosity.

Rust doesn’t really have much of a runtime; I’m not sure what niceties you’re thinkjg of :)

(I also logged that you talked about this in the issue; even knowing people want this is useful; it’s probably not in std because nobody’s ever really argued they need it!)

Thanks for taking the time to look at this Steve!

I'm not super familiar with threading in Rust, I was just going off comments made in the RFC and what little research I had done at the time I started looking in to it. This was all a few years ago and I know the runtime used to be much heavier so my info could very well be out of date.

I know that this is a feature that doesn't impact a large number of people, but for the people that do need it it's pretty important. Being able to do soft real-time threading inside of an RTOS environment like Xenomai or Linux w/ the preemptive kernel (RT) patch in combination with Rust's other safety-oriented features would be a huge boon for embedded developers I think.

Ah ha! So, looking at the issue, at that time, Rust did have a runtime, and green threads. Today, we don't, and just have OS threads. So that's where the miscommunication lies :)

> while you can do things to the threads by just directly calling through to C, what you end up with is a thread that doesn't have all of the Rust runtime niceties set up on it correctly.

That is incorrect. Rust threads are system threads and nothing more.

> I'm just waiting for a full featured version of this functionality to be available in the language, but I was also sort of curious to see what OP's solution to the problem was.

You will be waiting for a long time. No one is in a rush for that RFC because the functionality exists in crates and through a ffi call if you need it. Rust does not have a large standard library and will never have one as large as Java/C#. This is why the crate system exists.

>> while you can do things to the threads by just directly calling through to C, what you end up with is a thread that doesn't have all of the Rust runtime niceties set up on it correctly.

> That is incorrect. Rust threads are system threads and nothing more.

It seems that wasn't the case years ago when I originally researched this and when the RFC I linked was filed.

> You will be waiting for a long time. No one is in a rush for that RFC because the functionality exists in crates and through a ffi call if you need it. Rust does not have a large standard library and will never have one as large as Java/C#. This is why the crate system exists.

That's fine, I'm not asking for a large standard library nor am I being held back by the absence of these features. I haven't spent a lot of time with Rust but it's on my radar so I was just asking a few questions to try and gather some info. Do note, though, that if a language wants to bill itself as a systems language that these are important features to have available and well-vetted for low-level embedded software development.

Strange that you dismiss Java due to its JVM dependency, yet pause at C# disregarding its CLR dependency. C# does not strictly require you to write your code with OOP principles in mind. Yes there are classes, properties, inheritance, etc. but you can treat those as purely organizational and write in a more functional style.

Regardless, Rust seems like a solid choice here, but I wouldn't discount Go (golang). It's incredibly simple to write and read code in and its runtime is incredibly rock solid. I have web services written in Go that have literally never crashed of their own accord.

The author mentions needing to package python for distributing the product, which suggests that the product is intended for Windows. Which means that clr (unlike python and jvm) is probably preinstalled on most of his customers' machines.

Is there a state-of-the-art library for audio analysis ? (genuinely asking)

what type of audio analysis? There's this - http://essentia.upf.edu/documentation/

I am thinking about spectrum comparison, like shazam does

Essentia does audio fingerprinting with Chromaprint, which is essentially that.

There are also other open source projects using Chromaprint focused specifically on that - https://github.com/worldveil/dejavu

Just curious, why was GO not looked at as an option?

mediocreguy why go and not python or tcl?

"The main problem with the Python version of this product - or subproduct - was that it was pretty unstable, hard to extend and hard to debug" -> I assume go would be worse. This is where rust's hefty language comes in handy

Reply on news.ycombinator.com