Some questions about userspace control elements

Some questions about userspace control elements

[Takashi Sakamoto]

Dear all,

I have some questions about ALSA control interface.

Currently I'm working for writing control applications in userspace. The
application adds some control elements to a certain control device, then
execute interprocess communication via the device by ALSA control interface.

To help this work, I'm preparing for alsa-gir, with partly implementation of
ALSA Control/Timer/Sequencer interface.
(Currently I have no plan to support the other interfaces, such as PCM.)

https://github.com/takaswie/alsa-gir

Then I have six questions.

1.The 'numid' is unique number for each element or not.
2.The 'numid' is always zero in SND_CTL_EVENT_MASK_ADD event.
3.The way to change permissions of each control element.
4.Added elements are not removed when closing fd.
5.Processes can delete elements which the other processes added.
6.The operation to replace element generates separate events.

In detail:
1.The 'numid' is unique number for each element or not?
I want to use it to indicate each element, if possible. But there're
more members in snd_ctl_elem_id structure.

2.The 'numid' can be notified in SND_CTL_EVENT_MASK_ADD event?
As long as I test, it's always zero when userspace applications add any
elements. Is it an expected behaviour? Or a bug?

3.The way to change permissions of each control element.
Is it possible after adding the elements? If possible, how to notify it
in the other processes?

4.Any elements added by a process are not removed at closing snd_ctl_t.
They're remained after closing the process' snd_ctl_t. Is it an expected
behaviour? Or a bug?

5.Processes can delete elements which the other processes added.
Is it an expected behaviour? Or a bug?

6.The operation to replace elements generates separate events.
ADD/REMOVE events occurs sequencially. Userspace application cannot
distinguish replacement from adding/removing, therefore cannot process
appropriate action. Is it an expected behaviour? Or a bug?


Regards

Takashi Sakamoto

Re: Some questions about userspace control elements

[Clemens Ladisch]

Takashi Sakamoto wrote:
> 1.The 'numid' is unique number for each element or not?
> I want to use it to indicate each element, if possible. But there're
> more members in snd_ctl_elem_id structure.

The other members help with searching elements.  But numid itself must
be unique.

> 2.The 'numid' can be notified in SND_CTL_EVENT_MASK_ADD event?
> As long as I test, it's always zero when userspace applications add any
> elements. Is it an expected behaviour? Or a bug?

This looks like a bug in the kernel code.

All the other members of the id structure should be correct; as
a workaround, try calling snd_ctl_elem_info().

> 3.The way to change permissions of each control element.
> Is it possible after adding the elements? If possible, how to notify it
> in the other processes?

At the moment, this is not possible for userspace controls.

What bit(s) do you want to change?

> 4.Any elements added by a process are not removed at closing snd_ctl_t.
> They're remained after closing the process' snd_ctl_t. Is it an expected
> behaviour? Or a bug?

This is by design.  These controls are intended to be a property of the
device itself, and to be somewhat permanent.

> 5.Processes can delete elements which the other processes added.
> Is it an expected behaviour? Or a bug?

For permanent controls, it would not be possible to remember which
process created them originally.

> 6.The operation to replace elements generates separate events.
> ADD/REMOVE events occurs sequencially. Userspace application cannot
> distinguish replacement from adding/removing, therefore cannot process
> appropriate action. Is it an expected behaviour? Or a bug?

Replacement is just a shortcut for removing/adding.  So far, changing
the properties of userspace controls has not been necessary.


Regards,
Clemens

Re: Some questions about userspace control elements

[Takashi Sakamoto]

Hi Clemens,

Thanks for your answer. I want to discuss about the design of ALSA
userspace controls with you, while today I've read some related kernel
codes and realized they're more buggy than I expected...perhaps. I'd
like to start discussion after fixing them.


Thanks

Takashi Sakamoto

On Feb 2 2015 02:50, Clemens Ladisch wrote:
> Takashi Sakamoto wrote:
>> 1.The 'numid' is unique number for each element or not?
>> I want to use it to indicate each element, if possible. But there're
>> more members in snd_ctl_elem_id structure.
> 
> The other members help with searching elements.  But numid itself must
> be unique.
> 
>> 2.The 'numid' can be notified in SND_CTL_EVENT_MASK_ADD event?
>> As long as I test, it's always zero when userspace applications add any
>> elements. Is it an expected behaviour? Or a bug?
> 
> This looks like a bug in the kernel code.
> 
> All the other members of the id structure should be correct; as
> a workaround, try calling snd_ctl_elem_info().
> 
>> 3.The way to change permissions of each control element.
>> Is it possible after adding the elements? If possible, how to notify it
>> in the other processes?
> 
> At the moment, this is not possible for userspace controls.
> 
> What bit(s) do you want to change?
> 
>> 4.Any elements added by a process are not removed at closing snd_ctl_t.
>> They're remained after closing the process' snd_ctl_t. Is it an expected
>> behaviour? Or a bug?
> 
> This is by design.  These controls are intended to be a property of the
> device itself, and to be somewhat permanent.
> 
>> 5.Processes can delete elements which the other processes added.
>> Is it an expected behaviour? Or a bug?
> 
> For permanent controls, it would not be possible to remember which
> process created them originally.
> 
>> 6.The operation to replace elements generates separate events.
>> ADD/REMOVE events occurs sequencially. Userspace application cannot
>> distinguish replacement from adding/removing, therefore cannot process
>> appropriate action. Is it an expected behaviour? Or a bug?
> 
> Replacement is just a shortcut for removing/adding.  So far, changing
> the properties of userspace controls has not been necessary.
> 
> 
> Regards,
> Clemens

