Looking for maintainers

[est31]

A bit of history of cpal

@tomaka has created the cpal library a over decade ago¹, as a library to provide an abstraction layer over the different audio backends of the operating systems. In fact, @tomaka is one of the giants on whose shoulders the Rust community is standing, having created multiple projects, many of which have become key libraries for their categories, like rodio, glium, glutin, winit.

In 2018 (I think, I don't have precise records), @tomaka has added @mitchmindtree as a co-maintainer. Eventually, in 2019², it was moved into the RustAudio organization. It was due to @tomaka having less time to dedicate for his old projects as he focused on his new job.

A bit of history on me

I have been fascinated with audio since the start of my involvement in Rust. In fact, some of my first projects were an ogg and vorbis decoder (ogg and lewton). A bit after their creation, I have moved the projects to the RustAudio org.

The first PR I merged in cpal was in August 2019, 6bf00f1. Initially @mitchmindtree and me maintained cpal together, but as he stopped maintaining, I was on my own.

Of the projects mentioned above, I've also become maintainer of glium and rodio.

I have a full time job in Rust now that I really love, and it needs a lot of my time. So my situation is similar to the one @tomaka was in.

cpal maintenance now

In fact, I'd say that over the last 2-3 years, I haven't been a good steward of cpal. I've left PRs unreviewed, didn't respond to people making PRs, etc. People became frustrated, closed PRs, etc. And, of course, I'm not paid for cpal, especially not by the folks opening PRs, so they can't expect anything, but their emotions are also justified. I'd become frustrated too if nobody read my PR for months and years. I'm not happy about this, and I'm sorry!

call for maintainers

As explained, the need for a maintainer exists for a longer time already. But today, with the 0.16 release, I want make an explicit public call for maintainers of cpal. Please reach out to me via the rust-lang zulip (est31) or via this github thread.

maintaining cpal

Maintaining cpal is not easy. A lot of people rely on it so the ability to do damage is there. PRs might not contain actually good solutions to a problem. It's very low level code. If you are a single maintainer, you need to be expert for audio libraries for multiple operating systems. Ideally the burden is shared among a group where each person can specialize. In fact, part of why I am not a good maintainer is that I know surprisingly little about them.

On the other hand, positive contributions can also reach a lot of people and improve their software by improving cpal. Maybe some might even be convinced to adopt Rust for their projects.

my future in cpal

Ideally, after a transition period, I'd walk away completely from being a maintainer and hand it over. I sadly don't have the time. If folks prefer to co-maintain with me, that is a possibility as well.

thanks

I want to thank @tomaka for giving life to this amazing library, @mitchmindtree for having been a great maintainer, the contributors, issue reporters, and everyone who chose to adopt cpal for their project.

Footnotes

1. the first commit is from 2014 ↩

2. Publish version 0.11.0 #353 from Dec 2019 updated the URL in git, Wayback is still pre-redirect in January 2019 ↩

[SolarLiner]

I have a bit of a last-resort idea in case cpal does not pick up a new maintainer:

interflow

I am working on interflow, an alternative crate to cpal that takes inspiration from PortAudio and RtAudio, and aims to support duplex streams natively where possible, and also provides a fallback for running a duplex stream on top of separate input and output streams. interflow is more opinionated than cpal, as it forces the sample type (f32), but that in turns simplifies a lot of the user-facing API, makes it easier to provide the infrastructure to make the fallback possible (and possibly seamless if I design the API right). I've also made it modular over the backend, meaning that 3rd-party backends are possible (meaning you can write the backend for your bespoke embedded project, or support a specific platform, or even provide an alternative implementation for the backend, I'm thinking specifically of Web Audio which is a pain, require different strategies depending on the hosting setup, and might benefit from future innovations as well).

While interflow and cpal are completely separate (outside of some hypothetical cpal backend over interflow), the project asio-sys which is part of this repository as well. Therefore, maintaining at least this specific part of the repository is already of interest to me, as it will allow continued support and availability of ASIO in interflow.

Even though it might seem like the "death" of cpal would directly benefit interflow in becoming more popular, I would actually prefer cpal continuing to exist for the following reasons:

• As mentioned above, interflow is explicitely opinionated: I want a specific API surface to be able to empower most use-cases and keep the API simple. Ultimately, interflow will do format conversion and resampling to provide the configured sample rate transparently to users, for example.
  In contrast, cpal is less opinionated and its API is a bit lower level, which might be preferred by some people — I would argue though that cpal has a bunch of implicit opinions (callback-based API, being unable to restrict supported sample formats, and forcing the sample conversion selection at runtime) that hinder most use-cases without much benefit to the runtime performance or the flexibility.
• I wouldn't want to end up shouldering the entirety of the Rust audio stack
• Some competition is good, having choices and being able to explore different design philosophies that ultimately will raise the quality of audio libraries in Rust

