Use PulseAudio for BSD

[hajimehoshi]

ALSA is not listed in OpenBSD package list

https://ftp.openbsd.org/pub/OpenBSD/7.0/packages/amd64/

[hajimehoshi]

Just using PulseAudio might solve this:

https://github.com/hajimehoshi/ebiten/commit/13e84f022477ea6e4055b01438cf8f9390ffcb84

[divVerent]

Yeah. FreeBSD has ALSA in the ports collection, and technically it wouldn't be much work to at least ship a pulseaudio-only-supporting ALSA userspace for OpenBSD or NetBSD... but it's not in their ports and pkgsrc.

I sure would like to see support for all the BSDs, though. Whether that means a pulseaudio or BSD audio / OSS-ish backend I do not really care.

[divVerent]

Actually, I may be wrong - apparently NetBSD has some ALSA stuff in its pkgsrc now. Gotta try that out. That would still leave OpenBSD though.

[reezer]

It's actually a bit more complicated than that for FreeBSD. One is able to configure how ports are compiled, so you might be using one of these and probably more:

• OSS directly
• PulseAudio (if the user decides so)
• Sndio (if the user decides so)

OSS should always work on FreeBSD. The same is true for DragonFly BSD.

For OpenBSD one can safely assume that sndio will always work. It has a pretty simple interface.

I think the ALSA parts you refer to might be the Linux compatibility layer, that FreeBSD offers, which technically isn't really running on FreeBSD.

For pkgsrc one also has to be careful to not mix things up. pkgsrc is also used by the MINIX 3, some Solaris/illumos distributions and also is compatible with Linux and other operating systems.

I am not completely sure about NetBSD. I think OSS is a safe option here as well.

All of them also support pulseaudio, if it is installed. So that's always an option.

[midnadimple-zz]

pulse is prob best option, since most people, regardless of what os they're using, will have it installed already. how difficult would it be to transition?

[hajimehoshi]

The implementation is not difficult. Actually there was an implementation https://github.com/hajimehoshi/ebiten/commit/13e84f022477ea6e4055b01438cf8f9390ffcb84

The problem is that I don't have an environment to test this.

[midnadimple-zz]

huh, it just so happens that I do. ill test it out

[hajimehoshi]

Thanks, I'll queue this task to my task list... Stay tuned

[divVerent]

As latency can matter a lot for some games, maybe at least for some transition period offer both ALSA and pulseaudio (if both compiled in), similar to how we now have DirectX and OpenGL on Ebiten?

On Wed, Apr 13, 2022, 12:27 Hajime Hoshi @.***> wrote:

Thanks, I'll queue this task to my task list... Stay tuned

— Reply to this email directly, view it on GitHub https://github.com/hajimehoshi/oto/issues/154#issuecomment-1098252163, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB5NMG3ZNAUZHFGFABLZJ3VE3YXVANCNFSM5GTEDDHQ . You are receiving this because you commented.Message ID: @.***>

[hajimehoshi]

This sounds a good idea, but the affected environment is only FreeBSD, and this is originally not well tested to be honest. So, I think it is ok not to have a transition period.

[divVerent]

Sorry, I mean - if you implement pulseaudio support, then that would not only cover all the BSDs, but Linux too.

So if that is the approach taken, why not in the long term move to that for Linux too? Would also make snap and flatpak integration easier.

However after all that tends to happen on Linux audio, I would want to see a transition mechanism for that.

On Wed, Apr 13, 2022, 22:20 Hajime Hoshi @.***> wrote:

This sounds a good idea, but the affected environment is only FreeBSD, and this is originally not well tested to be honest. So, I think it is ok not to have a transition period.

— Reply to this email directly, view it on GitHub https://github.com/hajimehoshi/oto/issues/154#issuecomment-1098644278, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB5NMBRG7S7TVUOUXKGBNTVE56FFANCNFSM5GTEDDHQ . You are receiving this because you commented.Message ID: @.***>

[Kimapr]

I use exclusively PulseAudio on my Linux device, and the use of ALSA here makes AAAAXY play sound on the wrong device (I want it to play over HDMI but it plays on laptop speakers instead) with no obvious way to fix this. P.S. solved by installing pulseaudio-alsa, which makes ALSA go through PulseAudio.

[hajimehoshi]

I'm not sure the convention in Linux. ALSA is a kind of lower-level thing than PulseAudio, but probably am I misunderstanding?

[karlpip]

I would like to ask if it's possible to leave the ALSA implementation in the code in case you want to implement Pulseaudio support. So one can chose between them somehow, maybe with an ENV var?

Currently i am using Oto on a machine which does not need Pulseaudio because there is only one sound emitting program at a time. In my case installing Pulseaudio would only be unnecessary bloat and energy waste as it starts user services.

[hajimehoshi]

Enabling to choose PluseAudio sounds an interesting idea. Let me think...

[divVerent]

I'm not sure the convention in Linux. ALSA is a kind of lower-level thing than PulseAudio, but probably am I misunderstanding?

It's complicated. It technically is, but PulseAudio can use ALSA as a backend and ALSA can use PulseAudio as a backend.

The point of this bug is rather the fact that PulseAudio (and the protocol-compatible Pipewire) exists on more operating systems than ALSA.

[reezer]

I hope this is helpful and might also be interesting to people coming here searching. There is a very cross-platform C library that does support pretty much all of Go's supported platforms called miniaudio. There is a Go library interfacing with it, called malgo. I am writing it because it's a great overview of what could be done and which platforms support which backends. Unless many other options it also doesn't require much to set it up and get it building on all the platforms.

Maybe something to steal ideas or even code (miniaudio is public domain) from.