Add support for 24-bit and 32-bit audio output.

[AliceLR]

Patches necessary to actually use the 32-bit output support added by libxmp/libxmp#964 (see libxmp/libxmp#924). This is a work in progress and can be finished after libxmp 4.7.0 is out.

Drivers with 24-bit and 32-bit audio support:

• ALSA
• BeOS/Haiku (only Haiku tested)
• CoreAudio
• NetBSD
• OSS
• PulseAudio
• sndio
• WinMM
• AIFF file
• Raw file
• WAV file

Drivers that do not support 24-bit or 32-bit:

• DART (compilation tested only)
• Sound Blaster

Skipped drivers (I do not have a testing environment):

• AHI
• AIX
• ALSA 0.5
• BSD
• HP-UX
• QNX
• SGI
• Solaris

[sezero]

Drivers with 24-bit and 32-bit audio support:

* [ ]  OSS

I think it's possible with new (4.x) oss versions, e.g. freebsd: See their sys/soundcard. h at https://cgit.freebsd.org/src/tree/sys/sys/soundcard.h#n175 for AFMT_S32_NE and AFMT_S24_NE, for e.g.

* [ ]  ALSA 0.5

Can't we just remove that prehistoric backend?

[AliceLR]

I think it's possible with new (4.x) oss versions, e.g. freebsd: See their sys/soundcard. h at https://cgit.freebsd.org/src/tree/sys/sys/soundcard.h#n175 for AFMT_S32_NE and AFMT_S24_NE, for e.g.

I think this is correct, but I didn't look that closely. The current lists were kind of just guessing based on the defines I could easily search. The only drivers I looked at with any depth are the ones that are updated and working, so far. (Also, I forgot to put WinMM in the list—seems that like WAV, it works but you need to use WAVEFORMATEXTENSIBLE?)

Can't we just remove that prehistoric backend?

Not sure; I think if that happens, it should wait for a later release. (I think anything that only supports ancient ALSA should also have OSS?)

[AliceLR]

AFMT_S32_NE

Confirmed that this works in NetBSD. I will try the other BSDs too once I'm done with NetBSD (if only to see if anything actually supports AFMT_S24_NE...).

[AliceLR]

* [ ]  sndio

You need to use model=ac97 to even get this to work out of the box running in QEMU??? 🤨

Is there anything modern that supports the "BSD" driver or should I dig up older BSD releases?

[AliceLR]

@sezero due to this, and the remaining two issues for 4.2.1 being related to new/modified options, should we just go ahead and plan for this release to be 4.3.0 instead?

[sezero]

@sezero due to this, and the remaining two issues for 4.2.1 being related to new/modified options, should we just go ahead and plan for this release to be 4.3.0 instead?

From users' point of view, 4.3.0 vs 4.2.1 is more indicative of lots of feature additions, so that's OK for me.

Are we still keeping libxmp-4.4.0 compatibility?

[sezero]

Are we still keeping libxmp-4.4.0 compatibility?

Tested this branch built against 4.6.2 and 4.7.0, ran against 4.6.2 and 4.7.0 with -d alsa -b 32, seems OK so far.

[AliceLR]

Are we still keeping libxmp-4.4.0 compatibility?

The two features that rely on 4.7.0 already have runtime version checks, and it might ease transition pains if someone finds a bug with 4.7.0. I say keep 4.4 compatibility for now.

[AliceLR]

WinMM driver is patched now, @sezero you may want to test it with old stuff because I probably did it wrong. 🙂

CoreAudio pending my Macs not being buried (soon, probably).

[sezero]

WinMM driver is patched now, @sezero you may want to test it with old stuff because I probably did it wrong. 🙂

Is cbSize assignment correct?

Other than that, is WINVER check out of concern for (i) building against old SDKs, or (ii) is it that because windows older than w2k doesn't support this, or both? How about defining our own XMP_WAVEFORMATEXTENSIBLE for (i), and using a runtime windows version check for (ii)?

[AliceLR]

Did another consistency pass—all of the drivers that this branch substantially touches no longer directly modify options->format, but instead use the new update_format_* functions, and the 24-bit check in the driver play functions is more consistent between drivers.

I will check the #pragma pack patch when I get a chance. Is that something from Microsoft's headers? I did not see it in the MINGW headers (may have just missed it).

[sezero]

I will check the #pragma pack patch when I get a chance. Is that something from Microsoft's headers? I did not see it in the MINGW headers (may have just missed it).

They (both msvc and mingw) include pshpack1.h/poppack.h to adjust structure packing in mmreg.h and also in many other sdk headers.

[AliceLR]

Small patch to ensure structure packing, also no harm including mmreg.h. (Build-tested only.)

Applied. It might have worked without this before because WAVEFORMATEX was declared in the Windows headers with packing, then.

