I would like to raise a concern about the recent Linux audio backend change in Oto, where the ALSA backend was deprecated/replaced and Oto now depends on PulseAudio on Linux.
From what I understand, this change is already included through Oto in ebiten/v2 v2.10.0-alpha, which means that applications upgrading to this Ebiten version are now effectively required to have PulseAudio available on Linux.
I think this is an important breaking change.
Until now, our Linux deployments used ALSA directly. In our specific case, we run our games on hundreds of different machines, inside containers. These containers do not run PulseAudio; they use ALSA directly.
In my opinion, this should either:
- be introduced in a new major release, because it changes the runtime requirements for Linux users; or
- keep ALSA available as an optional backend.
I understand the motivation for moving to a pure Go PulseAudio backend, especially if the goal is to avoid CGO and simplify builds. However, removing or deprecating ALSA as the only Linux backend makes PulseAudio mandatory for everyone, including embedded, kiosk, containerized, or minimal Linux environments where ALSA is commonly used directly.
Would you be open to restoring ALSA support as an optional backend?
For example, ALSA could remain available behind a build tag, so users can choose between:
go build -tags alsa
or similar, while keeping PulseAudio as the default backend if that is the preferred direction.
If this approach is acceptable, we would be happy to work on a PR to restore ALSA as an optional backend selected via build tags.
/cc @tinne26
I would like to raise a concern about the recent Linux audio backend change in Oto, where the ALSA backend was deprecated/replaced and Oto now depends on PulseAudio on Linux.
From what I understand, this change is already included through Oto in ebiten/v2 v2.10.0-alpha, which means that applications upgrading to this Ebiten version are now effectively required to have PulseAudio available on Linux.
I think this is an important breaking change.
Until now, our Linux deployments used ALSA directly. In our specific case, we run our games on hundreds of different machines, inside containers. These containers do not run PulseAudio; they use ALSA directly.
In my opinion, this should either:
I understand the motivation for moving to a pure Go PulseAudio backend, especially if the goal is to avoid CGO and simplify builds. However, removing or deprecating ALSA as the only Linux backend makes PulseAudio mandatory for everyone, including embedded, kiosk, containerized, or minimal Linux environments where ALSA is commonly used directly.
Would you be open to restoring ALSA support as an optional backend?
For example, ALSA could remain available behind a build tag, so users can choose between:
go build -tags alsaor similar, while keeping PulseAudio as the default backend if that is the preferred direction.
If this approach is acceptable, we would be happy to work on a PR to restore ALSA as an optional backend selected via build tags.
/cc @tinne26