On Mon, May 08, 2023 at 06:17:41PM -0400, Greg Troxel wrote:
Hi Greg,
> I'm not following. Are you saying
>
> we should remove suppport from the kernel API for 24-bit linear?
24-bit support was disabled a long time for fear of "confusing software"
and I have enabled it to support 24-bit hardware. Without "userland
support", the code for handling 24-bit audio sources and sinks was
disabled (and broken). I also added support for 24-bit data to
audioplay/audiorecord, mostly to exercise the driver.
For other reasons, the whole audio system was limited to 16-bit audio
or some parts would silently assume to be 16-bit and even panic if
something told it to use anything else.
It still is limited to some degree as the audio mixer still runs in
16-bit, so all data gets truncated and later expanded as necessary
unless you rebuild the system with AUDIO_INTERNAL_BITS=32. (There
are a few uncommon drivers that may need to be fixed).
Support for 24-bit audio (or 32-bit audio) is rarely needed. For
all practical purposes 16-bit is enough for recording or playing audio.
There is studio equipment that goes beyond that, not much for audio
fidelity, but for comfort. I'm still not sure if 32-bit internal audio
processing is worthwhile as it adds overhead for low-end systems
(on the other hand the in-kernel mixer is much heavier, so these
already lost).
As for "confusing software", we basically hide capabilities of the
audio system. Applications only talk to virtual audio hardware
and pass an audio format that supports linear audio data only
as consecutive bytes (1,2,4 and now 3 bytes per sample) but not
creative bit allocations (like the feared 24-bit bits inside a 32-bit
word) or odd bit counts. You simply cannot specify this (or specify it
"wrongly"). So the only difference is now that an application does not
fail if it specifies 3 bytes per sample.
N.B. most software just hardcodes 16-bit little-endian signed samples and
one fixed sample rate of 48kHz (or 44.1kHz if the programmer remembered
audio CDs) and our audio driver will crudely resample this to what it
and the hardware supports.
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
