Use alsa-rs for alsa support rather than alsa-sys

[derekdreery]

I'm opening this as a draft, both because it's quite large, and because it depends on some additions I've made to alsa-rs. I really like it though in principal. It removes almost all unsafe code (certainly the bits that are hard to reason about), and IMO makes the alsa backend much easier to reason about.

EDIT oh, and there are bugs in it at the moment that prevent it from making any noise. Specifically I get

beep: pcm_jack.c:181: snd_pcm_jack_poll_revents: Assertion `pfds && nfds == 1 && revents' failed.

[ishitatsuyuki]

Sorry but the formatting changes have made it overwhelmingly hard to reason about the diff. I appreciate if you avoid them for this PR: we have a plan to run rustfmt after the large refactoring PRs.

[derekdreery]

At this point I wouldn't review the code of the diff, I've opened the PR more to get feedback on the idea. I think having another layer of abstraction (that is zero-cost) makes implementing the cpal interface much easier, and would allow more fearless experimentation without worrying about misuse of the alsa api or UB. The onion layers model is being use for example in gloo which, although for a different domain, shows the principal in action.

[ishitatsuyuki]

Yes, I think using Rust bindings is a good idea, and it seems it's better than using raw FFI bindings that haven't been updated for 2 years anyway.

I haven't looked at the code but at the moment we have some low-level dealing with the poll descriptors - wonder if that would be correctly abstracted in alsa-rs.

[derekdreery]

I haven't looked at the code but at the moment we have some low-level dealing with the poll descriptors - wonder if that would be correctly abstracted in alsa-rs.

I agree and think we should be careful when evaluating projects like alsa-rs or nix, to make sure they are good abstractions. And then if we audited the crates to make sure they do what we want we can pin our dependency to the exact version, so that we know the code won't change from under us (or we could vendor it).

Both these projects are very handy when working with unix c libraries though, as you no longer have to hold the ffi cognitive load in your head while working on using the libraries.

[ishitatsuyuki]

Do you still plan to work on this? So far it doesn't seem alsa-rs is good enough nor provide any improvements to code quality.

You're welcomed to add RAII wrappers or other unsafe-to-safe facilities inside cpal as well.

[diwic]

Hi! I'm the maintainer of the alsa crate. I just wanted to say that if there's anything in the alsa crate that keeps you from moving over CPAL from alsa-sys to alsa, I'm all ears and likely willing to improve the alsa crate to fit your needs. Please open an issue if that's the case.

we have some low-level dealing with the poll descriptors - wonder if that would be correctly abstracted in alsa-rs.

There is indeed a poll descriptor abstraction in the alsa crate. I hope you will find it to be correct 🙂

[mitchmindtree]

Hi folks, just wanted to notify you that this is currently being discussed at #386 :)

[mitchmindtree]

Closed via #386.