All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Some questions about userspace control elements
Date: Sun, 01 Feb 2015 20:41:06 +0900	[thread overview]
Message-ID: <54CE10D2.7090903@sakamocchi.jp> (raw)

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

             reply	other threads:[~2015-02-01 11:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-01 11:41 Takashi Sakamoto [this message]
2015-02-01 17:50 ` Some questions about userspace control elements Clemens Ladisch
2015-02-02 14:14   ` Takashi Sakamoto
2015-02-04 23:51   ` Takashi Sakamoto
2015-02-05  0:44     ` Takashi Sakamoto
2015-02-06  9:38       ` Clemens Ladisch
2015-02-07  1:58         ` Takashi Sakamoto
2015-02-07 15:45           ` Clemens Ladisch
2015-02-08 10:57             ` Takashi Sakamoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54CE10D2.7090903@sakamocchi.jp \
    --to=o-takashi@sakamocchi.jp \
    --cc=alsa-devel@alsa-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.