Hi Mark,
On Thursday 25 November 2010 14:41:35 Mark Brown wrote:
On Thu, Nov 25, 2010 at 10:38:05AM +0100, Clemens Ladisch wrote:
In USB and HD audio devices, all links are immutable, and the routing is controlled by 'selector' entities that activate exactly one of their input pads. In userspace, this entity shows up as a mixer control. I guess it would be possible to map the ACTIVE flag onto these controls.
Ditto for ASoC, mostly.
Alternatively, entities can have 'mute' mixer controls associated with their pads. In this case, multiple unmuted inputs would be mixed together.
ALSA has PCM and MIDI devices, and several types of mixer controls. (It also has hardware dependent and timer devices, but I don't think
these would need topology information.) So we need at least these: MEDIA_ENTITY_TYPE_NODE_ALSA_PCM MEDIA_ENTITY_TYPE_NODE_ALSA_MIDI MEDIA_ENTITY_TYPE_SUBDEV_ALSA_CONTROL
Furthermore, topology information is also needed for entities not associated with a mixer control, such as microphones, speakers, jacks/ connectors, and effect units. These entities are defined in the USB and HD audio specifications, but are not yet handled by ALSA.
All this and more in the embedded case - digital audio link nodes and DSP I/O nodes (could possibly do those as digital audio ones) spring to mind. Also bear in mind that embedded devices can get *very* large - a mobile phone audio system can have of the order of 100 nodes in the graph.
It depends on how you define nodes. I can certainly imagine a graph with 100 controls, but maybe several controls can be part of the same node ? On the video side we've decided to split entities depending on the possible data paths configurations. As I'm not a fluent ascii-art speaker, please have a look at pages 4 and 5 of http://www.ideasonboard.org/media/20101103-lpc- media.pdf
Page 4 shows the internal topology of the OMAP3 ISP. The major blocks in that diagram are reported as entities. Page 5 shows the internal topology of one of the blocks, the OMAP3 ISP preview engine. As you can see the pipeline is made of sub-blocks that implement a single image processing function. As the pipeline is linear (don't worry about the non-linear part in the beginning, it's just there to take into account link configurability at the higher level) we don't export all the sub-blocks as entities, but we expose the controls on the preview engine entity instead.
ALSA devices are not addressed by their device node but with card/device/
subdevice numbers; mixer controls have numeric IDs, unique per card: struct { int card; int device; int subdevice; } alsa_device; struct { int card; int numid; } alsa_control;
For the embedded stuff we also have a bunch of stuff in the graph which may not be visible to userspace at all at present and would just have a string based identifier.
That could be easily added (provided the string is not too long).