kern/42016: audio(4) does not handle formats where validbits!=precision

[jmcneill%invisible.ca@localhost]

>Number:         42016
>Category:       kern
>Synopsis:       audio(4) does not handle formats where validbits!=precision
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 08 11:45:00 +0000 2009
>Originator:     Jared D. McNeill
>Release:        NetBSD 5.99.16
>Organization:
        
>Environment:
        
        
System: NetBSD pipes.invisible.ca 5.99.16 NetBSD 5.99.16 (MONOLITHIC) #54: Tue 
Sep 8 07:15:49 EDT 2009 
jmcneill%ptichka.invisible.ca@localhost:/Users/jmcneill/branches/HEAD/src/sys/arch/i386/compile/obj/MONOLITHIC
 i386
Architecture: i386
Machine: i386
>Description:
        From audiosetinfo():

                if (SPECIFIED(p->precision)) {
                        pp.precision = p->precision;
                        /* we don't have API to specify validbits */
                        pp.validbits = p->precision;
                        np++;
                }

        This means that if hardware supports eg. 20- or 24-bit samples in
        32-bit containers, userland has no way to select this.

        In theory the hardware driver should be able to set
        precision=validbits (so eg. 24-bit samples in 24-bit containers) and
        implement its own audio filter for linear24_to_linear32 conversion,
        but attempts to make this work have been unsuccessful. Maybe it needs
        the following change from OpenBSD:

          http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/audio.c#rev1.101

        A few thoughts;

        1. For eg. 24-bit samples, is it more likely that userland will supply
           a 24/24 or 24/32 stream?
        2. Extending AUDIOSETINFO is not desirable, and OSS compatibility
           should also be taken into account.
>How-To-Repeat:
        
>Fix:
        

>Unformatted: