sound documentation for the snd_hda (Nvidia)
Alexander Leidinger
Alexander at Leidinger.net
Sat Dec 1 04:06:43 PST 2007
Quoting Chuck Robey <chuckr at chuckr.org> (Fri, 30 Nov 2007 17:02:05 -0500):
> 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?
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.
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,
> > Alexander.
> >
>
--
It would be illogical to assume that all conditions remain stable.
-- Spock, "The Enterprise Incident", stardate 5027.3
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
More information about the freebsd-multimedia
mailing list