Re: 2.4 - buttons, temperature, ictc

On  Wed, Jul 18, 2001, Joseph P. Garcia wrote:

On Wed, 18 Jul 2001 12:11:42 +0100
"Iain Sandoe" [off-list ref] wrote:

quoted

How does the action end up getting routed to the sound driver?

In the current set up, [...]
code that should/will not make the trip into a public kernel.  but i'd have
double check to make sure..

well, I understood that from the original patch (and the objection I had was
just as you say)... I don't fancy trying to maintain that cross-linkage in
dmasound.

quoted

I'd definitely favour a daemon that didn't imply dependence on a particular

[...]

quoted

so that coverage would come as part of a standard install?

I'm not familiar with what kind of apis already exist, but your suggestion
to make something like esound sounds good.

Apart from Bastien's comment in another follow-up..

Given that these daemons try to
allow for such things that we can provide in hardware (iirc), like multiple
opens of /dev/dsp.  So would this be like taking most of the kernel's sound
interface (like mixer too?) and bringing it into a userspace daemon?

as I understand it, yes... although I tend to concentrate on the raw driver
and haven't done much with esound/arts...

 You mention ALSA a bit.
Would this be a better fit than OSS, or are we better making our own?

I doubt (seriously) that another audio API would stand *any* chance of
making it into official linux ... it's still debatable whether ALSA will...

but then again, I always lean a bit too much toward the
generic all-purpose APIs created by Mr./Ms. Someone Else whenever userspace
is involved.

ALSA is *much* cleaner - in principle - all the bloat is taken out of the
kernel drivers into user-land.   However, it's much more complex to set up
at the moment - IMHO probably hasn't really reached 'end user' status yet.

There are starter PPC drivers - based on dmasound.  However, much is still
to be done and ASLA hasn't reached 1.0 yet.  (This is why I'm still working
on adding other Apple chip-sets into dmasound).

And so with this, how much would stay kernel side?  is this a new api'ed
kernel driver, or a userspace driver/daemon using a semi-generic ioctl
interface for ppc sound hardware that also listens to other devices for
control?  Can this be achieved in a kernel thread?  or would that still be
considered kernel-bloat?  not to sure on userspace scheduling reliability.

Well pre-ALSA (which is where we are at) ... the role of user-space
abstraction of the OSS devices is handled by aRts et. al.  So I guess taking
a look at how you might feed stuff to that is a start.

Otherwise, you could take the Apple HIG ethic of letting the user select
things... it works quite well (if you don't have a religious problem with
how they do things ;-)))

(i talk alot when im trying to help)

s'ok - better to get a solution that will be acceptable from the start.
ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/