On Tue, 2014-02-18 at 21:26 +0530, Arun Raghavan wrote: > On 17 February 2014 23:47, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote: > > On Mon, 2014-02-17 at 12:46 +0200, Tanu Kaskinen wrote: > >> On Mon, 2014-02-17 at 16:06 +0530, Arun Raghavan wrote: > >> > > I'm not completely clear what you're trying to achieve with volume > >> > > control objects right now - are you just trying to fix the balance > >> > > problem, or ...? I see the point you're making about the potential > >> > > applicability of associating multiple volume controls with a single > >> > > device, but I'd like to understand what you'll be solving with the > >> > > patch set you'd be submitting with this infrastructure. > > > > <snip> > > > >> Out of curiosity, what do you mean by "associating multiple volume > >> controls with a single device"? I don't remember mentioning multiple > >> volume controls per device, unless you mean the idea of having a debug > >> mode with access to alsa mixer volume elements etc. > > > > Never mind, I now realized that you probably referred to the N9 volume > > model, where each output device has two volumes: "call" and "everything > > else". > > I'd have thought that would be handled by volume classes, but perhaps > I'm not following what the N9 is doing. Ok, then I'll ask again: what did you mean by "associating multiple volume controls with a single device"? As for the N9 setup: there are two volume classes: "call" and "other". There are 2 * n_output_devices volume controls, one for each combination of a volume class and an output device. -- Tanu
