From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Alsa questions Date: Mon, 16 Jan 2006 16:23:07 +0100 Message-ID: References: <1137367389.4823.40.camel@localhost.localdomain> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <1137367389.4823.40.camel@localhost.localdomain> Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Benjamin Herrenschmidt Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org Hi Ben, At Mon, 16 Jan 2006 10:23:09 +1100, Benjamin Herrenschmidt wrote: > > Hi Takashi ! > > I'm trying to figure out how to properly design a new sound driver for > powermac with Alsa. Great! > Most earlier machines are easy enough in that they have one codec on one > bus. However, things get more tricky on G5 and newer laptops, where you > end up with more than one bus and multiple codecs (I think both multiple > codecs on one bus and multiple busses with separate codecs setups > exist). > > I'm not too sure what kind of relationship Alsa has between PCMs and > mixer devices, and that sort of things yet There is only one control (mixer) device for each card instance. A control device may contain flat array of control elements. Each element includes attributes, the type of interface (mixer, PCM, card-global, etc), the device number, the subdevice number, and the index number. For mixer elements, device and subdevice are not used but only index is referred. When you have the controls with the same role for different i/o's, you can still differentiate with a different index number. But, a different name would be more intuitive for users. For example, if the first bus corresponds to the front and the second to the surround, the controls should be like "Front XXX" and "Surround XXX" rather than "PCM XXX" #0 and "PCM XXX" #1. If a control is not necesarily visible on mixer and bound to a PCM stream, it should have IFACE_PCM instead of IFACE_MIXER. You can set up such controls at the open hook in alsa-lib's configuration file. For example, the SPDIF status bits belongs to such one. You can use device and subdevice numbers in snd_ctl_elem_id to identify the binding to a PCM (sub)stream. > The main question that comes to mind is how I represent the multiple > busses. Each bus has an independant pair of DMA channels (playback and > capture). > > - should I instanciate a different card object for each bus or not ? > Busses _seem_ to be mostly independent, though I yet have to double > check if they have any kind of crossover clocking... > > - should I instanciate one card, but 2 PCM devices ? > > - should I instanciate one card and one PCM device but with 2 playback > and 2 capture substreams ? Well, it's pretty depending on the functionality of each i/o. IMO, the audio functions on the same board should be implemented in a single card instance. So, I prefer multiple PCMs on a single card. But it's up to you... > It _seems_ to me, but I may be wrong, that the later would mean that you > have N substreams getting in the same codec and beeing mixed, which > isn't the case. Right, multiple substreams are usually for h/w mixing since the empty substream slot is searched automatically as default. > My 2 i2s busses are wired to different codecs and thus > different inputs and outputs. However, it's not yet clear to me if both > busses always have both inputs and outputs... I _think_ that in some > models at least, one of the 2 busses is only used for digital input or > output, not sure, I'm still digging into darwin and machine device-trees > to try to write down a complete "map" of apple hw setup. OK. That's important to know which does really what :) > So if the above feeling is right, that would mean that I need either 2 > cards or 2 PCM devices, is that right ? Yes. I guess 2 PCM devices would be simplier. > Then, comes the various codec controls (volumes, mutes, ...)... I am > supposed to set them all to "MIXER" or should I in some way attach them > to the proper PCM on which the codec ? As menitioned, if the element is tightly bound to a PCM stream and not necessarily visible, it should be PCM iface type. > Another question that comes to mind is locking with external event... > things like input detection interrupts etc... Changing controls seem to > be trivially done with the snd_ctl_notify) interface, but what about > PCM settings ? For example, if you plug a digital input in, the driver > needs to change all it's internal clocking network and force it's PCM > settings to match the incoming signal. (In fact, it's not even yet clear > to me if I can have a digital input plugged _and_ output at a different > clock rate a different data yet, at least not if they are on the same > i2s bus, but some machine have separate busses so ...). In some cases, > that include changing the PCM format. The typical case where it has the > most impact on the driver is when inputing AC3... Ah, a good question. Unfortunately, the PCM setting is supposed to be constant during running, so far. That is, the essential state (e.g. PCM format, rate) must be determined in hw_params call. We may need extend in some fields (e.g. sample rate) to be variable during the operation in future... Takashi ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click