I want to add that interflow is still very young, the API is not stable and we are still in the exploration phase. I wouldn't expect it to become a good solution in the next couple of months, so in any case this would take a while to become viable, and I could be a temporary maintainer of cpal in the meantime, though I do not know how much effort that would require and if this would be compatible with my available free time.

The change

Nevertheless, in case cpal goes unmaintained, a solution could be to provide a migration path from cpal to interflow given their overlap in use-cases, and progressively deprecate cpal over the time frame of your transition period, making interflow the successor to cpal.

This would be a net negative for the community for the reasons listed above, but I cannot say that I could maintain two separate and conflicting audio I/O crates, especially since interflow has the kind of API I want to expose to users, and I have opinions on the cpal API. If I am to get involved with cpal more closely, it will be to bring users over to interflow, making this less complicated and involved by only having one project to tend to.

This is why I say this is a "last resort" plan, because I would rather somebody steps up and takes over as maintainer of cpal; this would be the least disruptive outcome for the community.

Splitting asio-sys

Currently, ASIO support is written directly against ASIO bindings. This means that the asio-sys crate was develop to fit within the requirements of cpal, but IMHO makes the crate less usable in other projects (i.e., interflow as I mentioned above).

asio-sys could be separated from cpal and given a life of its own. I would love to help maintaining it myself, but given I am moving away from Windows, this would probably be harder for me to do by myself at least. In any case, it makes sense to me that this could be moved out to reduce the maintenance burden on cpal and having another group form over maintaining asio-sys (and maybe creating actual idiomatic Rust bindings as a future asio crate).

[git-staus]

Kudos to you @est31 for maintaining cpal alone for so long!

Would it make sense to put a note on this in the README? Perhaps #903 should also be mentioned in this discussion. Surprisingly it has never received any replies.

[nick42d]

Thanks for your service @est31. I heavily rely on this create, but am lacking subject matter expertise. Is there a suggestion you have for how people like me can help out?

[robinsingh1]

Hey @est31 , I would be interested in helping out with maintenance of the project , could we chat through what potential options could look like

[roderickvd]

I've done a quite a lot of low-level ALSA stuff in librespot and can help out with that.

[est31]

@roderickvd thanks, that is very impressive experience. I have sent you an invite. Hopefully you can merge PRs now, review them, etc. Do as you deem is best for the project. If you need help with publishing releases, please reach out, but in theory there should be an auto-publish job (which might not work though, idk). I'll be also around to add future maintainers.

@git-staus I have responded to the issue you linked: I am currently employed as an full time employee and don't intend to walk on the freelancer OSS maintainer path. I love OSS and will contribute to it in the future, but it is also the case that if I do software engineering all day at work, doing it in OSS projects on top of that is a bit much, so I reduced my involvement. Maybe in the future there might be folks with the right expertise who would be interested in turning this into an income stream. I can help with any coordination needed.

@nick42d @robinsingh1 thanks for the gestures! I lack the bandwidth to grow expertise in the areas required for cpal maintenance. Maybe @roderickvd can help.

[roderickvd]

@est31 thank you for the collaboration invite, which I just accepted.

Given the usage of cpal, it can and should have more maintainers still. My expertise is with ALSA, so we definitely need people to help maintain the other platforms too, but generally we need more maintainers to spread the load and ensure quality.

@nick42d if you've got Rust experience up your belt then your assistance would be greatly appreciated in triaging and reviewing issues and PRs.

@robinsingh1 I'm not very big on doing 1-on-1 chats. Feel free to chime in here with what you can and would like to do. I notice your profile does not show a lot of GitHub. Everybody's gotta start somewhere, so be clear on what you expect of it.

[roderickvd]

@est31 I seem unable to (re-) run CI jobs. Could you set me up with the appropriate rights? Thanks!
Couldn't find a way to DM you - let me know if you have a different way of getting in touch.

[nick42d]

@est31 thank you for the collaboration invite, which I just accepted.

Given the usage of cpal, it can and should have more maintainers still. My expertise is with ALSA, so we definitely need people to help maintain the other platforms too, but generally we need more maintainers to spread the load and ensure quality.

@nick42d if you've got Rust experience up your belt then your assistance would be greatly appreciated in triaging and reviewing issues and PRs.

Sounds achievable to me, I have a couple of years of Rust experience now with my public projects on here. Please feel free to add me as an optional reviewer on any PRs.

I'll caveat this by saying I'm currently studying part time, so my capacity is limited, but it's not zero and I don't see why I shouldn't still try to stay involved.

In regards to triaging, as it sounds like your preference is to keep discussion in the open here, so keep an eye out for an issue from me about a tagging strategy for the repo.

[wgibbs-rs]

Good afternoon!

While it seems the door is pretty closed here, I wanted to jump in on this conversation. I've been programming with CPAL for a few years now for a DAW project of mine. While I have plenty of projects done in Rust, I really value the safe-programming that you discussed in your post. Code security, testing, and resilience are really important to me, and I'm consistently working with those topics (Rust, C, Ada, V&V, etc).

