[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
Wed Sep 14 00:46:33 UTC 2016


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

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

Makes sense. For the record, I am using soxr-vhq.

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

Indeed it does, and it does work well for me, apart from the part where it
overrides stream restoring. On the subject of making it configurable, it feels
sort of “weird” to have this filter expose its hook priority as a user
configurable variable, and using the filter also seem like a bit of abuse.

If we're touching source code, wouldn't it be better to add an option to
module-stream-restore indicating what volume to pick for streams that it fails
observing? Or perhaps adding a new `module-default-volume` that runs after
everything else and just sets a configurable volume if unset.

That being said, module-match being capable of running before
module-stream-restore definitely seems like a useful feature to have
regardless,
because I might want to set different default volumes based on the title (but
still retain the ability to make changes of my own).

P.s. I wonder if it would be possible to get module-match to detect changes to
the match table in realtime, although for that I suppose I could use inotify +
unload-module && load-module.

Anyway, how do you propose exposing this to the user? I noticed while digging
through the source that there's a pa_sink_input_new_data->volume_is_set bool,
maybe the right way to approach this would be to add a ‘force’ option to
module_stream_restore which forcibly applies saved volumes even if
volume_is_set
was already true by the time the fixate hook got called?

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


More information about the pulseaudio-bugs mailing list