Re: [Kernel-discuss] Re: h5400 h5500 h5550 OSS patches to support monoaudio

From: Jamey Hicks <jamey.hicks_at_hp.com>
Date: Mon, 28 Mar 2005 11:37:26 -0500

Jim Kaba wrote:

>Phil,
> Normally I'd agree with you 100%. I believe this case may be different
>though. I was on the fence about whether to implement this stereo<-->mono
>conversion in the driver versus in the application, but some of the
>arguments (below) convinced me that in this case it was appropriate for the
>driver.
>
> 8KHz mono sound I/O *seems* be be somewhat of a "bare minimum" standard
>-- kind of a least common denominator for support. This is at least true
>for OSS, and possibly ALSA as well. (I'm quite new to both, having only
>dabbled in audio over the years, so correct me if I'm wrong.) In fact, the
>default OSS driver settings for interacting directly with /dev/dsp are
>supposed to be 8KHz mono 16bits per sample. The fact that the h5xxx OSS
>drivers didn't support this format while all the documentation about OSS
>suggested they should, by default, threw us for a loop for a while.
>
>
>
It does seem that 8KHz mono is a default minimum on PCs.

> My experience with iPAQs and Familiar only includes h3800s, h5400s and
>h5500s. But my guess is that all the older platforms (the h3800s for sure)
>supported mono input and output native to the hardware codec. I don't know
>if the other newer platforms use codecs that dropped mono audio like the
>h5xxx series did. But I would say that the current situation is that some
>programs work on some iPAQ models and not on other models *RIGHT NOW* and
>that this patch fixes that fact, at least for the h5xxx series. One of the
>"jobs" of device driver is to hide the details of the hardware and to
>provide a common interface to the applications. With this patch, I'm now
>able to use the same software that I used on our 3800s, while without this
>patch I'll have to hack any audio application I want to use to be sure that
>it supports the other formats.
>
>
None of the iPAQs have supported mono in hardware. They all sample
stereo even from mono sources such as the microphone. We did have a mono
hack in the driver for the h3[1678]00 but dropped it because it was a
barrier to patches getting accepted upstream.

The only applications that seem to need modification are dusty old ones
such as rat and openh323. They've needed fixing since the h3600 days and
still need fixing. If they were updated to query audio capabilities and
use what's available, we wouldn't need to keep hacking the driver.
Doesn't alsa provide userspace stereo to mono conversion? If so, adding
alsa support would solve this problem without making the driver
unpalatable to the mainstream kernel maintainers.

All that being said, I've used a mono hack in the past because it was
expedient and won't try to prevent you from using a mono hack or
distributing a mono hack.

Jamey
Received on Mon Mar 28 2005 - 11:40:22 EST

This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:20:11 EDT