Re: LINEAR24 userland format in audio(4) - do we really want it?

[mlelstv%serpens.de@localhost (Michael van Elst)]

nia%NetBSD.org@localhost (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 userland
there wouldn't be 24bit hardware to support.

I can easily find "userland" files with 24bit audio that can be
processed unless there is the artificial rule to forbid their use.
These are standard files used on other platforms and audioplay
can now handle a standard 24bit WAV file.



>The reason being that it's very confusing how exactly
>24-bit samples should be encoded, and different applications
>and implementations have different ideas.

That's why we have container formats that exactly describe
this for compatibility and applications that follow standards.

Please also don't forget that audio(4) isn't that flexible
when it comes to handling of sample encoding. For userland
there is still only one precision value that doubles as
stride. There is only one bit assignment (modulo endianess)
that an application could specify. Everything else still
requires reformatting by the application, so there is
little to confuse. We only support linear samples that
use 1,2,4 and now also 3 consecutive bytes in memory.

If an application needs to handle samples that aren't
stored in consecutive bytes, it has to parse and
reencode them, just like it always had to do.


>I think the confusing situation means that a lot of
>applications will be broken.

It's now no longer broken to handle 24bit WAV files.