libsoundio VS cubeb

Audio DSP is definitely the deep end of the pool. I believe the Zig programming language owes its creation to Andrew Kelley (the creator) trying to write stuff for an audio workbench going "damn, this is really hard to do with C, why does C suck so much" and just creating a language that's like C but without the bad parts to do it himself. I'm not joking, this is literally the origin of Zig as I've heard it from a podcast, and here is Andrew's old audio lib for proof: https://github.com/andrewrk/libsoundio

http://libsound.io is a great cross platform library for reading and writing to sound cards. i have used it successfully on macos and i’m sure it supports linux and possibly windows too. you will probably also need lib audio for reading and writing to files.

Hmm... after some research it seems that I've misunderstood Zig's situation a bit. Zig has introduced null-terminated string types a couple of years ago, but still encourages you to do most string operations with slices instead. Let me explain:

Zig's string literals (which you create with parenthesis like "Hello world!") are null-terminated byte arrays, expressed as the type const [N:0]u8 (where the :0 tells you that it's null-terminated), whereas the more typical array might be written as const [N]u8. The reason for this feature is not because the language wants you to use null-terminated strings, but because these static strings need to be stored in the global data section of the ELF executable, and these require you to use null-termination. But if you want to do any mutable operation with this string, you need to convert this into a proper slice (ptr + size). And it seems like Zig developers don't really use null-terminated types that much at the API level, but use it for things like C interop or cases where you really need it for special optimizations.

Noting that from the PR that introduced this feature, Andrew Kelley writes:

> I think you will find that the Zig community in general (and especially myself) agrees with you on this [null-terminated strings being fragile], and APIs in general should prefer slices to null terminated pointers. Even if you are using Zig to create a C library, and even in actual C libraries, I would recommend pointer and length arguments rather than null terminated pointers, like this: https://github.com/andrewrk/libsoundio/blob/1.1.0/soundio/so...

> That being said, I want to repeat what I said earlier about null terminated pointers: A null terminated array is not inherently an evil C concept that is intruding in the Zig language. It's a general data storage technique that is valid for some memory constrained use cases. I also stumbled on a Real Actual Use Case inside LLVM. The bottom line for me is that null terminated pointers exist in the real world, and especially in systems programming. You can see this in interfaces with the operating system in the standard library...

So he acknowledges null-terminated strings can certainly be useful in certain situations outside of legacy reasons, which is good to know. And Zig creating a special type for this shows that a good systems language needs to be designed to accommodate the needs of the outside world.

Perhaps you could use either http://libsound.io/ or SDL2 game library + SDLAudioIn (http://burningsmell.org/sdl_audioin/) which provides low-level APIs to access operating-system sound systems like Alsa, PulseAudio, PipeWire, and CoreAudio (not sure how well it is supported by SDL2).

Comparison: https://github.com/andrewrk/libsoundio/wiki/libsoundio-vs-SD...

Fun fact: Andrew Kelley, the creator of the Zig programming language, kind of created it so he could work on audio processing.

Based on: https://github.com/andrewrk/libsoundio/blob/master/example/sio_sine.c

Does this fit your needs? https://github.com/andrewrk/libsoundio

I listened to the Co-recursive podcast the other day that featured Andrew Kelley, the creator of the Zig programming language. Before Zig he developed Libsoundio - https://github.com/andrewrk/Libsoundio, to solve problems around realtime audio.

Audio will probably come later, but libsoundio will be the first thing in terms of groundwork. Integrating that in the same way we've integrated GLFW, so you can just cross compile and get cross-platform audio to boot.

