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). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