I understand there was a recent round of maintainership offers, but I wanted to ask if there’s still an opportunity to contribute more actively, whether as a co-maintainer or a contributor to cpal. I’d love to help with code, reviews, documentation, or testing.

Just let me know if there's any way I can help contribute to this project as well.

[roderickvd]

@nick42d:

Sounds achievable to me, I have a couple of years of Rust experience now with my public projects on here. Please feel free to add me as an optional reviewer on any PRs.

Great, I'll remember to do that. In parallel, feel more than free to go through the backlog and review as you want.

I'll caveat this by saying I'm currently studying part time, so my capacity is limited, but it's not zero and I don't see why I shouldn't still try to stay involved.

It's appreciated. I've got more than a full-time job myself, as well as a family, so we do what we can, when we can and want to.

In regards to triaging, as it sounds like your preference is to keep discussion in the open here, so keep an eye out for an issue from me about a tagging strategy for the repo.

👍 So far I don't have full repository access yet, otherwise I'd enable the "Discussions" feature.

---

@wgibbs-rs:

While it seems the door is pretty closed here, I wanted to jump in on this conversation.

Not closed at all, as far as I am concerned. If anything we need more people to sustain and enhance this popular crate.

I understand there was a recent round of maintainership offers, but I wanted to ask if there’s still an opportunity to contribute more actively, whether as a co-maintainer or a contributor to cpal. I’d love to help with code, reviews, documentation, or testing.

As above I don't have full repository access to hand out any rights, but yes all help is great. My proposal would be to first go through the backlog of PRs & issues to do some grooming. Resuscitate good PRs that are in there, do cross-platform testing, dust it all off and we go from there.

[wgibbs-rs]

@roderickvd

Sounds great. I'm happy to contribute to this project. I'll start looking through some PR requests, and add what I can there, especially in terms of keeping cpal safe or updated.

Thanks for letting me know!

[gulbrand]

I might be able to help maintain the CoreAudio / Mac side of this. I have quite a bit of interest in cpal for my personal projects and I also try to live by a philosophy geared toward helping others.

[KushalLukhi]

Hi maintainers — I'm Kushal (@KushalLukhi). I'd like to volunteer as a maintainer/contributor for this project.

I can help with:

• issue triage and reproduction
• reviewing/fixing open bugs
• dependency/security updates
• release/support chores

Happy to start with PR-based contributions and earn trust progressively. If you're open, please share the preferred onboarding path and first tasks.

[roderickvd]

Thanks for your offers @gulbrand and @KushalLukhi. Indeed, it'd be great if you could go through the issues and PRs to review them and propose appropriate action. Let's take it from there!

[git-staus]

Sorry for being nosy @KushalLukhi, but would you mind providing some kind of indication whether you are an LLM-driven bot or not?

[chrissnell]

Sorry for being nosy @KushalLukhi, but would you mind providing some kind of indication whether you are an LLM-driven bot or not?

Sure looks like it

[1rhino2]

interested in helping maintain cpal.

background: systems / low-level C and Linux (networking, sockets, etc). rust is secondary for me but i write and review it. i can test on linux + windows.

honest about audio: not an ALSA expert. happy to start with triage, PR review, repros, and cross-platform smoke tests, then take a platform slice once i've earned it.

saw you still want more maintainers beyond ALSA. if useful, point me at 1-2 PRs or issues that need eyes first and i'll start there.

[roderickvd]

Hi @1rhino2 be welcome. Just take a the current issue and PR list and go from there! Specific ones that would be great to contribute to are #1287 and #1220.

[1rhino2]

@roderickvd thanks. starting with #1287 (and the related #1297) then looking at #1220. will report back with review notes / any windows smoke i can run.

[1rhino2]

@roderickvd update from the #1287 / #1220 pointers:

• fix(asio): share duplex buffer state across Device handles for the same driver #1297: static review up
• feat(WASAPI): allow setting raw stream mode #1195: windows review up (check green; noted StreamConfig vs extension-trait design question from v0.19 design goals #1220)
• HostId enum Refactor #1274: light review up
• v0.19 design goals #1220: left a short status note

still no ASIO interface on this box, so live duplex A/B for #1287 is blocked for me until i set up ASIO4ALL/SDK or borrow hardware. WASAPI PreferRaw runtime smoke also blocked here by a missing gnu linker (dlltool), check-only for now.

[LastExceed]

I'm interested in becoming a maintainer. My expertise is with Windows audio APIs, most notably ASIO. I initially came here for #1299, but have since gotten hooked on the project, and want to stay around. While cleaning up the issue backlog, I keep wishing I had the ability to assign tags, because delegating this by leaving comments everywhere (as I currently do for closing issues), or by creating lists of URLs (as I did for moving stuff to Q&A) is just not feasible.

At my day job I'm somewhat of a specialist for code cleanup and refactorings. Somehow the tasks that most would consider tedious tend to be really zen to me. In my free time I have a special interest in IO latency, which is what first got me into low level audio programming (specifically this deep-dive).