On Mon, Feb 23, 2009 at 03:10:07AM -0800, J.C. Roberts wrote:
> My build of -current is a few days old. I'm having problems recording
> with aucat on a particular device.
>
> The system has an integrated "Intel 82891DB AC97" audio chipset and has
> three physical jacks: one output (headphone/hp) and two inputs
> (mic/line-in). All the OpenBSD audio toys work perfectly with the
> integrated device.
>
> The system also has a "Logitech QuickCam Pro 9000" USB web cam and in
> addition to the camera, it also contains a fairly limited audio device,
> basically a cheap, mono microphone with a fixed frequency (16,000Hz).
> The dmesg and output of `audioctl -f /dev/audio1` are at the end.
>
> uvideo(4) /dev/video0
> uaudio(4) /dev/audio1
>
> With OpenBSD 4.4-Stable, I can record with the cheap microphone using
> either ffmpeg or aucat but aucat on 4.4-stable requires user ('-u')
> settings for the device to record properly.
>
> recording
> $ ffmpeg -f oss -ar 16000 -i /dev/audio1 out-ffmpeg-4.4.wav
> $ aucat -u -c 0:0 -r 16000 -f /dev/audio1 -o out-aucat-4.4.wav
> $ aucat -u -e u8 -c 0:0 -r 16000 -f /dev/audio1 -o test44.raw
> playing
> $ mplayer out-ffmpeg-4.4.wav
> $ mplayer out-aucat-4.4.wav
> $ aucat -u -e u8 -c 0:0 -r 16000 -i test44.raw
>
> Doing the same tests above on OpenBSD 4.5-current shows both ffmpeg and
> aucat no longer work for recording audio through the webcam mic. I'm
> sure there is a rate/frequency problem (i.e. playing too fast), but
> also there seems to be a lot of distortion.
>
> Q: Could the ffmpeg record/playback issue be due to the use of 'oss' as
> the format? And if so, is there a "better" choice for recording
> formats with ffmpeg given the improvements in OpenBSD audio?
>
> Yes, I know the easy answer is to just use the perfectly working
> microphone in the integrated sound card on the main board (audio0), but
> getting this funky, cheap microphone on the webcam working properly
> with the new aucat seems useful... mainly because it worked fine with
> 4.4-stable, and the quirks of the device makes for a good test of aucat.
>
> Without the "-u" switch on aucat(1), it will try to auto configure
> itself, but on the cheap webcam microphone, aucat is ignoring the
> number of channels (1) and ignoring the fixed rate (16,000Hz).
>
-u means ``don't try to avoid useless conversions''. Besides to
temporarily workaround hardware bugs (or for testing), this option
shouldn't be necessary. I mean, if it's necessary then there's a
bug elsewhere that have to be fixed.
> The most strange part of aucat on this microphone is the "-c" switch
> channel control somehow effects speed. The default number of channels is
> two (stereo) according to the man page for aucat, but the device itself
> only has one channel.
>
> Using the -c switch along with rate plays close to normal speed but with
> lots of distortion.
For recording the channels range is specified with the -C option,
-c is for playback. On 4.4, it used to depend on the situation,
since then this was simplified/uniformized.
> $ aucat -d /dev/audio1 -u -e s16le -c 0:0 -r 16000 -o out-wcam.raw
since -c is ignored, this records 2-channel s16le at 16kHz (you
want to use -C 0:0 here and shouldn't need -u)
> $ aucat -u -e s16le -c 0:0 -r 16000 -i out-wcam.raw
>
this interprets the file as 1-channel s16le at 16kHz, so parameters
mismatch.
> But not using the -c switch plays far too fast (with distortion)
> $ aucat -d /dev/audio1 -u -e s16le -r 16000 -o out-wcam.raw
> $ aucat -u -e s16le -r 16000 -i out-wcam.raw
>
(there's no -d option, but i suppose this is a typo)
> Q: I don't understand why/how the number of channels affects the rate?
>
it can't! I guess this is because the file is not played with the
parameters with which it was recorded.
> If I turn on debugging and let aucat auto-configure itself (without
> forcing the issue with the '-u' switch), you can see it's actually
> trying to resample from 16000 to 441000Hz, but the resulting file plays
> too fast and with lots of distortion.
>
> $ aucat -f /dev/audio1 -o out-wcam-plain.raw
> out-wcam-plain.raw: assuming headerless file
> safile_new: using 5872(2936) fpb
> file_new: sndio:hdl
> dev_init: hw recording s16le,0:0,16000Hz
> dev_init: using 8808 fpb
> safile_start: play/rec started
> file_new: wav:out-wcam-plain.raw
> cmap_new: out-wcam-plain.raw: s16le,0:0,16000Hz -> s16le,0:1,44100Hz
> resamp_new: 2936/8092
aucat records 1-channel, s16le at 16kHz (required by the device)
then it converts it to 2-channel, s16le at 44.1kHz (required by -o
defaults) and saves the result. So it appears to work.
You probably want to record as follows:
aucat -f /dev/audio1 -C 0:0 -e s16le -r 16000 -o out-wcam-plain.raw
and then to play it:
aucat -c 0:0 -e s16le -r 16000 -i out-wcam-plain.raw
Let me know if above commands properly work on current (they should
work even on few months old -current system, but iirc not on 4.4)
If you are bored by the playback options, you can use .wav for
recording, so parameters are stored in the file. And then,
just:
aucat -i file.wav
[...]
If you remove the -c, -C, -e and -r options (on both commands) they
should work too. The only difference is that you'll get stereo, s16
at 44.1kHz files, involving useless conversions, and since the
signal is mono, only one channel will contain.
-- Alexandre
