[lkml]   [2010]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC/PATCH v6 03/12] [alsa-devel] media: Entities, pads and links
    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:
    > >
    > > 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

    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).


    Laurent Pinchart

     \ /
      Last update: 2010-11-25 16:31    [W:0.023 / U:0.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site