[pulseaudio-discuss] [PATCH v3 0/6] Add default volume to ports

[David Henningsson]

On 2015-05-05 17:28, Alexander E. Patrakov wrote:
> 05.05.2015 19:08, Tanu Kaskinen wrote:
>> On Tue, 2015-05-05 at 17:31 +0500, Alexander E. Patrakov wrote:
>>> 27.04.2015 16:34, Tanu Kaskinen wrote:
>>>> Here's the third version of the patch set that aims to fix the Aureon
>>>> volume bug[1].
>>>>
>>>> Changes in v3:
>>>>    - Use pa_parse_volume() in pa_config_parse_volume().
>>>>    - Add mute and save_mute fields to
>>>>      pa_sink/source_port_changed_hook_data to make the mute handling
>>>>      symmetric with the volume handling.
>>>>
>>>> David suggested that I could share the volume parsing code also in
>>>> pactl, but that turned out to be difficult with pactl's relative
>>>> volume adjustments, so I didn't want to do that in this patch set, but
>>>> I plan to do that later.
>>>>
>>>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=81777
>>>
>>> I have tested the series. It works as described. However, the heuristic
>>> that decides between 100% and 30% volume default could use some more
>>> thinking.
>>>
>>> On my new Rotel RA-1570 integrated amplifier, it defaulted to 30%
>>> volume. Also, because the ALSA mixer does not expose any volume controls
>>> on this card, PulseAudio applied those 30% in software. As this is a
>>> high-end amplifier (as opposed to the originally-discussed Terratec
>>> Aureon Dual USB card) and it has a hardware volume knob, I would object
>>> to this default on my card.
>>>
>>> So, maybe it is a good idea to apply the 30% default volume not on all
>>> analog ports, but only on paths that have a volume control exposed in
>>> ALSA mixer, plus some explicit exceptions (including the Terratec card)?
>>
>> That sounds ok to me (I'm not volunteering to write the patch, however).
>> I'm not sure what would be the best approach to configuring it... Should
>> the analog path configuration files explicitly say that "I'm an analog
>> path", and the mixer code would then apply this heuristics to those
>> paths? Or should the mixer code just look at the path name, and infer
>> that it's an analog path if the name starts with "analog-"?
>
> I think that, out of these two possibilities, an explicit "I'm an analog
> path" statement is better. Or maybe use a negative - "I am a digital
> path", that's less lines to write, and also safer if new analog paths
> appear.
>
> So my logic becomes:
>
> 0. If the path explicitly sets the default volume, use it. This should
> only be set in exceptional cases like the Terratec card.
>
> 1. If the path is digital, set the default volume to 100%.
>
> 2. If the path is not digital, but there are no applicable ALSA volume
> controls at all (i.e. if PA would fall back to software-only volume
> control), set the default volume to 100%. Rationale: corner case, a hint
> that the volume control is in fact external.

I'm not sure about this corner case. It could just as well be that there 
are some really cheap devices that have no mixer (or, the driver fails 
to understand how to use it), and then the 30% should be standard.

You earlier said that line out should default to 30% just in case 
someone uses it as a headphone output, maybe the same reasoning applies 
here?

> 3. If the path is not digital, and there are applicable ALSA volume
> controls, then set the default volume to 30%.
>
> But, because you already have patches, please ignore that. I think my
> logic can almost be expressed using your "default-volume" option, we
> just need two such options: one applicable if there are ALSA mixer
> controls on the path, and the other applicable if there aren't such
> controls. This improvement can be done later, i.e. I don't object to the
> current patchset.
>
>>
>>> Alsa-info here:
>>> http://www.alsa-project.org/db/?f=45946d2958764b508773255a8ffffb1bf4e41ceb
>>>
>>>
>>> P.S. PulseAudio also finds a bogus SPDIF output on the Rotel amplifier.
>>> Maybe we need a whitelist, not a blacklist, here?
>>
>> Can you elaborate, what kind of whitelist? Only create spdif profiles on
>> whitelisted products? If that's what you mean, I don't think it's a good
>> idea. It's a worse situation if we erroneously disable the spdif
>> capability on a sound card than if we erroneously enable it.
>
> Yes, you understood me correctly.

I thought you were referring to the alsa-lib blacklist here [1]? That's 
where you're supposed to add devices that should not be opened as spdif.

> As for the fear that we erroneously
> disable the spdif capability, I think that it is a bit more subtle. On
> the majority of USB cards (i.e. on all cards that don't have a specific
> explicitly-written exception in the ALSA configs), both front:1 and
> iec958:1 resolve to hw:1, and absolutely nothing is done in ALSA to say
> to the actual hardware whether we want analog or digital output. So
> there is almost nothing to be lost.
>
> The only situations where this matters are related to default volumes
> and passthrough capability - but also note that some USB cards decode
> AC3 in hardware and then output that to headphones. So USB audio is
> really a gray (or unknown) area between analog and digital, and IMHO
> should ideally be special-cased.
>

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[1] 
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/conf/cards/USB-Audio.conf;h=031bee0d86fd66bbea0b39b5a8b3e9c2741e836d;hb=HEAD#l42