[rust-dev] Rust and real-time audio

David Henningsson david.henningsson at canonical.com
Mon Oct 13 03:45:19 PDT 2014

On 2014-10-08 07:49, David Henningsson wrote:
> Hi,
> I'm curious about the possibilities to use Rust for programming 
> real-time audio stuff. Usually one has one small task that runs in 
> high priority, and everything else is handled by a main task.
> I have a few questions related to this:
>  1) The real-time audio task should never block when not expected to, 
> so stuff like malloc() is forbidden. Is there a way I can mark a 
> section/module/crate/something of the code as "real time safe", and 
> thus get warnings or errors in case I try to do something that would 
> require heap allocation or other blocking stuff?
> The rest of the code (i e the main task) should still be able to use 
> the entire libstd.

It seems to me like one option could be to do this runtime, by switching 
the allocator (this should be possible, right?) to one that checks the 
thread context first and fails (or emits a warning) in case we're 
currently in a hard real-time safe thread/mode.

>  2) The real-time audio thread might want to receive messages as well. 
> Are channels suitable for this, or are the complications that cause 
> things to be problematic here?

So after having looked through the code, I think I can answer the two 
remaining one myself (but feel free to correct me if I'm wrong here) :

It looks like this *might* be problematic in the sense that there 
*might* be heap memory allocation involved when sending things over the 
channel. But it seems to recycle the memory by keeping a list of "unused 
list items". So it was not designed for hard real-time usage.

>  3) When using e g ALSA as your audio API, you usually block waiting 
> on a file descriptor. I was wondering if one would be able to select 
> between ALSA's fd and the channel, thus the blocking part of the 
> real-time thread would look something like:
> select! (
>     command = rx.recv() => handle_command_from_main_thread(command),
>     () = alsa.wait_for_avail() => alsa.write_more_audio_to_buffer()
> )
> ...where alsa.wait_for_avail() would somehow tell rust that it should 
> block on ALSA's file descriptor in addition to other things (such as 
> messages on the channel).
> If it matters, assume native threads (i e, not green threads).
The answer is "no, not as the runtime is currently designed". When a 
task deschedules, it seems to wait on a mutex or semaphore. It is not 
waiting for file descriptors (like the other mainloops I've seen on Linux).

If it were, it would provide a more flexible approach, including waiting 
for pipes, sockets, etc. And eventfds could replace the mutex/semaphore 
currently used for channels. It would be interesting to know if there 
was a difference in performance though.

// David

More information about the Rust-dev mailing list