Re: Some questions about userspace control elements

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

Hi Clemens,

On Feb 6 2015 18:38, Clemens Ladisch wrote:
> Takashi Sakamoto wrote:
>> On Feb 5 2015 08:51, Takashi Sakamoto wrote:
>>> sound/core/control.c:1188
>>> {{{
>>> kctl.count = info->owner ? info->owner : 1;
>>> }}}
>>>
>>> In this code, the value in struct snd_ctl_elem_info.owner is assigned to
>>> struct snd_kcontrol.count. The meaning of these two member is completely
>>> different but assigned.
> 
> There is hardware that has many identhtical controls.  To save memory,
> ALSA treats controls with .count > 1 as if there were multiple controls.
>
> This optimization is not visible in the userspace API.

In my understanding, it's due to the granularity of operation. If we
assume a PCI device has one register to express several control elements
as bitfield. One read or write operation can handle these controls. Such
control elements can be expressed in one ALSA control substance.

> The owner field is used because there is no other field to set the
> count.

No. In SNDRV_CTL_IOCTL_ELEM_ADD ioctl, struct snd_ctl_elem_info.count
has the number of elements in this control, there it's an abuse of
member unrelated to the count.

>> When any userspace control element are added, the value of struct
>> snd_ctl_elem_info.owner is zero because there's no API to set this
>> member in userspace
> 
> So far, setting this field has not been needed.  An API could be added.

I cannot find the advantage to add such API in userspace. The value of
owner field SHOULD be set just by lock/unlock API.

>>> I guess that the reason is to limit the number of event generated when
>>> the control element set is operated.
> 
> If a driver needs twenty identical controls, it could create one control
> with count=20, or twenty controls with count=1.  In both cases, twenty
> events are sent.

But this is not applied to userspace controls because a control with 20
elements can generate one events instead of 20.

This is ugly because it demands userspace applications to distinguish
kernel/userspace application in event handling.


Thanks

Takashi Sakamoto