Re: Some questions about userspace control elements

[Takashi Sakamoto]

Hi Clemens,

I find a curious issue about the userspace element. Could I ask you to
give some comments about

The code is this one line.

sound/core/control.c:1188
{{{
kctl.count = info->owner ? info->owner : 1;
}}}
http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/core/control.c?id=6ccd93bdb989507717edb375d40534f1177822c5#n1188

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.

include/sound/control.h:67
{{{
struct snd_kcontrol {
...
unsigned int count;
...
};
}}}
http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/include/sound/control.h?id=6ccd93bdb989507717edb375d40534f1177822c5#n67

include/uapi/sound/asound.h:851
{{{
struct snd_ctl_elem_info {
...
__kernel_pid_t owner;		/* owner's PID of this control */
...
};
};
}}}
http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/include/uapi/sound/asound.h?id=6ccd93bdb989507717edb375d40534f1177822c5#n851
(I wonder why the value with _kernel_pid type is exported to userspace...)

I guess that the reason is to limit the number of event generated when
the control element set is operated. Actually, my sample code reports
one event every time when operating the control element with 10 entries.
But I believe this is the different behaviour as the kernel control
elements do.

sound/core/control.c:257
{{{
kctl.count = ncontrol->count ? ncontrol->count : 1;
}}}
http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/core/control.c?id=6ccd93bdb989507717edb375d40534f1177822c5#n257

For me, the behaviour of userspace control element is a bit strange. The
behaviour is legal as a control element?


Regards

Takashi Sakamoto

Re: Some questions about userspace control elements

[Takashi Sakamoto]

I want to add some supplement to my previous message.
(sorry to include some logic jump...)

On Feb 5 2015 08:51, Takashi Sakamoto wrote:
> The code is this one line.
>
> sound/core/control.c:1188
> {{{
> kctl.count = info->owner ? info->owner : 1;
> }}}
> http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/core/control.c?id=6ccd93bdb989507717edb375d40534f1177822c5#n1188
>
> 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.

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 and snd_ctl_elem_info_alloca() or 
snd_ctl_elem_info_malloc() initialize allocated memory with zero.

Then, 1 is always assigned to the kctl.count.

> I guess that the reason is to limit the number of event generated when
> the control element set is operated. Actually, my sample code reports
> one event every time when operating the control element with 10 entries.
> But I believe this is the different behaviour as the kernel control
> elements do.

For example, 'add' event is generated in sound/core/contro.c:378. This 
event is generated several times as the number of count:
http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/core/control.c?id=6ccd93bdb989507717edb375d40534f1177822c5#n376

Due to kctl.count is assigned to 1, the number of generated event for 
userspace control elements is one time.

> sound/core/control.c:257
> {{{
> kctl.count = ncontrol->count ? ncontrol->count : 1;
> }}}
> http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/core/control.c?id=6ccd93bdb989507717edb375d40534f1177822c5#n257
>
> For me, the behaviour of userspace control element is a bit strange. The
> behaviour is legal as a control element?

On the other hand, in kernel control element, kctl.count is assigned to 
the value which each driver gives. Therefore, the number of generated 
events is the same as the number of element count.

In these reasons, the number of generated events is different between 
kernel/userspace control element.

Actually, there's a few kernel control elements in which the number of 
count is bigger than 1. So in most case, users cannot realize the 
differences to use ALSA control application such as alsamixer. The 
behaviour of userspace control elements looks like kernel control 
elements which major sound drivers give.

Please inform to me if my understanding is wrong.


Regards

Takashi Sakamoto

Re: Some questions about userspace control elements

[Clemens Ladisch]

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

The owner field is used because there is no other field to set 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 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.


Regards,
Clemens

Re: Some questions about userspace control elements

[Takashi Sakamoto]

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

Re: Some questions about userspace control elements

[Clemens Ladisch]

Takashi Sakamoto wrote:
> On Feb 6 2015 18:38, Clemens Ladisch wrote:
>> 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.

That is a different count.

struct snd_ctl_elem_info.count allows a control to have multiple values.
For example, a stereo volume control has two values.

kctl.count creates multiple controls.


Regards,
Clemens

Re: Some questions about userspace control elements

[Takashi Sakamoto]

On Feb 8 2014 00:45, Clemens Ladisch wrote:
> Takashi Sakamoto wrote:
>> On Feb 6 2015 18:38, Clemens Ladisch wrote:
>>> 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.
> 
> That is a different count.
> 
> struct snd_ctl_elem_info.count allows a control to have multiple values.
> For example, a stereo volume control has two values.
> 
> kctl.count creates multiple controls.

Oh, I confused these two 'count's... I'm OK that the count member in
struct snd_kcontrol means the number of controls (elements) with the
same type, and the count member in struct snd_ctl_elem_info means the
number of values in a controls, then the event occurs every controls,
not for values.


Thanks

Takashi Sakamoto