Re: Issues and/or possible bugs in alsa

["Alexander E. Patrakov" <patrakov@gmail.com>]

25.02.2015 13:30, Jaroslav Kysela wrote:
> Dne 25.2.2015 v 09:14 Alexander E. Patrakov napsal(a):
>> 25.02.2015 03:46, Yomi Ogunwumi wrote:
>>> Third. This is just a question. Is this :
>>> https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio
>>> bug, or is it an issue with alsa?
>>> I'm only asking since Raymond linked something that seemed to belong to the
>>> alsa project.
>>>
>> This is a bug both in ALSA and in PulseAudio.
>>
>> The ALSA part (from the user viewpoint) is that the softvol plugin does
>> not reprocess the already-submitted but buffered samples when the volume
>> changes. But it can't, because that would require an additional thread
>> for monitoring the software volume changes, and such thread does not exist.
>>
>> The PulseAudio part of the bug is that it does not deactivate softvols,
>> even though it can apply volume in software itself. In October 2014, in
>> Dusseldorf, a general agreement has been reached on the following arguments:
>>
>>    * ALSA has no API to definitely distinguish softvols from other controls.
>>    * ALSA has the snd_ctl_elem_info_is_user() API function that tells
>> whether this is a userspace control.
>>    * All softvols are userspace controls.
>>    * There are other kinds of userspace controls, but they are rare.
>>    * If a control is named PCM Playback Volume and is a userspace
>> control, then it's likely a softvol. Not bulletproof, but a good-enough
>> heuristic.
>>    * On finding a softvol, PulseAudio should set it to 100% (so that it
>> doesn't eat CPU) and don't touch from that point on.
>>
>> But nobody has implemented this so far.
> PulseAudio should open PCM with the SND_PCM_NO_SOFTVOL mode. In this
> case, the PCM device does not add the softvol plugin to the internal
> plugin chain. These mode flags was introduced a long time ago (discussed
> with Lennart) and I thought that PA uses it.
>
> 					Jaroslav
>

Well, that can be done, but the "don't attempt to control the softvol" 
part of the bug needs to be solved first. SND_PCM_NO_SOFTVOL by itself 
is not sufficient.

-- 
Alexander E. Patrakov