[pulseaudio-tickets] [Bug 97777] Clipping with per-stream volume above 100% even though device volume below 100%

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=97777

--- Comment #4 from Tanu Kaskinen <tanuk at iki.fi> ---
(In reply to Niklas Haas from comment #3)
> > If the sink used floats too, I think the audio wouldn't get clipped.
> 
> I could try that, although I'm not quite sure how. The ALSA sink doesn't
> support float formats natively, so I'd need a conversion plugin (`type
> plug`) in the signal path - and I'm not sure how to get PulseAudio to
> include one when opening the ALSA device.

You could hack /usr/share/pulseaudio/alsa-mixer/profiles/default.conf. For
example, the analog stereo sink and source have this configuration:

[Mapping analog-stereo]
device-strings = front:%f hw:%f
channel-map = left,right
paths-output = analog-output analog-output-lineout analog-output-speaker
analog-output-headphones analog-output-headphones-2
paths-input = analog-input-front-mic analog-input-rear-mic
analog-input-internal-mic analog-input-dock-mic analog-input analog-input-mic
analog-input-linein analog-input-aux analog-input-video analog-input-tvtuner
analog-input-fm analog-input-mic-line analog-input-headphone-mic
analog-input-headset-mic
priority = 10

Replacing front:%f with plughw:%f would probably work. ("%f" is the card index
or name.)

To configure the sample format, you need to set "default-sample-format =
float32ne" in /etc/pulse/daemon.conf ("ne" in "float32ne" means native
endianness. "le" and "be" can be used too for little and big endianness).

> > I suppose we could reorder the processing so that sink and stream volumes
> > are applied to the stream audio before we convert the audio to ints and mix
> > it with other streams. This would mean applying the sink volume multiple
> > times if there are multiple streams, though, whereas the current code only
> > applies the sink volume once to the mix result.
> 
> I'm confused by this. Isn't resampling and mixing done on floats rather than
> integers?

Internally resamplers will use whatever they want, and if a resampler uses
integers internally, the resampling will destroy float values outside the
normal range, even if both the sink and the stream use floats. We don't have
any clever logic that would pick the resampler implementation based on the sink
and stream format (and I'm not sure that would even be desirable, because we
don't have clear pairs of resamplers with equivalent speed and quality that
would only differ in their internal sample format).

Mixing is done with the sink sample format.

> > The case where you successfully play a stream with +10dB volume to a sink
> > with -10dB volume without clipping is a case where we skip the stream
> > volume application step and merge the stream volume with the sink volume
> > when the sink volume is applied. I think you'd get clipping if there was
> > another stream playing at the same time, because in this situation the
> > stream and sink volume application has to be two separate steps.
> 
> I tried playing multiple streams simultaneously, and I still get no clipping
> from pulse-test until the moment I cross the +10 dB threshold, after which I
> get immediate and obvious clipping. (My device is still set to -10 dB)

It seems that I was wrong about how we do things. Having multiple streams
doesn't prevent merging the two volume application steps into one. The thing
that prevents the merging is having a mismatch in channel maps. If you just
swap left and right channels in your stream's channel map, I expect you to get
clipping.

> > however: do you wish that the volume of the loud stream is remembered the
> > next time the application starts to play, or should it revert to the
> > default volume? We cap the remembered volume to 100%, so the "mixing
> > headroom" solution is good if you don't want to remember the volume, and
> > the "lower default volume" solution is good if you want to remember the
> > volume.
> 
> Depends on the application, actually. For MPD, yes, for mpv no. If it's
> possible to set the default volume for never-before-seen streams to 70% or
> so (instead of 100%), I would be perfectly happy since I consider that a
> completely acceptable solution, and it would also allow volume-remembering
> to continue working. It would also allow me to use software volume controls
> in mpv without running into any clipping-related issues, since 100% in mpv
> would again map to the maximum possible volume (rather than 140% in the
> mixing-headroom approach).

module-match can almost do what you want. The only problem is that it overrides
volumes set by module-stream-restore. See [1] for documentation. Adding a new
configuration option to change the hook callback priority should be pretty
trivial (the module uses a hook to get notified of new streams, and the
callback priorities decide the ordering between module-match and
module-stream-restore).

[1]
https://wiki.freedesktop.org/www/Software/PulseAudio/Documentation/User/Modules/#index53h3

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20160913/99fea953/attachment-0001.html>