• Audio

  • Realtime audio drivers in Rust

giuliomoro that's it by the looks of things!

Yes, but indirectly it is due to a limitation of the dasp (formerly sample crate) which appears to only support fixed-size (at compile time) frames (if I'm reading the documentation correctly).

    Urghh... You could run board_detect which returns the board name and infer the channel count from that at compile time ... Hackish ...

      giuliomoro That wouldn't work for cross-compilation. dasp is a separate crate anyway, so that can be ignored for now

        l0calh05t Okay, but that substitution implies different semantics, right?

        that's correct, but as far as I knew no one was actually setting it to anything else than default, so this was sort of a compromise: keep ABI compatibility for everything else while changing the meaning for this (to my knowledge) unused flag. Yeah, pretty poor, but ultimately AFAIK the only thing that relied on dynamically linking to Bela is Supercollider, which I also maintain and which didn't set that specific flag.

        l0calh05t Supporting audioThreadDone would be the most complex of the additions.

        that's an optional function callback, you are unlikely to need it for anything. It was required for Supercollider, as it didn't have a way of being notified and gracefully shutdown if the audio thread ended because the button was pressed.

        l0calh05t s there any way to check which ones are valid?

        you mean which values are valid for stopButtonPin? Any value is "valid". -1 or any number >= 128 are considered "off", values between 0 and 127 are considered "on" and the value is the pin number that will get monitored.

        l0calh05t /// How many audio input channels [ignored]
        int numAudioInChannels;
        /// How many audio out channels [ignored]
        int numAudioOutChannels;
        seem to be obsolete?

        You seem right. I may have left them there in case i actually wanted to use them ... it could be helpful to specify manually how many of the available I/O one wants to actually use ... currently you can do it only in a limited way by setting e.g: --board=Bela (or .board = BelaHw_CtagFace) to only use 4in/8out when a CTAG Beast is also connected... But as usual there are other higher-priority things going on :-(

                  giuliomoro the only thing that relied on dynamically linking to Bela is Supercollider, which I also maintain and which didn't set that specific flag.

                  Rust links shared libraries by default AFAIK, but it should be possible to change this. The allocation functions for the settings struct aren't used yet though, but doing that shouldn't be to complicated either.

                  giuliomoro you mean which values are valid for stopButtonPin? Any value is "valid". -1 or any number >= 128 are considered "off", values between 0 and 127 are considered "on" and the value is the pin number that will get monitored.

                  Ok, but can any value in [0, 128) actually be used? What if something else is assigned to the pin as well?

                  giuliomoro currently you can do it only in a limited way by setting e.g: --board=Bela (or .board = BelaHw_CtagFace) to only use 4in/8out when a CTAG Beast is also connected... But as usual there are other higher-priority things going on

                  What happens if you set a board that isn't present / available (i.e., Bela when only a Beast/Face is used or BelaMini on a Bela)?

                          l0calh05t What happens if you set a board that isn't present / available (i.e., Bela when only a Beast/Face is used or BelaMini on a Bela)?

                          it will fail and not start. See https://github.com/BelaPlatform/Bela/blob/master/core/RTAudio.cpp#L452-L479

                          l0calh05t Ok, but can any value in [0, 128) actually be used? What if something else is assigned to the pin as well?

                          It will let you do that ... if you end up picking one of the pins that the Bela Digital channels are on and you set it to an output, this will affect the readings, but if it's used as an input, it will work. There are no checks to avoid any such clashes, we just make sure it doesn't crash. It's up to the user to select a pin that makes sense. Again, most likely this is just for those who want to spin their own board or something like that, not really for day-to-day usage ...

                                Just a quick update: bela-sys now uses a BELA_SYSROOT environment variable instead of having to place subsets of files into a Cargo-internal folder. So just extract partition 1 (/) of the Bela image to a folder of your choice and point BELA_SYSROOT at it (in theory it should also build on the Bela itself, assuming cargo and rustc work on it). This should work much better when crates depend on bela-sys. Furthermore, static vs dynamic linking of bela is now switchable via a crate feature static and the hello-example is now a proper example (meaning its dependencies are now dev-dependencies!) and not the main.rs of a "hybrid" executable/library crate.

                                If you want to try out my branches of bela-sys or bela-rs, add

                                [patch.'https://github.com/andrewcsmith/bela-sys.git'.bela-sys]
git = "https://github.com/l0calh05t/bela-sys.git"
branch = "bela0.3.8b_rust1.52.0"

[patch.'https://github.com/andrewcsmith/bela-rs.git'.bela-rs]
git = "https://github.com/l0calh05t/bela-rs.git"
branch = "bela0.3.8b_rust1.52.0"

                                to your Cargo.toml and add the original version to your dependencies. (I didn't change any of the URLs in case @andrewcsmith is interested in merging these patches)

                                Would you mind doing a PR for this so we can get it merged upstream? I'm not sure Andrew is looking at this forum.

                                I'm on other parts of my project (doing all the analog bits), so I didn't update the board and didn't recompile anything for quite some time now, so this went unnoticed.

                                fwiw, cargo and rustc work well on bela, but it's horribly slow. I was doing it on the device initially, but since it's so easy to cross-compile with rust, I ended up compiling on my laptops and sending the binary.

                                We can also figure out the dasp situation, surely there is a way to sort it out.

                                  padenot Would you mind doing a PR for this so we can get it merged upstream? I'm not sure Andrew is looking at this forum.

                                  Done 🙂

                                  padenot fwiw, cargo and rustc work well on bela, but it's horribly slow. I was doing it on the device initially, but since it's so easy to cross-compile with rust, I ended up compiling on my laptops and sending the binary.

                                  Yeah, I suspected as much and decided against trying it

                                  padenot We can also figure out the dasp situation, surely there is a way to sort it out.

                                  With the new min_const_generics feature, it should be possible to have a generic implementation where the proper compile-time channel counts is selected at run-time from a fixed set of known channel counts. Without such workarounds AFAICT not without changing dasp itself to support run-time variable channel counts.

                                        16 days later
                                        a month later
                                        15 days later

                                        l0calh05t Oh cool! This is great. I really look forward to your next post and reading about getting bela-sys and bela-rs working and happy.

                                        I'd be happy to help make a tutorial for Mac and Unix users as well.

                                            5 days later