The Nightly CircleCI build starting failing a while back with:

Compiling serde_json v1.0.34
error[E0599]: no function or associated item named `to_u128` found for type `num_traits::ToPrimitive` in the current scope
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/extprim-1.6.0/src/traits.rs:250:9

The Rust compilers in use are fairly old now (nightly is 1.25). serde_json requires 1.26 for [ui]128 support. cubeb-rs builds locally with current nightly, so probably the simplest fix is to update the CircleCI build image with newer Rust compilers.

@djg Where does the mozmedia/cubeb-rust:fc27 image live and how do we go about updating it?

Can you get an arbitrary channel count in the data callback?
As far as I see you can only get a mono or stereo stream.

Logging from the real-time thread really needs to be done using async logging.

At the moment, doing any logging that is ever so slightly non-trivial (and I'm talking formatting four floats in a string here) will glitch, on my Macbook Pro 2018 running with 128-frames buffer duplex stream.

I tried running cargo build --examples and running the resulting examples. It didn't work well.

C:\Users\username\src\cubeb-rs\cubeb-sys\libcubeb\src\cubeb_wasapi.cpp:1500 - fatal error: hr != CO_E_NOTINITIALIZED

(I do not get a Rust backtrace.)

wasapi_init() has the comment:

  /* We don't use the device yet, but need to make sure we can initialize one
     so that this backend is not incorrectly enabled on platforms that don't
     support WASAPI. */

Which makes no sense considering that https://github.com/kinetiknz/cubeb/blob/8c3e32bd24933f82220b66c88c845c4b2bdf28e7/src/cubeb_wasapi.cpp is a huge file, and not an empty stub. Is this Cubeb comment outdated, and should I file a Cubeb issue?

Changing wasapi_init() to return CUBEB_ERROR; causes cubeb-rs examples to build, and devices.exe to report nothing but WinMM, instead of crashing in a C++ assertion.

https://docs.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coinitializeex it appears that CoInitialize[Ex] was not called in the "current" thread, and https://github.com/kinetiknz/cubeb/issues/534 is an upstream issue discussing the COM initialization. Currently it must be done by the app, not by cubeb itself. Dolphin emulator calls CoInitialize(nullptr) for raw WASAPI., but doesn't do it for Cubeb without running into this issue (maybe they use older Cubeb).

rustc 1.37.0
stable-x86_64-pc-windows-msvc
Windows 10 x64, Realtek sound card with Microsoft (not Dell/Realtek) drivers, which expose speakers and headphones as separate devices.

What's involved with publishing to crates.io once the workspace reorganisation is finalized? (Issue #1)

When testing calling logv! from audio IPC work, {} is not being expanded into the parameter. Investigate why.

Hi,

For both of the input and output streams, it's unclear how to get the mutated struct that the callback uses since ownership is handed over.

Would it be sensible if the stop function returned a Result<T> rather than Result<()>?

Due to the lack of a feature-complete cubeb library on crates.io, I started working on my Rust wrapper for the Cubeb library. Later it was pointed out to me that this repository exists. I doubt there would be any point in maintaining two separate wrappers for the library, so I guess I'll discontinue mine.
Anything I could help out with here?

As the title says.

cubeb-api builds and links in the cubeb C library. For gecko, which already has it's own version of cubeb, this probably undesirable.

Can the sys crate be setup to not build and link cubeb, and avoid the overhead of pulling cmake, gcc, etc?

I'm not too familiar with the cubeb library and have been trying to get the input functionality working; I'm seeing some behavior where calling .stop() blocks the calling thread until in the callback I explicitly return 0. I've uploaded a gist.

Is this meant to be the correct behaviour?

Builds are failing while building libcubeb via cubeb-sys with:

/usr/bin/ld: libcubeb.a(cubeb_log.cpp.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/usr/bin/ld: //usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command line

Basically a copy of mozilla/mp4parse-rust#140.

Compiling & running my project results in Context::init_stream returning an error with an unrecognized code 3, I have no idea what I did wrong that resulted in this behavior.
The "audio part" of main.rs ends at line 130, the rest of the code isn't being invoked.
I run the project with env RUST_BACKTRACE=full cargo run --release to list the available devices and then with env RUST_BACKTRACE=full cargo run --release -- 0 where 0 is the selected device index. This second command produces the error.

     Running `target/release/streamsplash 2`
Selected device: Monitor of Cyborg F.R.E.Q.5 Gaming Headset  Digital Stereo (IEC958)
thread 'main' panicked at 'Failed to create Cubeb stream: Error { code: 3 }', src/main.rs:122
stack backtrace:
   0:     0x5610c01f2c03 - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::hcab99e0793da62c7
                               at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:     0x5610c01efb36 - std::sys_common::backtrace::_print::hbfe5b0c7e79c0711
                               at /checkout/src/libstd/sys_common/backtrace.rs:71
   2:     0x5610c01f444a - std::panicking::default_hook::{{closure}}::h9ba2c6973907a2be
                               at /checkout/src/libstd/sys_common/backtrace.rs:60
                               at /checkout/src/libstd/panicking.rs:355
   3:     0x5610c01f404b - std::panicking::default_hook::he4d55e2dd21c3cca
                               at /checkout/src/libstd/panicking.rs:371
   4:     0x5610c01f479b - std::panicking::rust_panic_with_hook::ha138c05cd33ad44d
                               at /checkout/src/libstd/panicking.rs:549
   5:     0x5610c01f4674 - std::panicking::begin_panic::hcdbfa35c94142fa2
                               at /checkout/src/libstd/panicking.rs:511
   6:     0x5610c01f45a9 - std::panicking::begin_panic_fmt::hc09fe500d9b7be81
                               at /checkout/src/libstd/panicking.rs:495
   7:     0x5610c01d6b05 - streamsplash::main::hdbc97505bfaa57c0
   8:     0x5610c01fb1fa - __rust_maybe_catch_panic
                               at /checkout/src/libpanic_unwind/lib.rs:98
   9:     0x5610c01f4dc8 - std::rt::lang_start::ha09816a4e25587ea
                               at /checkout/src/libstd/panicking.rs:433
                               at /checkout/src/libstd/panic.rs:361
                               at /checkout/src/libstd/rt.rs:59
  10:     0x7f001e59082f - __libc_start_main
  11:     0x5610c01d5c18 - _start
  12:                0x0 - <unknown>

Any help would be much appreciated.

I got this error when compiling firefox nightly:

16:04.32 error[E0308]: mismatched types
16:04.32   --> /var/tmp/portage/www-client/firefox-107.0/work/firefox-107.0/third_party/rust/cubeb-backend/src/log.rs:71:22
16:04.32    |
16:04.32 71 |         log_callback(buf.as_cstr().as_ptr());
16:04.32    |         ------------ ^^^^^^^^^^^^^^^^^^^^^^ expected `i8`, found `u8`
16:04.32    |         |
16:04.32    |         arguments to this function are incorrect
16:04.32    |
16:04.32    = note: expected raw pointer `*const i8`
16:04.32               found raw pointer `*const u8`
16:04.33 For more information about this error, try `rustc --explain E0308`.
16:04.34 error: could not compile `cubeb-backend` due to previous error
16:04.34 Caused by:
16:04.34   process didn't exit successfully: `CARGO=/usr/lib/rust/1.63.0/bin/cargo-1.63.0 CARGO_CRATE_NAME=cubeb_backend CARGO_MANIFEST_DIR=/var/tmp/portage/www-client/firefox-107.0/work/firefox-107.0/third_party/rust/cubeb-backend CARGO_PKG_AUTHORS='Dan Glastonbury <[email protected]>' CARGO_PKG_DESCRIPTION='Bindings to libcubeb internals to facilitate implementing cubeb backends in rust.

here is the full build log: build.log.gz

I will open a seperate bugzilla issue to track any progress, and link it back.

I'm not sure how linking to another library works. For now, updating the submodule in cubeb-sys to anything with mozilla/cubeb@07c352c breaks the build. I'm disabling systest in #62, but it would be good to reenable.

systest uses ctest, which uses syntex_syntax2, which uses extprim:

    Compiling syntex_pos v0.59.1
error[E0557]: feature has been removed
  --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/extprim-1.7.1/src/lib.rs:58:81
   |
58 | #![cfg_attr(extprim_channel="unstable", feature(llvm_asm, test, specialization, const_fn))]
   |                                                                                 ^^^^^^^^ feature has been removed
   |
   = note: split into finer-grained feature gates

A fix PR is pending upstream (kennytm/extprim#21).

Hi there,

I was wondering whether it's possible to relax the constraints of the data callback closure of Stream to not be Sync.

What I'm trying to do at the moment is to prepare audio processors on the main thread before the audio stream starts, then move them into the audio stream's data callback so that they can be used to process audio input/output. With the data callback closure constrained to Sync, I was only able to use structures that are Sync themselves in the audio processors. (For example, it won't work for the resamplers from https://github.com/HEnquist/rubato).

I took a bit closer look into the mechanism of the audio stream, and I think it might be ok to relax the constraint to only require Send for the data callback - at least for the limited use cases I can think of, though I might be missing something.

Keen to hear your thoughts. Cheers.

Can you please add me as an owner of the cubeb crates on crates.io so I can published the latest (minor) changes to be picked up in Gecko? Instructions here. Thanks!

Hi folks! I was made aware of the cubeb and cubeb-rs projects by @padenot after his excellent WebAudio talk at Native Instruments last night. It's exciting to see the Mozilla cross platform audio backend peeking into Rust, I only wish I came across the project sooner.

I am currently one of the main maintainers/developers of the CPAL project, a project that seems to have very similar goals to cubeb though is far less mature and less battle-tested. I am also one of the founders of nannou, a creative coding framework for Rust. We recently received a grant to work on CPAL and improve the state of cross-platform audio in Rust. We've made a few improvements already over the past month or two, but even after the rest of the work we currently have planned we would still be a long way from the exhaustive set of features and backends that cubeb currently supports.

While I think CPAL is making decent progress, cubeb with its experienced team and Mozilla backing has piqued my interest, and I wonder if our efforts would be better combined in cubeb-rs.

This brings me to some questions:

• Is the ideal goal for cubeb-rs to eventually become a pure-Rust (down to the platform API) port and replacement to the cubeb C++ library for eventual use within gecko? Or is the intention for cubeb-rs to remain as a set of bindings to the C++ cubeb library?
• Are you interested in seeing cubeb-rs used in projects unrelated to the rest of the Mozilla ecosystem? E.g. as the audio backend for a creative coding framework like nannou? Do you have any interest in non-Mozilla devs contributing?

Thanks for your time!

There are two consumers for cubeb-related APIs:

• Users of the cubeb API
• Implementators of cubeb backends.

Extract the common FFI types and wrappers so they can be shared and reduce the proliferation of definitions.

See kinetiknz/cubeb#346

I want to set a specific frame size of the audio callback. Is that possible in cubeb? Right now I always get 512 samples.
Thanks you for your support!

cubeb-core/src/ffi.rs is generated by hand. Switch to using bindgen.

From @kinetiknz PR/7

This looks like a combination of a bindgen generated file and hand editing. I'm concerned that this will be difficult to maintain in the future, so I'd rather we simply use bindgen directly for all FFI level bindings (and let them deal with the bugs), then write cleaner Rust-y APIs on top of whatever bindgen spits out.

I noticed there is already some CI setup for testing on Linux here. I thought it might be worth opening an issue for testing on other platforms and adding some other handy tools to the CI process.

Recently CPAL switched their CI from a combination of travis, appveyor and circle-ci to use Github workflows. I'm still a little new to the way they work, but one nice benefit seems to be that each of the main platforms are supported in one place. You can find CPAL's workflow here where the following jobs are specified:

• clippy-test: runs clippy on the repo providing good-practise suggestions to contributors (though addressing each isn't a necessity for landing PRs).
• rustfmt-check: checks PRs have been formatted with the current stable rustfmt with default settings.
• cargo-publish: automatically publishes new releases of crates within the CPAL repository to crates.io when a PR is merged into master as long as 1. all CI passed successfully and 2. the version in the Cargo.toml has been updated. Something like this might ease the pain-point mentioned here and make it easier to keep the cubeb* crates up to date on crates.io.
• ubuntu-test
• asmjs-wasm32-test
• windows-test
• macos-test

I should mention that while it's convenient to have all CI in one place like this, it comes with the downfall of being a little more tied down to Github. Then again, I suppose it is not too tricky to switch to a different service in the case that the repository is moved, and this workflow could be used as a reference assisting in the process.

Would you be interested in a PR that adds a workflow with jobs similar to those above?

Currently ASIO is not on the roadmap, but many audio interfaces on windows only work with ASIO.
Is this something you consider adding for the future?