alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Tanu Kaskinen <tanuk@iki.fi>
To: Jaroslav Kysela <perex@perex.cz>,
	General PulseAudio Discussion
	<pulseaudio-discuss@lists.freedesktop.org>,
	alsa-devel <alsa-devel@alsa-project.org>
Subject: Re: [pulseaudio-discuss] [alsa-devel] Question about the various mixer options in UCM
Date: Sun, 23 Feb 2020 11:00:16 +0200	[thread overview]
Message-ID: <084fc279e86e5fdf7439161aede4a75c85be69a0.camel@iki.fi> (raw)
In-Reply-To: <9c35a20952f53624c8cd082a5e7de33d2d34adca.camel@iki.fi>

On Sat, 2020-02-22 at 08:53 +0200, Tanu Kaskinen wrote:
> On Sun, 2020-02-16 at 18:38 +0100, Jaroslav Kysela wrote:
> > Dne 16. 02. 20 v 11:06 Tanu Kaskinen napsal(a):
> > > On Sun, 2020-02-16 at 11:42 +0200, Tanu Kaskinen wrote:
> > > > + pulseaudio-discuss@lists.freedesktop.org
> > > > 
> > > > On Sat, 2020-02-15 at 17:25 +0100, Jaroslav Kysela wrote:
> > > > > 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.
> > > > 
> > > > Verb + list-of-device-variants sounds like a good way to map UCM
> > > > devices to pulseaudio profiles (and if there's just one verb, which I
> > > > expect to be the common case, don't show it in the profile name). I
> > > > don't know how the variants should be configured in UCM, but I know
> > > > that device variants should be able to declare conflicts with other
> > > > devices (or device variants). For example, 5.1 speaker output may make
> > > > recording impossible, while stereo speaker output can be used toghether
> > > > with a mic. If this information is not provided by UCM, pulseaudio will
> > > > have to probe all variant combinations (like it currently does with the
> > > > legacy mixer system).
> > > 
> > > Sorry, now I realized that the Verb + list-of-device-variants scheme
> > > doesn't really work after all as the profile scheme. Or maybe it does,
> > > but it's significantly different from what we do currently. Switching
> > > between Headphones and Speaker-Stereo often doesn't require reopening
> > > the PCM device, so there's no need for separate Headphones and Speaker-
> > > Stereo profiles. I guess we could still create separate profiles, it
> > > just means that the profile list will get much longer.
> > > 
> > > We could add a separate optimization step to the profile creation
> > > process. That is, first create all possible device-variant combinations
> > > as the initial profile list, and then inspect which profiles can be
> > > merged. Naming the merged profiles becomes a problem, but I imagine
> > > it's solvable with static rules (e.g. merging Speakers-Stereo and
> > > Headphones becomes Analog-Stereo), and if necessary the merging can be
> > > improved gradually over time.
> > > 
> > > > From profile creation perspective the ideal scheme would be not based
> > > on UCM devices but on PCM devices and their configuration variants, but
> > > I imagine naming would be an even bigger problem with this scheme (how
> > > to map PCM device names to sensible user friendly names?).
> > 
> > I think that I didn't explain my idea in detail. The variant verbs may be 
> > almost identical (thus all devices will be defined) like the "master" one. But 
> > the specific variant configuration will be returned to the application. So it 
> > will differ only in the channel count value for the Speaker device or so. The 
> > PCM device name + PCM parameters check will be fine. I don't think that we 
> > should modify something on the PA side. PA activates only one verb per 
> > soundcard now.
> 
> Oh, you want to create variant verbs? Is the idea that all possible
> device combinations will be made separate verbs? That would make life
> easier for PulseAudio, but wouldn't it mean a lot more work for UCM
> configuration writers? Rather than generating the device combinations
> automatically in PulseAudio, the combinations would have to be manually
> listed in every UCM configuration.
> 
> I think it would be better to define only one verb per sound card and
> declare the conflicts between the devices or device variants, and let
> PulseAudio automatically generate the device combinations as profiles.
> 
> I may be misunderstanding something, I didn't for example understand
> what you meant by "the PCM device name + PCM parameters check will be
> fine". Some examples could be useful. Let's say that there's a sound
> card that has stereo output (either headphones or line-out), 4.0
> output, 5.1 output, SPDIF output and stereo input. If input is used,
> 5.1 output can't be used at the same time. Would UCM define the
> following verbs?:
> 
> HiFi:Headphones,SPDIF,Mic
> HiFi:Line-Stereo,SPDIF,Mic
> HiFi:Line-4.0,SPDIF,Mic
> HiFi:Line-5.1,SPDIF

I'm currently writing UCM configuration for Audigy2, because
PulseAudio's default configuration doesn't work with that card
properly. I'm creating verbs for each possible device combination, and
I ran into a naming issue. How should "bidirectional" devices be listed
in the verb name? If there's both line-out and line-in and SPDIF
supports both input and output, maybe the verb name could be for
example this:

HiFi:Line-4.0-Out,SPDIF-Out,Line-Stereo-In,SPDIF-In

The device name in SectionDevice would be just "Line" or "SPDIF".

I don't really like bidirectional devices, i.e. I'd prefer have
separate SectionDevice names for Line-In and Line-Out, but I guess
merging them into one device can work.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk


  reply	other threads:[~2020-02-23  9:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-15  6:29 [alsa-devel] Question about the various mixer options in UCM Tanu Kaskinen
2020-02-15 16:25 ` Jaroslav Kysela
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 [this message]
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=084fc279e86e5fdf7439161aede4a75c85be69a0.camel@iki.fi \
    --to=tanuk@iki.fi \
    --cc=alsa-devel@alsa-project.org \
    --cc=perex@perex.cz \
    --cc=pulseaudio-discuss@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).