Erik Hovland wrote:
>
> On Mon, Mar 28, 2005 at 11:37:26AM -0500, Jamey Hicks wrote:
> > The only applications that seem to need modification are dusty old ones
> > such as rat and openh323.
>
> I guess the crux here is that RAT is an app that Jim uses Right Now
> (tm). So although it may be dusty old, it is useful. If RAT is basically
> the must work sort of thing for Jim's project I am inclined to allow
> the mono hack into the hh tree (I know you are never going to give me
> cvs write access after saying that :). But this is especially true for
> the 2.4 tree since there really is no upstream maintainers for the hh tree
> anymore. And this patch won't make it into 2.6 since that is all alsa
> territory.
Actually, RAT itself does not seem to be *too* dusty and old -- They had a
new release this time last year. (Now, the ALSA support in RAT is dusty
and old, that is true.)
RAT does check the driver defaults and use only the driver's native
capability -- what is broken (or misconfigured, or whatever) is the apps's
ability to use anything other than the default!
>
> > 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.
>
> Alsa does. And we have a working alsa tree again. It may be worth it to
> just get alsa working again. Drop Jim's patch and go on from there. But
> until someone finds the time to suss-out alsa again Jim's patch is the
> shortest path to Jim and others to working with mono 8khz.
>
> And just to provide 0.02USD about the patch, the patch is short and
> sweet. I like it. Smart to reuse the double_samples hack. Having said
> that I would probably rename double_samples to something like
> num_user_channels and initialize it to 2 (since stereo is default) and
> change it to one when mono is request. An attempt to do that is attached
> as a patch. It is *very* similar to Jim's patch and only makes that
> change.
Now, if I can convince you all to set the default OSS configuration to 8KHz
mono, my plot to downgrade the code will be complete!!!!! Bwaa, haa, haa,
haa!
But, seriously, if 8KHz mono 16bitspersample is the default of the OSS API,
shouldn't the OSS driver set the codec up that way by default? That way
you could actually do
cat /dev/dsp > foo
followed by
cat foo > /dev/dsp
and actually have "normal" audio captured and played back! It seems that
would preserve backward compatability with any old/broken apps completely
-- and new apps would just override these default parameters the way they
should.
(Before you kick me off the mailing list, I'll mention that I'll be
submitting a new "external headset autodetect" patch tomorrow...)
>
> E
>
> --
> Erik Hovland
> mail: erik AT hovland DOT org
> web: http://hovland.org/
> PGP/GPG public key available on request
>
> ---------------------------------------------------------------------------
>
> rework-jims-mono-mode.patchName: rework-jims-mono-mode.patch
> Type: Plain Text (text/plain)
>
> ---------------------------------------------------------------------------
> _______________________________________________
> H5400-port mailing list
> H5400-port_at_handhelds.org
> https://www.handhelds.org/mailman/listinfo/h5400-port
-- ---------------------------------------------------------------------- James T. Kaba Sarnoff Corporation There are 10 kinds of people in the world: jkaba_at_sarnoff.com those who understand binary, and those who don't. 609-734-2246Received on Mon Mar 28 2005 - 19:34:11 EST
This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:20:11 EDT