[sezero]

Small patch to ensure structure packing, also no harm including mmreg.h. (Build-tested only.)

Applied.

Seems lost in the last force-push: https://github.com/libxmp/xmp-cli/compare/502f2f1dda900d3697ee46c306faaf167f144f13..ac9904379e287c0a190526b97095d8be7370251a

[AliceLR]

DART

Finally installed OW (via Wine because both Linux installers crash...). Nothing in the API prevents 24-bit or 32-bit audio, but what I'm not able to find is whether or not OS/2 actually supports this (edit: there's no BPS_24 or BPS_32, so not looking likely.) Guess I'll set up a VM tomorrow.

[sezero]

Re DART: As I understand it, BPS_32 isn't defined: Looking at kai, it defines its own but only uses it in its uniaud backend (which is an alsa derivative available in later os/2 variants.) So, I guess we can stick to 8/16 bit ins sound_dart.c, unless I'm missing something.

[AliceLR]

Guess I'll set up a VM tomorrow.

My mistake for having the audacity to claim I could simply set up an OS/2 virtual machine—I'm encountering QEMU bugs that prevent the VM from booting that were allegedly fixed in 2024 🙃 if you're okay with the DART patch as-is, I'll just leave it with the two TODOs for now.

[sezero]

[Missed this comment...]

if you're okay with the DART patch as-is, I'll just leave it with the two TODOs for now.

Yes, leave dart to operate only with 8 and 16 bits. (Can't run-test at the moment, though..)

[AliceLR]

Pushed my best attempt at a CoreAudio driver fix without being able to test it, which I should be able to this weekend.

[sezero]

Pushed my best attempt at a CoreAudio driver fix without being able to test it, which I should be able to this weekend.

Typo at line 221 of sound_coreaudio.c, leading to build failure:

--- sound_coreaudio.c~
+++ sound_coreaudio.c
@@ -220,3 +220,3 @@
 	update_format_signed(options,
-			!!(ad.FormatFlags & kAudioFormatFlagIsSignedInteger));
+			!!(ad.mFormatFlags & kAudioFormatFlagIsSignedInteger));
 	update_format_channels(options, ad.mChannelsPerFrame);

[AliceLR]

Typo at line 221 of sound_coreaudio.c, leading to build failure:_format_channels(options, ad.mChannelsPerFrame);

😎

[AliceLR]

Typo at line 221 of sound_coreaudio.c, leading to build failure:_format_channels(options, ad.mChannelsPerFrame);

😎

Seems to work perfectly in El Capitan after correcting that, will try some slightly newer OS versions when my mini's GPU stabilizes long enough for me to update MacPorts and build anything.

The xmp driver also needs to filter unsigned for sample sizes >8, since CoreAudio is unable or unwilling to massage these back to signed and instead rejects the config.

[AliceLR]

Also, we should probably consider something like this:
https://sourceware.org/pipermail/newlib/2021/018753.html

Snow Leopard has Automake 1.10 :)

edit: also, PKG_CHECK_MODULES at configure.ac:46 sometimes fails to expand (Autoconf 2.61; also encountered it briefly in another environment, but it disappeared)?

[sezero]

Also, we should probably consider something like this: https://sourceware.org/pipermail/newlib/2021/018753.html

Snow Leopard has Automake 1.10 :)

edit: also, PKG_CHECK_MODULES at configure.ac:46 sometimes fails to expand (Autoconf 2.61; also encountered it briefly in another environment, but it disappeared)?

See #82

[AliceLR]

I will start re-checking the drivers with major changes and hopefully mark this as ready later.

I'll make a follow-up patch to at least get the "skipped" drivers using the new sound.h inline functions, but I don't think I can test any of those (compilation or runtime) (AHI: no toolchain; AIX, HP-UX, QNX, SGI, Solaris: no headers/libs, so no testing environment for proprietary UNIX currently; ALSA 0.5, BSD: no headers/libs in anything modern, so no testing environment).

[sezero]

AHI: no toolchain;

Tested AHI under Linux-hosted-AROS, seem to work.

[AliceLR]

Tested AHI under Linux-hosted-AROS, seem to work.

Does it have 24-bit/32-bit support? I can try to give it a proper patch (instead of just clearing the 32-bit flag) too.

[sezero]

Does it have 24-bit/32-bit support? I can try to give it a proper patch (instead of just clearing the 32-bit flag) too.

Looked at devices/ahi.h, it does have AHIST_M32S and AHIST_S32S, so it
should be possible to support it. (Adding ifndef's for those two macros
should make us stay at the safe side, but whatever.)

#define AHIST_M32S		(8UL)			/* Mono, 32 bit signed (LONG) */
#define AHIST_S32S		(10UL)			/* Stereo, 32 bit signed (2×LONG) */