Re: [rust-dev] Rust and real-time audio
For your first question, you could enable the "owned-heap-memory" warning as an error for the crate in which you want to avoid heap memory. If this doesn't do exactly what you want, you may be able to write your own lint to do what you want http://doc.rust-lang.org/rustc/lint/ On Wed, Oct 8, 2014 at 1:49 AM, 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. > > 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? > > 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). > > // David > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust Radio - an SDR framework
Looks like there's a lot of good stuff in there. I especially like the rtlsdr bindings: I'll be able to get live data sooner than I thought! On Sep 11, 2014 1:28 PM, "Ian Daniher" wrote: > Very cool. I did some work on discrete time DSP with SDR applications. The > library's at https://github.com/ade-ma/LibRedio. > > Best, > Ian > > On Thu, Sep 11, 2014 at 8:56 AM, Allen Welkie > wrote: > >> If anyone is interested in software defined radios, I'm starting a >> project called Rust Radio (very similar to GNU Radio). Take a look at >> https://github.com/awelkie/rustradio. It's still pretty new, but >> critiques and contributions are always welcome! >> >> ___ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust Radio - an SDR framework
Yeah, I set up the block to work on iterators over objects instead of references because it made a lot of things simpler. But you're right that it causes a lot of unnecessary copying. I think its time to revisit that decision. I'll play around with using iterators over references instead of objects. Thanks! On Sep 11, 2014 11:46 AM, "Peter Marheine" wrote: > Your design bears significant similarity to my own work on an audio > streaming framework [1], which seems a bit more mature despite still > being the subject of significant experimentation on my part. > > It looks like your elements do a lot of copying, which could have a > significant negative effect on performance. I approached the same > problem by having elements (Source in audiostream) return references > to mutable buffers (which may not be possible with Iterator). This > should allow elimination of most copies in real-world applications, > though at the moment my design calls for independent tasks for each > linear pipeline segment while will require a copy for each task. > > I also found your Interleave block interesting, since I've been > working on squeezing performance out of my own Interleave block (I > expect most pipelines with have at least one of both Interleave and > DeInterleave, so vector optimizations are a good goal to reach for). > I'm pleased with the performance so far (10.5 GB/s on the ~3 GHz Core > i5 machine I'm testing on), but it might be useful to break that into > its own library so others can benefit from the vector optimizations. > > Your connect! macro is nice; I've been planning to do something > similar (possibly define a whole DSL for pipeline specification which > can be used as a macro), but you beat me to it in this case. :) > > Anyway, it looks like there are things we can learn from each other > here, and I'll be watching your project- might be a good excuse to get > some use out of my HackRF and contribute some components back. > > [1] https://bitbucket.org/tari/audiostream.rs/ > > On Thu, Sep 11, 2014 at 6:56 AM, Allen Welkie > wrote: > > If anyone is interested in software defined radios, I'm starting a > project > > called Rust Radio (very similar to GNU Radio). Take a look at > > https://github.com/awelkie/rustradio. It's still pretty new, but > critiques > > and contributions are always welcome! > > > > ___ > > Rust-dev mailing list > > Rust-dev@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > -- > Peter Marheine > Don't Panic > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Rust Radio - an SDR framework
If anyone is interested in software defined radios, I'm starting a project called Rust Radio (very similar to GNU Radio). Take a look at https://github.com/awelkie/rustradio. It's still pretty new, but critiques and contributions are always welcome! ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Closures with owned environments
Oh, cool. Instead of returning the closure from a function, I'd rather use
it in a call to map(), then return that Map struct. Something like:
fn map_add>(it: I, x: int) -> Map<...> {
it.map(|&: y: int| x + y)
}
So does this mean I just need to wait until the map() function accepts
unboxed closures?
On Tue, Sep 9, 2014 at 5:00 PM, Vladimir Matveev
wrote:
> Hi, Allen!
>
> In fact, it is possible to do it now without DST, using unboxed closures
> only:
>
> #![feature(unboxed_closures, unboxed_closure_sugar)]
>
> fn make_adder(x: int) -> Box<|&: int| -> int> {
> box |&: y: int| x + y
> }
>
> fn main() {
> let f = make_adder(3);
> println!("{}", f.call((4i,)));
> }
>
> Test it here: http://is.gd/mCJ6Dh
>
> This code employs the idea that unboxed closure is just an instance of
> some anonymous struct implementing one of Fn* traits, so we can just
> return a boxed trait object representing the closure. The call syntax
> is ugly, however, but this should change in the nearest future (though
> explicit dereferencing, like (*f)(x), will likely be needed anyway).
>
> 2014-09-10 0:39 GMT+04:00 Allen Welkie :
> > In this stackoverflow question:
> >
> >
> http://stackoverflow.com/questions/21130272/return-a-closure-from-a-function
> >
> > Chris Morgan mentions the possibility of adding closures with owned
> > environments with the DST implementation. Is this being done with the
> > current DST effort? If not, are there plans to add it?
> >
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Closures with owned environments
In this stackoverflow question: http://stackoverflow.com/questions/21130272/return-a-closure-from-a-function Chris Morgan mentions the possibility of adding closures with owned environments with the DST implementation. Is this being done with the current DST effort? If not, are there plans to add it? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Using 'mod' for test code
I'm having an issue with creating a separate testing file for a program I'm writing. I have a file called 'myprogram.rs', which imports complex numbers with the following extern crate num; use num::complex::Complex; and then defines a bunch of functions. I want to test these functions in a separate file. So I created 'testprogram.rs' and import the myprogram functions using the 'mod' keyword: mod myprogram; But when I try to compile test.rs with the --test flag, I get the following error for myprogram.rs: "unresolved import 'num::complex::Complex'. Did you mean 'self::num::complex'? What's going on here? How can I import my program to create a test suite. Also, is this the preferred way of creating a test suite (using the 'mod' keyword)? Or should I compile 'myprogram.rs' into a crate and import the crate into 'test.rs'? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Conflicting implementations of a trait
Can there be two simultaneous implementations of a generic trait? I ask because I want to extend the Complex class to allow for multiplication by scalars, so that you can use "a * b" where "a" and "b" can be either scalars or Complex. The Complex struct already has an implementation of the Mul trait. I wanted to add another, so I added the implementation of Mul> for Complex, and used the scale() function. But I get a compiler error saying that there are conflicting implementations for trait 'core::ops::Mul'. Is it possible to simultaneously overload the Complex (*) operator scalars and complex numbers? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
