[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/44677: NetBSD-5 pad(4) output always 2-channel
>Synopsis: NetBSD-5 pad(4) output always 2-channel
>Arrival-Date: Fri Mar 04 08:15:00 +0000 2011
>Originator: Matthew Mondor
NetBSD behemoth.xisop 5.1_STABLE NetBSD 5.1_STABLE (GENERIC_MM) #0: Thu Dec 30
08:12:30 EST 2010
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
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:
$ audioplay -f -c1 -e slinear_le -P 16 -s 44100 ./sample-real
Followed by the pad(4) recorded result:
$ 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.
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.
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.
Main Index |
Thread Index |