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 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.