Repository navigation
Release with cpal 0.18, needed for visionOS #898
Description
0.22.2 still requires cpal 0.17, which requires mach2 0.5, and mach2 0.5 refuses to build for
aarch64-apple-visionos:
error: mach requires macOS or iOS
master already moved to cpal 0.18 in #891, and cpal 0.18 requires mach2 0.6, which builds for every
Apple vendor. So nothing is needed in this repository beyond a release.
With master, plus RustAudio/cpal#1262 which declares the AVAudioSession dependencies on visionOS, I
get sound on the visionOS 26.2 simulator: DeviceSinkBuilder::open_default_sink opens the default
device and a SineWave plays, built for aarch64-apple-visionos-sim and run through
xcrun simctl spawn.
Is a release planned? Happy to help if anything is blocking it.
Activity
yara-blue commentedon Jul 10, 2026
For now I'd recommend using master, if you pin it to a specific revision (commit) you should not have any problems (if you do please report them!).
There is still quiet a lot that needs to land and I haven't had the time to get to it. Should be able to get started on that finally this weekend. Then a release depends on review capacity within Rodio. Might be a month might be a few months.
SkeletonGamer commentedon Jul 10, 2026
Thanks, pinning master works. I only needed
cpal 0.18foraarch64-apple-visionos, and audio isoptional in my project, so there is no rush on my side.
One thing while you are looking: CI is currently red on master. Rust 1.97 extends
clippy::question_mark, and clippy runs from stable with-D warnings, so every PR you open thisweekend shows an unrelated failing check. #899 fixes it, one line in
src/source/from_iter.rs.RustAudio/cpal was hit by the same lint, in RustAudio/cpal#1263.
yara-blue commentedon Jul 10, 2026
Thank you :)
xronocode commentedon Sep 21, 2026
Another consumer waiting on the cpal 0.18 line here: we play audio through DeviceSinkBuilder and record via cpal directly in the same app, so released 0.22.2 pins the whole app to cpal 0.17.
One data point for the release call: I bumped our app to cpal 0.18.2 with master pinned at 685e057, and it compiles apart from the mechanical 0.18 migrations (name() is Display now, unified error type, StreamConfig by value). The DeviceSinkBuilder surface we use is unchanged, so what has landed of the rewrite is not visible from the consumer side.
Happy to help move the release along: changelog drafting from the commit history, review or fixes on the open community PRs (#913, #914, #915, #920), or whatever else on the pre-release list can be delegated. What is left that has to land first?
SArpnt commentedon Oct 4, 2026
the new version of cpal fixes a major bug that can cause audio to permanently drop out at any time; i think a patch version should be released.
dbalsom/martypc#245
RustAudio/cpal#730
xronocode commentedon Oct 5, 2026
That dropout issue (RustAudio/cpal#730) is exactly the kind of thing the 0.18 bump would fix for downstream users. The offer from my earlier comment stands: the migration is still mechanical on my end (nine fixes, verified against cpal 0.18.2), happy to send the PR whenever useful.
yara-blue commentedon Oct 6, 2026
Sorry everyone has been a hectic time. We're in the middle of a re-architect/rewrite that is taking longer then planned (will turn out better then what we had planned in spring though!).
I do not have the time to spin up a separate Rodio branch from the previous release and bring it up to cpal 18.2. But I would not mind reviewing one and pushing out a release.
It need to be branched from the previous Rodio release since a lot of the new stuff in right now is not ready for publishing as we will probably change/overhaul it again.
PR for this welcome please keep the LLM policy in mind: https://rust.audio/community/ai/
xronocode commentedon Oct 7, 2026
Happy to pick this up.
I came to this while moving Handy (cjpais/Handy) onto released crates. Handy enumerates devices with its own cpal and hands the chosen one to
DeviceSinkBuilder::from_device, so the app's cpal and rodio's cpal have to be the same version, and while rodio is on 0.17 the app can't move to 0.18. I've worked on Handy's audio code before: the cpal 0.16 to 0.17 bump (cjpais/Handy#1644) and moving blocking cpal calls off the main thread (cjpais/Handy#1716).I have a branch off v0.22.2 with cpal 0.18.2 that builds and passes tests locally. The port is mostly mechanical: the unified
cpal::Errorreplaces the old per-operation error types in our public signatures, andbuild_*_streamtakes the config by value. One behaviour change: 0.18.2 reports xruns on more backends, soMicrophoneno longer ends on an xrun or other errors that leave the stream running. It also covers the original visionOS case:cargo check --target aarch64-apple-visionosfails on v0.22.2 (mach2 0.5) and passes on the branch. The full CI command set passes on Rust 1.87.Two practical questions before the PR:
release/0.22.x) for me to target? Or is it easier if I send the branch from my fork and you pull it? Either works for me.On the AI policy: I write in Russian and this comment was translated to English with AI. For the port itself AI helped with the mechanical parts, and I checked every change myself. If that's a problem, tell me.
yara-blue commentedon Oct 7, 2026
0.23.0just make sure there is a change-log entry so it is clear what happened.I do not mind the use for translation, LLMs are perfect for that.
If mechanical means that you decided what you wanted to change and then AI made the change I think it's fine. As long as your instructions where specific enough. Though you really should not write anything yourself for this. Just copy what you need from master. The master branch is on
Cpal 0.18so all the code to support it is already written, reviewed and merged.Good luck!
xronocode commentedon Oct 8, 2026
Thanks for the branch! The PR is up: #930.
chore: update cpal to 0.18.2
docs: changelog and upgrade notes for cpal 0.18
chore: update cpal to 0.18.2
docs: changelog and upgrade notes for cpal 0.18