[lkml]   [2010]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
> Hi Clemens,
> On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote:
>> I wrote:
>> > I'll see if I can draw up the ALSA-specific media stuff over the
>> weekend.
>> Sorry, wrong weekend.
>> Anyway, below are some remarks and a patch.
> Thank you. Please see my comments inline.
>> * Entity types
>> TYPE_NODE was renamed to TYPE_DEVICE because "node" sounds like a node
>> in a graph, which does not distinguish it from other entity types
>> because all entities are part of the topology graph. I chose "device"
>> as this type describes entities that are visible as some device node to
>> other software.
> What this type describes is a device node. Both NODE and DEVICE can be
> confusing in my opinion, but DEVICE_NODE is a bit long.

What about DEVNODE? I think that would be a good alternative.

>> TYPE_EXT describes entities that represent some interface to the
>> external world, TYPE_INT those that are internal to the entire device.
>> (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems
>> to be an even more meaningless name.)
> SUBDEV comes from the V4L2 world, and I agree that it might not be a very
> good
> name.

SUBDEV refers to a specific type of driver. Within the v4l world it is
well defined. So I prefer to keep this. Perhaps some additional comments
or documentation can be added to clarify this.

> I'm not sure I would split entities in internal/external categories. I
> would
> create a category for connectors though.

I agree. It was always the plan to eventually add connectors, but v4l
didn't really need it (it already has an API to enumerate connectors).

>> ALSA mixer controls are not directly represented; a better fit for the
>> architecture of actual devices is that one or more mixer controls can be
>> associated with an entity. (This can be done with a field of the mixer
>> control.)
> Agreed.
>> * Entity properties
>> There needs to be a mechanism to associate meta-information (properties)
>> with entities. This information should be optional and extensible, but,
>> when being handled inside the kernel, doesn't need to be more than
>> a read-only blob. I think that something like ALSA's TLV format (used
>> for mixer controls) can be used here. (I'm not mentioning the X-word
>> here, except to note that the "M" stands for "markup".)
> I've been thinking of adding a new ioctl for that. It's something we need
> to
> draft. The UVC driver will need it, and I'm pretty sure other V4L2 drivers
> would find it useful as well.
>> * Entity subtypes
>> EXT_JACK_ANALOG represents any analog audio and/or video connector.
>> Properties for audio jacks would be jack type (TRS/RCA), color code,
>> line level, position, etc.
>> EXT_JACK_DIGITAL represents a digital connector like S/PDIF (coax/
>> EXT_JACK_BUS represents a bus like FireWire and comes from the USB audio
>> spec. (I doubt that any devices with this entitiy will ever exist.)
>> EXT_INSTRUMENT represents something like an e-guitar, keyboard, or MIDI
>> controller. (Instrument entities are typically audio sources and MIDI
>> sources and sinks, but can also be audio sinks.)
>> EXT_SPEAKER also includes headphones; there might be made a case for
>> having those as a separate subtype.
> Shouldn't headphones be represented by an EXT_JACK_ANALOG ?
>> EXT_PLAYER represents a device like a CD/DVD/tape player. Recorders can
>> also write to that device, so "player" might not be an ideal name.
>> EXT_BROADCAST represents devices like TV tuners, satellite receivers,
>> cable tuners, or radios.

I don't think it is right to talk about 'represents devices'. I'd rephrase
it to 'connects to devices'.

> There's clearly an overlap with V4L here. Hopefully someone from the
> linux-
> media list can comment on this.

I don't think this will be a problem. Initially we probably won't be
enumerating connectors for V4L since it already has its own API for that.

>> INT_SYNTHESIZER converts MIDI to audio.
>> INT_NOISE_SOURCE comes from the USB audio spec; this is not an attempt
>> to describe the characteristics of consumer-grade devices :-) , but
>> represents an internal noise source for level calibration or
>> measurements.
>> INT_CONTROLS may have multiple independent controls (this is USB's
>> Feature Unit); INT_EFFECT may have multiple controls that affect one
>> single algorithm.
> I'd describe this as a feature unit/processing unit then.
>> INT_CHANNEL_SPLIT/MERGE are needed for HDAudio devices, whose topology
>> information has only stereo links.
> Some of those INT entities could also be implemented in dedicated chips,
> so I
> really think the EXT/INT split doesn't make too much sense. Should we have
> an
> AUDIO category ?
>> * Entity specifications
>> While TYPE_DEVICE entities can be identified by their device node, other
>> entities typcially have just a numeric ID.
> In V4L2 sub-devices have (or rather will have once the media controller
> patches will be integrated) device nodes as well, so exposing that
> information
> is required.
>> For that, it would be useful to make do without separate identification
>> and
>> let the driver choose the entity ID.
> How would drivers do that ? What if you have two instances of the same
> chip (a
> video sensor, audio mixer, ...) on the same board ?



Hans Verkuil - video4linux developer - sponsored by Cisco

 \ /
  Last update: 2010-12-14 13:43    [W:0.106 / U:2.580 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site