public inbox for alsa-devel@alsa-project.org
 help / color / mirror / Atom feed
From: David Henningsson <david.henningsson@canonical.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Takashi Iwai <tiwai@suse.de>,
	ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Kay Sievers <kay.sievers@vrfy.org>,
	Lennart Poettering <lennart@poettering.net>
Subject: Re: Jack event API - decision needed
Date: Tue, 28 Jun 2011 17:27:15 +0100	[thread overview]
Message-ID: <4E0A00E3.5000102@canonical.com> (raw)
In-Reply-To: <20110627120743.GA20707@sirena.org.uk>

On 2011-06-27 13:07, Mark Brown wrote:
> On Mon, Jun 20, 2011 at 03:37:25PM +0200, David Henningsson wrote:
>
>> 1) We're continuing the path with /dev/input devices
>
>> 2a) We'll rewrite these devices to be read-only ALSA mixer controls
>
>> 2b) We'll rewrite these devices to be something within ALSA, but not
>> exactly mixer controls.
>
>> For options 2a) and 2b) I guess the existing /dev/input thing should be
>> deprecated and/or removed. So part of decision should maybe be based on
>> information about how widespread the usage of these devices are
>> currently...?
>
> So, this discussion seems to have ground to a halt.

Yes, unfortunately, and without a clear consensus. That puts me in a 
difficult position, because I'm trying to get the job done. And very 
preferrable, in the next release of Ubuntu (which is to be released on 
October this year). I've been talking to a few of my colleagues here at 
Canonical, and here's how we reason currently:

We have the input layer. We also have a set of patches for supporting 
this in PulseAudio (although currently unmerged and I'm not sure about 
their current quality/state).
We don't have the alternative Alsa Control API discussed in this thread. 
Without taking a stance of whether that would be a better solution or 
not, designing it will take some time - somewhat depending on the set of 
problems we're aiming to solve. Regardless, it will definitely not reach 
the 3.0 kernel (which is what we will ship in the next release of Ubuntu).

As such, it makes the most sense for me to continue working on the 
existing input layer API for the time being. If or when a new API is 
announced and finished, rewriting the pulseaudio patches to target that 
API will probably make sense. But we're not there today, and the time 
schedule for getting there is unknown.

If upstream udev/PulseAudio would be willing to merge my (existing and 
upcoming) patches, I would appreciate that, as I believe that would make 
both our lives easier. If not, well at least make a note that I /tried/ 
to do things the right way, and to make everybody happy - which is not 
always possible.

-- 
David Henningsson
http://launchpad.net/~diwic

  parent reply	other threads:[~2011-06-28 16:27 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-20 13:37 Jack event API - decision needed David Henningsson
2011-06-20 17:07 ` Mark Brown
2011-06-20 17:12   ` Takashi Iwai
2011-06-20 17:31     ` Mark Brown
2011-06-20 17:37       ` Takashi Iwai
2011-06-20 18:53   ` David Henningsson
2011-06-20 23:40     ` Mark Brown
2011-06-21 12:11       ` David Henningsson
2011-06-21 12:39         ` Mark Brown
2011-06-22 10:47           ` David Henningsson
2011-06-22 11:48             ` Mark Brown
2011-06-22 12:50               ` Kay Sievers
2011-06-22 13:25                 ` Mark Brown
2011-06-22 13:55                   ` Kay Sievers
2011-06-22 15:11                     ` Mark Brown
2011-06-22 21:41                       ` Dmitry Torokhov
2011-06-23  0:15                         ` Mark Brown
2011-06-23  8:42                           ` Dmitry Torokhov
2011-06-23 10:47                             ` Mark Brown
2011-06-22 21:01                   ` Lennart Poettering
2011-06-22 21:57                     ` Stephen Warren
2011-06-23  1:10                     ` Mark Brown
2011-06-23  7:01                       ` Clemens Ladisch
2011-06-23  7:24                         ` Takashi Iwai
2011-06-23  9:49                       ` Lennart Poettering
2011-06-23 11:43                         ` Mark Brown
2011-06-23 15:32                         ` Stephen Warren
2011-06-27 12:07 ` Mark Brown
2011-06-27 17:01   ` Colin Guthrie
2011-06-28 16:20     ` Mark Brown
2011-07-09  3:38     ` Mark Brown
2011-06-28 16:27   ` David Henningsson [this message]
2011-06-28 16:34     ` Liam Girdwood
2011-06-28 16:35     ` Mark Brown
2011-06-28 16:35     ` Takashi Iwai
2011-06-29  2:59       ` Mark Brown
2011-06-29  5:34         ` Takashi Iwai
2011-06-29  6:59           ` Mark Brown
2011-06-29  7:03             ` Takashi Iwai
2011-06-29  7:13       ` David Henningsson
2011-06-29  7:21         ` Mark Brown
2011-06-29  8:52           ` David Henningsson
2011-06-29 17:00             ` Mark Brown
  -- strict thread matches above, loose matches on Subject: below --
2011-06-20 13:56 Mark Brown
2011-06-20 14:11 ` David Henningsson
2011-06-20 14:19 ` Kay Sievers
2011-06-20 15:35   ` Takashi Iwai
2011-06-20 16:52     ` Mark Brown
2011-06-20 17:01       ` Takashi Iwai
2011-06-20 18:24     ` David Henningsson
2011-06-21  0:29       ` Mark Brown
2011-06-21  6:57         ` David Henningsson
2011-06-21 10:40           ` Mark Brown
2011-06-20 16:47   ` Mark Brown
2011-06-20 16:59     ` Takashi Iwai
2011-06-20 17:17       ` Mark Brown
2011-06-20 17:38         ` Takashi Iwai

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=4E0A00E3.5000102@canonical.com \
    --to=david.henningsson@canonical.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=kay.sievers@vrfy.org \
    --cc=lennart@poettering.net \
    --cc=tiwai@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox