* Re: Alsa questions
2006-01-15 23:23 Alsa questions Benjamin Herrenschmidt
@ 2006-01-16 15:23 ` Takashi Iwai
0 siblings, 0 replies; 2+ messages in thread
From: Takashi Iwai @ 2006-01-16 15:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 2+ messages in thread