search

Clownacy / clownaudio

Sound engine that is suitable for video games and other multimedia applications.
zlib License
24 stars 2 forks source link

Add CoreAudio backend for macOS #9

Closed NeRdTheNed closed 1 year ago

NeRdTheNed commented 1 year ago

This adds a no-dependancies audio backend for macOS, using only CoreAudio (the native macOS audio API). I've tried to match the code style of clownaudio as close as possible, please let me know if you'd like me to change anything!

Tested with macOS 10.6, 10.14, and 12.6, on arm64, x86_64, i386, and ppc (through Rosetta, compiled for macOS 10.4). All code should be theoretically capable of compiling for any known version of macOS. ppc requires using CLOWNAUDIO_CLOWNRESAMPLER due to issues with miniaudio's use of atomics, but works fine otherwise.

ewancg commented 1 year ago

Why add a platform-specific backend when there are several cross-platform ones to choose from?

NeRdTheNed commented 1 year ago

Why add a platform-specific backend when there are several cross-platform ones to choose from?

Many audio libraries have dropped support for older versions of macOS, which this backend supports. Additionally, this backend is much more lightweight than pulling in an entire library, as it's only around 250 lines of code (including comments and the license header).

ewancg commented 1 year ago

There's an SDL 1.0 backend, has even that dropped support for PPC macs?

NeRdTheNed commented 1 year ago

There's an SDL 1.0 backend, has even that dropped support for PPC macs?

You can certainly use SDL 1 on PowerPC macs, but this backend works with applications which don't use SDL 1 and still want to target PowerPC.

ewancg commented 1 year ago

You don't have to already be using SDL to use the SDL backends. They don't assume SDL has already been initialized.

Anyway, I have no authority here & am just commenting out of curiosity. I'm for it but I think this provides the expectation that there be platform-specific backends for all platforms, so for this to be added & provided in good faith there'd have to be a dsound/WASAPI backend and ALSA/Pulse backends. Which is a lot of work, and probably why there are only cross-platform backends being used at the moment.

ewancg commented 1 year ago

Also, I'm curious what the issue is with atomics in miniaudio

NeRdTheNed commented 1 year ago

Also, I'm curious what the issue is with atomics in miniaudio

Here's some relevant build output:

Undefined symbols:
  "___sync_val_compare_and_swap_8", referenced from:
      _c89atomic_compare_exchange_strong_explicit_64 in libclownaudio.a(miniaudio.c.o)
      _c89atomic_compare_exchange_strong_explicit_64 in libclownaudio.a(miniaudio.c.o)
      _c89atomic_compare_exchange_strong_explicit_64 in libclownaudio.a(miniaudio.c.o)
      _ma_job_queue_post in libclownaudio.a(miniaudio.c.o)
      _ma_job_queue_post in libclownaudio.a(miniaudio.c.o)
      _ma_job_queue_post in libclownaudio.a(miniaudio.c.o)
      _ma_job_queue_post in libclownaudio.a(miniaudio.c.o)
      _ma_job_queue_post in libclownaudio.a(miniaudio.c.o)
      _ma_job_queue_post in libclownaudio.a(miniaudio.c.o)
      _ma_job_queue_next in libclownaudio.a(miniaudio.c.o)
      _ma_job_queue_next in libclownaudio.a(miniaudio.c.o)
      _ma_job_queue_next in libclownaudio.a(miniaudio.c.o)
      _ma_job_queue_next in libclownaudio.a(miniaudio.c.o)
      _ma_job_queue_next in libclownaudio.a(miniaudio.c.o)
      _ma_job_queue_next in libclownaudio.a(miniaudio.c.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

I'm not sure exactly what the issue is, it could be that PowerPC doesn't support these operations, or that my linker setting are somehow wrong.

ewancg commented 1 year ago

Seems like it could be either be unimplemented intrinsics or just some builtin that old Apple Clang doesn't support. Either way, I think you should leave an issue in the miniaudio repo

NeRdTheNed commented 1 year ago

Seems like it could be either be unimplemented intrinsics or just some builtin that old Apple Clang doesn't support. Either way, I think you should leave an issue in the miniaudio repo

I might write up a bug report at some point, but I don't know how much they'll care about issues with Apple GCC 4.2 when building for PowerPC macs. I think it's probably a linking issue anyway.

ewancg commented 1 year ago

Apple GCC?

NeRdTheNed commented 1 year ago

Apple GCC?

Before Clang, XCode shipped a fork of GCC with some extra features for macOS support. Around the time that Apple switched to Clang, PowerPC support was dropped by Apple, so Clang historically doesn't support PowerPC macs. I've been able to compile clownaudio with Apple GCC 4.2.1 and 4.0.1, with https://github.com/devernay/xcodelegacy.

ewancg commented 1 year ago

Cool, I never knew there was such a thing. I think miniaudio wouldn't be opposed to a fix, as I understand it one of their aims is to be as flexible as possible when it comes to which platforms are supported.

mackron commented 1 year ago

I'd be happy to address build issues in miniaudio. I like it to work everywhere where practical. The hard part is that I don't have a way to test on PowerPC.

For the atomic build issue, it may be because you need to link with -latomic.

Clownacy commented 1 year ago

Cool, it's nice to receive a contribution!

I'm not opposed to having extra backends, even if they're somewhat redundant, because a lot of them already are, like the Cubeb and PortAudio ones. A CoreAudio backend would be a welcome addition, even if I can't test it myself.

I've been meaning to make some changes to clownaudio that would end up affecting this backend - could I bother you to relicense the backend to 0BSD and convert its code to C89? Those are how my recent libraries are, and I'd like to alter clownaudio to match them. Don't worry about the C99 bool type - I can switch that over to my C89 equivalent later.

NeRdTheNed commented 1 year ago

Cool, it's nice to receive a contribution!

I'm not opposed to having extra backends, even if they're somewhat redundant, because a lot of them already are, like the Cubeb and PortAudio ones. A CoreAudio backend would be a welcome addition, even if I can't test it myself.

I've been meaning to make some changes to clownaudio that would end up affecting this backend - could I bother you to relicense the backend to 0BSD and convert its code to C89? Those are how my recent libraries are, and I'd like to alter clownaudio to match them. Don't worry about the C99 bool type - I can switch that over to my C89 equivalent later.

No problems! I've changed the license to 0BSD, and reformatted the comments to be C89 compliant.

Clownacy commented 1 year ago

Thanks! By the way, since you wrote the file, feel free to replace the copyright statement at the top of it with your own. I don't think there's anything in there that I could claim copyright ownership of.

Isn't this part here incompatible with C89? C89 doesn't let declarations come after code. With the rest of the project still being C99, I know you wouldn't be able to compile the whole thing as C89, but you should be able to compile that one source file to an object file to test that it compiles as C89 without error.

NeRdTheNed commented 1 year ago

Thanks! By the way, since you wrote the file, feel free to replace the copyright statement at the top of it with your own. I don't think there's anything in there that I could claim copyright ownership of.

Isn't this part here incompatible with C89? C89 doesn't let declarations come after code. With the rest of the project still being C99, I know you wouldn't be able to compile the whole thing as C89, but you should be able to compile that one source file to an object file to test that it compiles as C89 without error.

I totally missed that, fixed!