# Template file for 'yuzu-mainline' pkgname=yuzu-mainline version=1295 revision=1 _cubeb_version=75d9d125ee655ef80f3bfcd97ae5a805931042b8 _sanitizers_cmake_version=aab6948fa863bc1cbe5d0850bc46b9ef02ed4c1a _dynarmic_version=bd570e093ca1d1206961296b90df65cda7de8e87 _sirit_version=d7ad93a88864bda94e282e95028f90b5784e4d20 _mbedtls_version=8c88150ca139e06aa2aae8349df8292a88148ea1 _xbyak_version=348e3e548ebac06d243e5881caec8440e249f65f _SDL_version=f17058b562c8a1090c0c996b42982721ace90903 _cpp_jwt_version=e12ef06218596b52d9b5d6e1639484866a8e7067 _cpp_httplib_version=305a7abcb9b4e9e349843c6d563212e6c1bbbf21 _Vulkan_Headers_version=00671c64ba5c488ade22ad572a0ef81d5e64c803 create_wrksrc=yes build_wrksrc=${pkgname}-mainline-0-${version} build_style=cmake configure_args="-DYUZU_CHECK_SUBMODULES=OFF -DYUZU_TESTS=OFF -DSIRIT_USE_SYSTEM_SPIRV_HEADERS=ON" hostmakedepends="pkg-config qt5-host-tools qt5-qmake clang" makedepends="fmt-devel libenet-devel inih-devel libusb-devel liblz4-devel opus-devel zlib-devel libzstd-devel boost-devel qt5-devel qt5-multimedia-devel libva-devel ffmpeg-devel glslang-devel SPIRV-Headers catch2 json-c++ speexdsp-devel" short_desc="Nintendo Switch Emulator" maintainer="Owen Law " license="GPL-3.0-or-later" homepage="https://github.com/yuzu-emu/yuzu-mainline" changelog="${homepage}/releases/tag/mainline-0-${version}" distfiles="${homepage}/archive/refs/tags/mainline-0-${version}.tar.gz https://github.com/herumi/xbyak/archive/${_xbyak_version}.tar.gz https://github.com/MerryMage/dynarmic/archive/${_dynarmic_version}.tar.gz https://github.com/yuzu-emu/mbedtls/archive/${_mbedtls_version}.tar.gz https://github.com/mozilla/cubeb/archive/${_cubeb_version}.tar.gz https://github.com/arsenm/sanitizers-cmake/archive/${_sanitizers_cmake_version}.tar.gz https://github.com/yuzu-emu/sirit/archive/${_sirit_version}.tar.gz https://github.com/libsdl-org/SDL/archive/${_SDL_version}.tar.gz https://github.com/arun11299/cpp-jwt/archive/${_cpp_jwt_version}.tar.gz https://github.com/yhirose/cpp-httplib/archive/${_cpp_httplib_version}.tar.gz https://github.com/KhronosGroup/Vulkan-Headers/archive/${_Vulkan_Headers_version}.tar.gz" checksum="b8b2616a24653352b8afd145ee46eb9ead07c6ef3aff8c0ff3a6225b381b4b85 fbe54fc881cdfb0876ddc8f29f74674a311ba7ae4b774751cb1b637c043e3bae 170530852547ee2f5517b0a12e643646e51a9974414084d389a85632df7c4518 8d3553ea5c3b47789c5a1a6437f948525d0a8ce2a0897000a36b511000c6bad4 8c5b7ca55ee586a3e5e63de2d31c319045f92e949140a734846a0d69ad342e2e 9f5b073625375322236a94ce8d2d803cdedad321c91e63845f487b9ebfb2c433 6612f924d1f2b2c7cb37effcda5d78550fad276887ee8f9bc391b9ecbf9e4a64 2a149e79712027d2d8141e3233df2f6679825b6f78237db3db72bc6cfc08b845 b4cc0e1f89d3c60a4dde74baa730a90de13c5dd5155b09d8dd34cd3205a6e758 61a97686b03edffa737c396f54e48da2ff0a04c3f6859ec9e80853aea6508030 99443e30caee5d2c0019de6549cc0c7c0432214494617da445753fc46374a7c3" post_extract() { mv "xbyak-${_xbyak_version}" xbyak cp -r xbyak "${build_wrksrc}/externals" mv "dynarmic-${_dynarmic_version}" dynarmic cp -r dynarmic "${build_wrksrc}/externals" mv "mbedtls-${_mbedtls_version}" mbedtls cp -r mbedtls "${build_wrksrc}/externals" mv "SDL-${_SDL_version}" SDL cp -r SDL "${build_wrksrc}/externals" mv "cubeb-${_cubeb_version}" cubeb mv "sanitizers-cmake-${_sanitizers_cmake_version}" sanitizers-cmake cp -r sanitizers-cmake cubeb/cmake cp -r cubeb "${build_wrksrc}/externals" mv "sirit-${_sirit_version}" sirit cp -r sirit "${build_wrksrc}/externals" mv cpp-jwt-${_cpp_jwt_version} cpp-jwt cp -r cpp-jwt ${build_wrksrc}/externals mv cpp-httplib-${_cpp_httplib_version} cpp-httplib cp -r cpp-httplib ${build_wrksrc}/externals mv Vulkan-Headers-${_Vulkan_Headers_version} Vulkan-Headers cp -r Vulkan-Headers ${build_wrksrc}/externals }

Open a new issue at https://github.com/mozilla/cubeb/issues and share the details of your Media section at about:support#media.

Hardware-related audio bugs can be directed here: https://github.com/mozilla/cubeb/issues.

Their resources are better focused on supporting the audio backend that most people use. They do apparently accept patches for ALSA support though.

Full build thread here.

You can report the issue here.

https://github.com/mozilla/cubeb/wiki/Backend-Support inspires a lot of confidence, because it means they pay attention to what the state of support is. FF is probably a bigger and better-maintained user than all the portaudio users combined. The major backends being Rust is a downside if I'll need to pull in Rust standard libraries. But there's no docs, and the knowledge is held by individuals within Mozilla. People before have had trouble extracting cubeb out for use by third parties.