Date: Sat, 01 Dec 2007 10:28:47 -0500 From: Chuck Robey <chuckr@chuckr.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-multimedia@freebsd.org, ariff@freebsd.org Subject: Re: sound documentation for the snd_hda (Nvidia) Message-ID: <47517DAF.5060005@chuckr.org> In-Reply-To: <20071201130054.6ee3644c@deskjail> References: <47475DF3.8030407@chuckr.org> <47477B4F.6000008@chuckr.org> <47484E4F.8000404@queue.to> <4749D405.6050800@chuckr.org> <20071126092456.ft3ir1peok80ckww@webmail.leidinger.net> <474B011A.6030705@chuckr.org> <20071128080526.qid2w9tvy800cck8@webmail.leidinger.net> <4750885D.5020402@chuckr.org> <20071201130054.6ee3644c@deskjail>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >>> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47517DAF.5060005>