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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Sep 13 16:54:02 UTC 2016


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

--- Comment #3 from Niklas Haas <bugs.freedesktop at haasn.xyz> ---
> 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.

> 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?

> 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)

> Your goal is to be able to increase the volume of a specific stream higher than other streams, without risk of clipping, right? 

Exactly.

> Another solution would be to set the default stream volume to something less than 100%. That would be simpler. The two solutions aren't equivalent, 

They both solve my use case as far as I'm concerned.

> 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).

-- 
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/55fcb7fb/attachment.html>


More information about the pulseaudio-bugs mailing list