Alsa-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Jaroslav Kysela <perex@perex.cz>
To: Tanu Kaskinen <tanuk@iki.fi>, alsa-devel <alsa-devel@alsa-project.org>
Subject: Re: [alsa-devel] Question about the various mixer options in UCM
Date: Sat, 15 Feb 2020 17:25:22 +0100
Message-ID: <cb58008e-e9cc-8390-cfc8-c5c93d31c862@perex.cz> (raw)
In-Reply-To: <50ae39498982ba2fc3fc8df1b9f0eac15a2b98c8.camel@iki.fi>

Dne 15. 02. 20 v 7:29 Tanu Kaskinen napsal(a):
> What's the difference between PlaybackVolume, PlaybackMixerElem and
> PlaybackMasterElem? Other than the obvious difference that
> PlaybackVolume is used only to configure the volume control, whereas
> PlaybackMixerElem and PlaybackMasterElem are used also to configure the
> mute control.

At first, I don't really know if someone uses PlaybackVolume/PlaybackSwitch. 
It was defined for the direct control interface (not the mixer interface). I 
do not think that we should support this.

I defined new PlaybackMixerElem to select the simple mixer element which 
controls both volume and switch (mute) in the ALSA API. The master volume 
might be also in the chain (thus PlaybackMasterElem) was introduced.

It seems that it might be not enough and I play with an idea to build custom 
mixer description to handle the special cases (like several speakers with the 
different volume controls connected to the single stereo stream etc.).

To keep things simple, I would probably hide all functionality to 
PlaybackMixer/PlaybackMixerElem and CaptureMixer/CaptureMixerElem . The 
special mixer name will create the abstract mixer for the applications and 
only one simple mixer element control will set the appropriate volume for
the stream (like pulseaudio actually does for the legacy ALSA support - volume 
synthetizer). So UCM will describe the mixer for alsa-lib and application will 
use only abstract interface to set / get the volume and mute state.

Actually, I am also trying to resolve the description of the speaker 
configuration. It may not be only enough to give the PCM device, because we 
don't know, if user connected the stereo or surround speakers to the sound 
card output for example. I play with an idea to add device variants to UCM, 
but the question is, how we can map this to pulseaudio profile/port schematics.

My quick idea is to export those variants via the verbs, so the exported verb 
names might look like:

HiFi:Speaker-Stereo
HiFi:Speaker-5.1

Where 'HiFi' is the verb name, 'Speaker' is the device name and 'Stereo' is 
the variant name.

If we need to define multiple variants, all may be exported like:

HiFi:Speaker-5.1,Mic-4.0

Also, we can enhance this and store the configuration to a file, thus 'HiFi' 
can refer to 'HiFi@Speaker-5.1,Mic-4.0' by default.

I welcome any opinions on this. The goal is to provide the complete abstract 
description of the sound hardware for sound servers like pulseaudio. We can 
use this abstraction for the command line ALSA applications, too.

				Thanks,
					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-15  6:29 Tanu Kaskinen
2020-02-15 16:25 ` Jaroslav Kysela [this message]
2020-02-16  9:42   ` Tanu Kaskinen
2020-02-16 10:06     ` [alsa-devel] [pulseaudio-discuss] " Tanu Kaskinen
2020-02-16 17:38       ` Jaroslav Kysela
2020-02-22  6:53         ` [pulseaudio-discuss] [alsa-devel] " Tanu Kaskinen
2020-02-23  9:00           ` Tanu Kaskinen
2020-02-23 13:55             ` Jaroslav Kysela
2020-02-26  8:05               ` Tanu Kaskinen

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=cb58008e-e9cc-8390-cfc8-c5c93d31c862@perex.cz \
    --to=perex@perex.cz \
    --cc=alsa-devel@alsa-project.org \
    --cc=tanuk@iki.fi \
    /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

Alsa-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/alsa-devel/0 alsa-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 alsa-devel alsa-devel/ https://lore.kernel.org/alsa-devel \
		alsa-devel@alsa-project.org
	public-inbox-index alsa-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.alsa-project.alsa-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git