uaudio patch,

[Mathew Kanner]

On Apr 28, Alexander Leidinger wrote:
> Mathew Kanner <mat at cnd.mcgill.ca> wrote:
> 
> >	I realise I'm the only one whose taken this position so I'll
> >withdraw it.  But for the record, this is my reasoning, what the heck
> >are you going to do with this informaiton: it doesn't help you.
> 
> If you want to go to the soundcard directly, without any conversation, you
> need to know what you can use.

	But this doesn't help.  At all.
> 
> > Other
> >interesting but often usesless information is printed in boot_verbose.
> >The listed capablities are often way beyound what our sound interface
> >can offer.
> 
> Just because it can't offer it _yet_, it doesn't mean we don't teach the
> interface to use it later. And parts of this improvement can be addressed
> from both sides (step by step).

	But this doesn't help.  At all.  (Because it isn't an
interface, it's only text output).  Expanding our abilities for
different formats and flagging which ones are hardware based is
*completly* serperate project.

> 
> > If you want to know what avaiable then connect to the
> >sound device and issue an ioctl like every other app.
> 
> If I have an app which plays some audio files. And if I have the opportunity
> to generate the right file with a conversation program which converts
> "something" (e.g. text to speach) but doesn't knows about an output device,
> and I want to generate the right output, I have to know what I can use. A
> human being which just knows about tools, but not about ioctl(), I need
> something which tells me what I can use. Do we have an app which does this?
> Do we need such an app, or would it be convenient to just look at "cat
> /dev/sndstat"?

	I'm not sure I %100 understand here but I think we should have
an app (say mixer) whihc will IOCTL for the caps and report to the
user.  This is a reporting tool only.  Apps that need to know will
IOCTL as usual.

> 
> >	Anyway, as a general concept, I think we should start
> >expanding our using sysctls.
> 
> I think it depends. For status/capabilities/static like output, we should
> look at enhancing existing interfaces (if they fit into the big picture of
> what we want to add), like our "sound status device".
> 
> For general "mode switching" (whatever this means) which doesn't fit into 
> the
> 4Front-OSS model, sysctl looks like a nice candidate. But another nice
> candidate would be a "sndctl" program which may interact with the device
> over /dev/dspX.ctl orsomething like this.

	Oo, a nice thought.
> 
> Is there something specific you have in mind regarding the sysctl proposal?

	Yes, for now we need commit Kazuhito HONDA patch for uaudio
that provices sysctls for all available mixer/device settings.

	I have a dream (just a dream, I doubt I'll ever achieve it) is
that our sound model is based on what the uadio standard provides.
When an app wants to know that caps they get a descriptor just like
what uaudio gives.  Their format has quite a bit of thought behind it
and its very flexible.  Really, one could take that uadio description
and convert it and run it through 'dot' and get a block diagram of the
soundcard.  That block diagram is usually only available in comments
in the source.
	--Mat