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
nia writes:
> Unfortunately file formats are standardized but the
> the way the audio APIs are implemented varies. :/
>
>> It's now no longer broken to handle 24bit WAV files.
>
> This is true, but audioplay is hardly the only
> consumer of the API and could easily be made to communicate
> with
Unfortunately file formats are standardized but the
the way the audio APIs are implemented varies. :/
> It's now no longer broken to handle 24bit WAV files.
This is true, but audioplay is hardly the only
consumer of the API and could easily be made to communicate
with the kernel using 32-bit
>> But that comment clearly indicates that _someone_ thought it
>> reasonable to checksum before swapping, so I can't help wondering
>> what use case that's appropriate for.
> It's a checksum over the 16bit words in native byte order. So when
> you access the words in opposite byte order, you
n...@netbsd.org (nia) writes:
Hi nia,
>I believe this should not be enabled, and that applications
>should be trained to write 32-bit linear samples instead.
Two things.
The "userland" 24bit format flag is required for internal 24bit
processing because someone thought that without 24bit
I believe this should not be enabled, and that applications
should be trained to write 32-bit linear samples instead.
The reason being that it's very confusing how exactly
24-bit samples should be encoded, and different applications
and implementations have different ideas.
In OSSv4, S24 means
