sound documentation for the snd_hda (Nvidia)

[Chuck Robey]

Alexander Leidinger wrote:
> I'm not directly involved in the HDA driver. What I wrote is subject to
> how the HDA driver was before it entered the tree. Ariff based his work
> upon this driver and committed it to -current after some work. So far
> only stereo inout/output is done. For multichannel output our
> soundsystem needs some infrastructure changes. Ariff worked on this
> already, for a status of this you need to ask him. AFAIK Ariff didn't
> worked on other parts the azalia spec allows to do. The comment in the
> pre-CVS driver was related to this, as it was tailored to get some
> sound out of the chips. How much Ariff extended upon this, I don't
> know. AFAIR he did some changes, but I don't know to what extend. For a
> final answer you have to ask Ariff.
> 
>> You need to understand, I think, that the basic approach to hardware 
>> orginization in the HDA spec is pretty much totally different than any 
>> other existing audio card design.  It wouldn't be possible to fold any 
>> existing design alongside this driver, because it would be like trying 
>> to design in some mechanical transmission that would serve to work 
>> equally well for a airship and a tricycle.  It ain't a'gonna fly, at 
>> least, it'd be very very difficult to treat the driver both as AC'97 and 
>> Azalia, both in the same driver.  That's not saying that a particular 
>> piece of hardware wouldn't have an AC'97 side and a HDA side, but one 
>> driver wouldn't run both ways.  At least, trying to do that in one 
>> driver would make ME schizophrenic.  I am not going to pay a shrink even 
>> if I get a great driver out of it.
> 
> The goal is to make the HDA driver handle the azalia part of the chips.
> And AFAIK the possibility to use the AC97 part is some decision which
> has to / can be made at soundcard-/mainboard-design-time. So AFAIK some
> boards don't support the AC97 part of it at all. For this reason I
> don't think it makes sense to offer AC97 support additionally to the
> azalia support as well.
> 
>> It's pretty obvious that a driver working compatibly with HDA would have 
>> to be a separate system than any other driver, using only the same PCI 
>> buss access code.  I was thinking, if that comment was actually not just 
> 
> I think you better have a look at the hda driver and how it attaches to
> the FreeBSD sound infrastructure. If you gain some insights into the
> working of the sound system it would be great if you could write
> something up. Either in our wiki, as doxygen comments directly in the
> code, or in some other way of documenting it. We lack good docs for the
> sound system (and I've put up an entry on our ideas list for this task,
> but so far nobody send in something (even getting docs for small parts
> of the sound system would be great)).
> 
>> outdated garbage, then it was referring to the organization of driver 
>> internals.  What I['m saying is, I'm a bit skeptical of this, what you 
>> show, below.

Separately, I hjave finally laid to rest my worry that the snd_hda 
driver was due for a major rewrite.  Stuart Barkley pointed out details 
from cvs log entries pointing out that the comments were before the 
current implementation was a fact, so the comment about a rewrite has in 
fact been accomplished, and that comment should be edited.

> 
> It depends where you draw the line. I haven't defined what "sound
> subsys" is in the diagram. It may be the case that we have to change
> the interface between the drivers and what we define as the sound
> subsys.
> 
> A more detailed diagram could be this:
> 
>                           /dev/dsp, /dev/mixer, ...
>                                    |
>               generic sound infrastructure (rate conversion, ...)
>                        |            |
> HDA "middleware" -- driver A      driver B -- AC97 "middleware"
> 
> 
> Another way could be:
>                           /dev/dsp, /dev/mixer, ...
>                                    |
>               generic sound infrastructure (rate conversion, ...)
>                        |            |
>            HDA infrastructure      AC97 infrastructure
>               |                           |
>           driver  A                   driver B, C, D
> 
> 
>> If anyone knows, for certain, whether a rewrite of the snd_hda driver is 
>> still intended, please let me know.  If it's not, well, that comment 
>> really needs to be excised.  But, no matter how well-intentioned, no 
>> more guesses, they're just going to confuse me more.
> 
> For a definitive answer, we need to ask Ariff (CCed).
> 
> Bye,
> Alexander.
> 
>>> +----------------------------------------+
>>> |   FreeBSD kernel                       |
>>> |                   +--------------+     |
>>> |                   | sound subsys |     |
>>> +-------------------+------+-------+-----+
>>>                            |
>>>                    +-------+--------+
>>>                    |   HDA code     |
>>>                    +----------------+
>>>
>>>
>>> And I think the goal is to get something like:
>>> +----------------------------------------+
>>> |   FreeBSD kernel                       |
>>> |                   +--------------+     |
>>> |                   | sound subsys |     |
>>> +-------------------+------+-------+-----+
>>>                            |
>>>                   +--------+--------+
>>>                   |HDA bus/framework|
>>>                   ++-----+--------+-+
>>>                    |     |        |
>>>                 sound   ...     something_else
>>>
>>>
>>> Hope this helps,

It does, and my thanks.  I have decided to perform, as a first step, an 
enhanced HDA diagnostic tool, because it should be of major help in 
getting the driver working, afterwards.

>>> Alexander.
>>>
> 
>