Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Hans,
On Tuesday 14 December 2010 13:40:21 Hans Verkuil wrote:
On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote:
- 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.
Fine with me. Clemens, any opinion on that ?
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.
Should this be clarified by using V4L2_SUBDEV instead then ? What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ?
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/ TOSLINK), ADAT, TDIF, or MADI.
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.
My understanding is that EXT_BROADCAST really represents the TV tuners, ..., not the connector they connect to. Some (all ?) of them are definitely V4L2 subdevs.
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 ?
Laurent Pinchart wrote:
On Tuesday 14 December 2010 13:40:21 Hans Verkuil wrote:
On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote:
- 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.
Fine with me. Clemens, any opinion on that ?
Fine with me too.
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.
Should this be clarified by using V4L2_SUBDEV instead then ?
If the "SUBDEV" concept doesn't exist outside V4L, that would indeed be better.
I don't want to rename things that come out of existing frameworks; this naming discussion makes sense only for those entity (sub)types that can be shared between them. Are there any, besides jacks?
What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ?
The entity types representing ALSA devices are already named "ALSA".
Regards, Clemens
Hi Clemens,
On Tuesday 14 December 2010 14:49:15 Clemens Ladisch wrote:
Laurent Pinchart wrote:
On Tuesday 14 December 2010 13:40:21 Hans Verkuil wrote:
On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote:
- 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.
Fine with me. Clemens, any opinion on that ?
Fine with me too.
OK I'll use that name.
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.
Should this be clarified by using V4L2_SUBDEV instead then ?
If the "SUBDEV" concept doesn't exist outside V4L, that would indeed be better.
I don't want to rename things that come out of existing frameworks; this naming discussion makes sense only for those entity (sub)types that can be shared between them. Are there any, besides jacks?
Some entities like TV tuners play a dual audio/video role. I'm not sure how to handle them, I lack experience in that field.
What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ?
The entity types representing ALSA devices are already named "ALSA".
I was talking about the INT_* types. They're ALSA-specific, but have no ALSA in the type name.
On Wednesday, December 15, 2010 00:50:44 Laurent Pinchart wrote:
Hi Clemens,
On Tuesday 14 December 2010 14:49:15 Clemens Ladisch wrote:
Laurent Pinchart wrote:
On Tuesday 14 December 2010 13:40:21 Hans Verkuil wrote:
On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote:
- 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.
Fine with me. Clemens, any opinion on that ?
Fine with me too.
OK I'll use that name.
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.
Should this be clarified by using V4L2_SUBDEV instead then ?
If the "SUBDEV" concept doesn't exist outside V4L, that would indeed be better.
I don't want to rename things that come out of existing frameworks; this naming discussion makes sense only for those entity (sub)types that can be shared between them. Are there any, besides jacks?
Some entities like TV tuners play a dual audio/video role. I'm not sure how to handle them, I lack experience in that field.
It is very important to distinguish between the actual tuner device and the physical connector. ALSA doesn't program a tuner device, that's the domain of V4L and DVB. ALSA just sees an input pin.
Regarding tuners there are roughly two types of hardware: one where the audio goes to an output jack (and the user has to use a loopback cable to hook it up to an audio input), or it goes to memory using DMA and an ALSA driver.
In the first scenario the MC would model a TV_ANTENNA connector and an AUDIO_OUT connector. The TV_ANTENNA connector would typically link to a V4L2_SUBDEV_TUNER, which would link to a V4L2_SUBDEV_AUDIO_DEMOD (in turn linked to the AUDIO_OUT connector). The tuner would also link to a V4L2_SUBDEV_VIDEO_DIGITIZER (in turn linked to a DEVNODE_V4L).
In the second scenario there is no AUDIO_OUT connector, instead there is a DEVNODE_ALSA.
It can get more complex: in the case of MPEG encoders the audio from the tuner goes to an audio demod, the video goes to a digitizer, and the output of those subdevs both go into the same MPEG encoder subdev.
When modeling hardware like audio or video devices it is important to remember to separate I/O pins from actually physical connectors. E.g. an audio device may have many possible input pins, but how they are hooked up to which physical connectors is something that is board specific and not part of the audio driver itself.
Anyway, what we need is a 'connector' entity. And just like the other entities, connectors can have multiple input pads so I don't see any problems in modeling antenna connectors.
Regards,
Hans
What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ?
The entity types representing ALSA devices are already named "ALSA".
I was talking about the INT_* types. They're ALSA-specific, but have no ALSA in the type name.
participants (3)
-
Clemens Ladisch -
Hans Verkuil -
Laurent Pinchart