
Rust for real time audio analysis - blacksmythe
http://www.tzaeru.com/squeezing-rust-into-production-part-2/
======
dljsjr
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](https://github.com/rust-
lang/rfcs/issues/819)

~~~
rapsey
This crate provides the functionality:
[https://github.com/Elzair/core_affinity_rs](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?

~~~
dljsjr
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.

~~~
pornel
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.

~~~
dljsjr
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.

~~~
steveklabnik
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!)

~~~
dljsjr
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.

~~~
steveklabnik
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 :)

------
jsd1982
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.

~~~
tetromino_
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.

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

~~~
dharma1
what type of audio analysis? There's this -
[http://essentia.upf.edu/documentation/](http://essentia.upf.edu/documentation/)

~~~
nkg
I am thinking about spectrum comparison, like shazam does

~~~
dharma1
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](https://github.com/worldveil/dejavu)

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

~~~
alexnewman
mediocreguy why go and not python or tcl?

~~~
alexnewman
"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

