sound documentation for the snd_hda (Nvidia)

[Chuck Robey]

Alexander Leidinger wrote:
>> I was operating under the assumption that those comments from hdac.c,
>> about the snd_hda driver badly needing a complete rewrite because it
>> was insufficiently, well, bussed?  Yeah, bussed meant that code rework
>> was ongoing.
>>
>> If you even know what that comment about the busses being less than
>> they might be means, IF you could point me at any driver that you
>> personally think shows a more *ideal* setup, it would at least make me
>> aware of what's really wanted.  You don't need to describe it yourself,
>> I know that'd be a major bore to do that for me, and I could probably
>> learn as well by just reading code that illustrates what things
>> *should* be.
> 
> AFAIK, the non-ideal part of the driver is not related to our 
> soundsystem. I was told the HDA architecture allows more than just the 
> normal sound output you get with, e.g. AC97 based soundcards. So I think 
> the idea is to split up the driver specific part a little bit more, so 
> that you can add more things later. So the parts you need to read are 
> the HDA specs and get an idea what can be improved there. Graphically 
> it's like this ATM:

It's getting to the point that I really, really am getting confused. 
You're telling me stuff about the driver, but others are telling me that 
the comment is out of date and incorrect, that there is no such driver 
rewrite under consideration.  The comment in hdac.c is quite clear and 
definite that it IS going to need a rewrite, that's why I have been 
asking this.  Do you know this to be true, or false, or is this maybe a 
guess?

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.

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 
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.

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.


> +----------------------------------------+
> |   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,
> Alexander.
>