Audio library alternatives

[nobonobo]

Are you looking to depends on SDL2 to implement native audio in your Lacking Library?
In this case, I felt a little disappointed that the build dependencies were so deep that Go's ease of building was lost.
I would appreciate it if you would consider using the audio library below instead.

The oto is very simple and reliable and crossplatform(win,mac,linux,wasm) audio output library.

https://github.com/ebitengine/oto

[mokiat]

Hi @nobonobo ,

Thanks for bringing this up.

Yes, I switched to SDL2 mostly because of the audio aspect. I guess the fact that SDL2 has more up-to-date gamepad mappings and a rumble capability were bonus points. I am also questioning that choice to be honest. The glfw was indeed much more lightweight and makde the app/games easier to distribute.

The problem is that I tried all sorts of Go bindings to various sound libraries but none seemed to work correctly.

I had oto starred for some time now and it was one potential pick. The issues I see there are as follows:

• The library appears to be a part of the ebitengine engine, so there is a risk that it might be slightly biased or pull in other ebitengine dependencies down the road. Not sure how open they would be to general-purpose improvement requests / proposals.
• The library it uses for mp3 decoding (https://github.com/hajimehoshi/go-mp3) appears to be archived and not under development anymore.
• There does not seem to be any type of panning capability or other audio effects. I assume that I would need to implement a middleware that wraps the io.Reader in order to manipulate the audio stream.
• The library does not provide any means to get the playback position. My ideas were to allow one day for the engine to be temporarily configured to tick based on an audio stream so that audio-video(animation) synchronization can be achieved, so that there can be cutscenes. (To be honest I am not sure how well SDL2 provides this as well)

I always knew that adding audio would likely be hard due to no standardization but it turned out to be real pain and in the end I went with what appeared to be "popular".

I am sorry, I was really not aware that someone else was using lacking. This is why I have mostly been doing brave API changes without considering what the implications might be.

Could you please share what you are using lacking for? Do you use just the native or also the js implementation?
Or if you have something working that is public, I would love to have a look (screenshot / video etc).

This will help me with knowing where to be careful in the future when making changes. Still, there are things in the main lacking code base that are still not well structured/designed and some breaking changes will be necessary in the future, so keep that in mind.

In the meantime, since I am not using any sophisticated panning or audio effects in my projects right now, I will consider rolling back to glfw and using oto for the time being.

[nobonobo]

I wrote sample code with oto/v2.

https://github.com/nobonobo/oto-synth-sample

Recently, "github.com/hajimehoshi/oto/v2" has been transferred to "github.com/ebitengine/oto/v3".

I see. If there are other features you need, depending on SDL2 may be the right thing to do.
Admittedly, it seems difficult to choose dependence.

Another plan is to depend on "miniaudio.h".

https://github.com/mackron/miniaudio

This is header only and has rich functionality.

[nobonobo]

rally-mka is fun!

I once demonstrated a self-made steering wheel controller by modifying your Rally-Mka.
(I use WebHID API)

Currently I'm only using lacking-js. However, I would like it to be kept cross-platform for easy building.

[mokiat]

Nice!

I once wired a G29 steering wheel and made it work but since there is no official API nor mappings (like there is for gamepads), I could not officially roll it out. Also, not having force feedback make it weird to drive.

As for lacking-js, keep in mind that there are some limitations as to how powerful an app can be. It has something to do with memory and web assembly. On mobile the rally-mka game and smaller stuff simply do not run and fail with allocation issues. It is a problem that appears in other engines and programming languages as well, but there you have more memory control to reduce the risk. Furthermore, it seems that the Go team is not actively developing WASM target and there are a lot of unaddressed github issues.

Regarding native, I am waiting to see if malgo (miniaudio) might be an option but that depeds on the following issues:

• Q: Support for High Level API gen2brain/malgo#50
• NULL Audio device on MacOS 14.1.1 (23B81) gen2brain/malgo#48

[nobonobo]

Oh, maybe I can adjust this demo program to work on your G29.
The high-level API for force feedback is covered by the kernel module in Linux and DInput/XInput in Windows, but what is done at the lower layer is the sending and receiving of HID messages. This often has a different format depending on each devices.

I own a "Driving Force GT". Basically compatible with G29.

[nobonobo]

I will start developing a native audio library compatible with wasmal.

https://github.com/nobonobo/nativeal

[mokiat]

Oh, maybe I can adjust this demo program to work on your G29.

No need. I am not really using it anymore. Besides, the rally-mka game is mostly a demo for what the engine can do at the moment.

I will start developing a native audio library compatible with wasmal.

Sound very nice. If you manage to keep it lightweight and cross-platform, this is definitely something I would be looking forward to. In fact, as soon as you can get media playback + gain + panning working, I could integrate it into lacking-native.

[mokiat]

@nobonobo , seeing as there is still not much progress on the audio library, I guess it is as good a time as any to give you a heads up. I am now considering moving to Rust. I will likely still invest a bit more time prototyping the lacking studio in Go, until I have an idea where I want to go with it but eventually I might be switching to Rust.

While I enjoy the language much less than Go, it appears to have the proper community when it comes to graphics/gaming, also it has the WGPU library, as well as the Web Audio API library available and working, both good long-term investments in contrast to the available Go library choices.

While I love Go and will continue to use it for microservices and professionally, there is just no serious community around gaming / sound / graphics and Go developers are disregarding WASM heavily, which is sad, considering that the language is more than capable to compete for anything beside AAA.

[mokiat]

v0.18.2 is based on GLFW and MiniAudio (via malgo) and has feature parity with what the JS implementation has at the moment.

This should cover the problem raised in this issue.