lkml.org 
[lkml]   [2010]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC/PATCH v6 03/12] [alsa-devel] media: Entities, pads and links
Date
Hi Clemens,

Thanks a lot for the review.

On Thursday 25 November 2010 10:38:05 Clemens Ladisch wrote:
> Laurent Pinchart wrote:
> > A link is a point-to-point oriented connection between two pads, either
> > on the same entity or on different entities. Data flows from a source
> > pad to a sink pad.
> >
> > Links are stored in the source entity.
>
> In the descriptors of USB Audio and HDAudio devices, the links are
> stored only in the sink. But AFAICS this doesn't matter in the media
> driver API.

Same for USB Video (UVC). The reason for that is that UAC and UVC have only 1-
to-many connections (same for the media controller by the way), and it's
easier to store that information in fixed-size structures if you store it in
the sink entities.

On the kernel side, the media controller stores links in both source and sink
entities for internal reasons. Links stored in the sink entity are called
backlinks.

On the userspace side applications will only see "forward" links, stored in
source entities. Applications will of course be free to store the links
whereever they want in their internal data structures.

As you mentioned, I think it doesn't matter much anyway.

> > +Links have flags that describe the link capabilities and state.
> > +
> > + MEDIA_LINK_FLAG_ACTIVE indicates that the link is active and can be
> > + used to transfer media data. When two or more links target a sink pad,
> > + only one of them can be active at a time.
> > + MEDIA_LINK_FLAG_IMMUTABLE indicates that the link active state can't
> > + be modified at runtime. If MEDIA_LINK_FLAG_IMMUTABLE is set, then
> > + MEDIA_LINK_FLAG_ACTIVE must also be set since an immutable link is
> > + always active.
>
> So the intended userspace API for controlling routing is to change the
> ACTIVE flag of links?

That's correct.

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

Same for UVC once again. It would be quite easy to map selector units to link
activation, but it doesn't even have to be done. We could keep the selector
units in the graph with all links immutable, and use the existing APIs to
control the selector units.

The alternative would have been to add selector units to the media controller.
I've thought about it, but we have embedded hardware (at least on the video
side) that have configurable links without selector units. The media
controller would have had to create fake selector units.

Between creating fake selector and translating link activation to selector
unit commands, I've decided to go for the second solution, as this will make
the graph simpler. Once again we can decide to keep explicit selector units in
the graph for UVC, UAC and HD audio devices. That's one I've done in a test
implementation of the media controller API in the uvcvideo driver.

> Alternatively, entities can have 'mute' mixer controls associated with
> their pads. In this case, multiple unmuted inputs would be mixed
> together.

I don't see any problem keeping those.

> > +#define MEDIA_ENTITY_TYPE_MASK 0x00ff0000
> > +#define MEDIA_ENTITY_SUBTYPE_MASK 0x0000ffff
> > +
> > +#define MEDIA_ENTITY_TYPE_NODE (1 <<
> > MEDIA_ENTITY_TYPE_SHIFT) ...
> > +#define MEDIA_ENTITY_TYPE_NODE_ALSA (MEDIA_ENTITY_TYPE_NODE +
> > 3)
>
> 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

I agree about PCM and MIDI, but I'm not sure about controls. If controls are
part of an entity, the entity will be reported through the media controller
API. If information about that entity can be queried through existing APIs
(ALSA, V4L, ...) those APIs should be used. For instance, on the V4L side,
V4L2 sub-devices are mapped to entities and also have a device node which can
be used to enumerate the controls supported by the subdev. The media
controller only reports the entity -> major:minor mapping to let applications
find the device and query it directly.

I think we will need a new ioctl in the media controller API to report
advanced information about an entity. This could be used to report controls
implemented by an ALSA element if ALSA doesn't provide a way to do that
directly. Another use case, which make me think that such an ioctl would be
needed, is to report UVC extension units type (16-byte GUID) to userspace.

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

Agreed, we will need to add new entity types and subtypes for those. The
reason they're not part of this submission is that I wanted real use cases
instead of coming up with a made-up list of entities I think would be useful.

> > +struct media_entity {
> > ...
> > + union {
> > + /* Node specifications */
> > + struct {
> > + u32 major;
> > + u32 minor;
> > + } v4l;
> > + struct {
> > + u32 major;
> > + u32 minor;
> > + } fb;
> > + int alsa;
> > + int dvb;
> > +
> > + /* Sub-device specifications */
> > + /* Nothing needed yet */
> > + };
>
> 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;

I will use this instead of 'int alsa'. Thanks a lot for the useful feedback.

> struct {
> int card;
> int numid;
> } alsa_control;

Regarding controls, let's first see how they should be reported by userspace,
as explained above.

--
Regards,

Laurent Pinchart


\
 
 \ /
  Last update: 2010-11-25 16:23    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site