kern/44677: NetBSD-5 pad(4) output always 2-channel

[mm_lists%netbsd.org@localhost]

>Number:         44677
>Category:       kern
>Synopsis:       NetBSD-5 pad(4) output always 2-channel
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 04 08:15:00 +0000 2011
>Originator:     Matthew Mondor
>Release:        NetBSD-5
>Organization:
>Environment:
NetBSD behemoth.xisop 5.1_STABLE NetBSD 5.1_STABLE (GENERIC_MM) #0: Thu Dec 30 
08:12:30 EST 2010  
root@behemoth.xisop:/usr/obj/sys/arch/i386/compile/GENERIC_MM i386

>Description:
Lately I wrote a software synthesizer.  I then had the idea to try
pad(4) for the first time to record the results to file.

The pad(4) device won't accept audio(4)-style ioctl(2)s to set such
configuration options, and thus can only be used via read-only
commands like dd(1) and cat(1) rather than audiorecord(1).
I understand that if those ioctl(2)s worked, non-identical pad(4)
and corresponding audio(4) configuration would be problematic.

When opening /dev/audio1 then setting it for 16-bit s-linear 44100
1-channel, the /dev/pad0 reader appears to still receive 2-channel
input.  If that is the expected behaviour, then it probably should
be documented.

In the case of my software synth, of course I could simply also
write the 1-channel output to a file directly instead.

The following is a sample recorded directly by the synthesizer:
http://ftp.pulsar-zone.net/pad/sample-real
$ audioplay -f -c1 -e slinear_le -P 16 -s 44100 ./sample-real

Followed by the pad(4) recorded result:
http://ftp.pulsar-zone.net/pad/sample-pad
$ audioplay -f -c2 -e slinear_le -P 16 -s 44100 /tmp/sample-pad

Note that the extra bytes (sample-pad is slightly larger than twice
the size of sample-real) are due to real-time software lag of the
unoptimized prototype implementation.

>How-To-Repeat:
Open /dev/audio1 and send 1-channel data to it, while recording from
/dev/pad0 using dd(1).  Notice that the results are 2-channel.

>Fix:
Perhaps make pad(4) output 1-channel data when the corresponding
audio(4) device is also configured for 1-channel.  Or document that
pad(4) creates two channels in all cases, mirroring a single channel
to the second one.