Removing the flat volume from pulseaudio and moving it into the mixer would make it hard to impossible to implement the following items: 1) give some apps flat volumes and others not. 2) raise the volume of just one stream in the mixer without affecting others. Since the mixer is not running inside pulseaudio, it can't atomically update both the master volume and the volumes of all other streams Wim On 19 October 2015 at 17:32, Alexander E. Patrakov <patrakov at gmail.com> wrote: > 19.10.2015 19:38, Wim Taymans wrote: > >> Hi all, >> >> Now that we are talking about flat volumes again (but I don't want to >> hijack the other thread), I would like to present another alternative to >> fix >> the problems with flat-volumes. >> >> The idea is that all apps, by default, operate in non-flat volume mode. >> This means all volume control done from the app is relative to the master >> volume. >> >> Privileged apps can see flat-volumes and thus (indirectly) change the >> master volume. One such privileged app is the volume control applet but >> it could be possible to manually enable trusted apps (maybe with a switch >> in the volume control next to the app stream). >> >> I made a little hack to let you try this, gnome-control-center is a >> hardcoded >> privileged app but you can see how we can store that in the database later >> or how we can hook this into the security framework. >> >> >> http://cgit.freedesktop.org/~wtay/pulseaudio/commit/?h=flat-volume-privilege-hack&id=1b203fe6bcc8bba1db1911fd4dbf225f36a6dbb9 >> >> I like this idea because: >> >> 1) it does not need any new api or changes to apps >> 2) sets a default that will not cause 100% master volume with misbehaving >> apps >> 3) has the master/app volume separation that people understand and that is >> also exposed in apps (volume in totem, master in gnome-shell header). >> 4) still exposes the flat-volume model if needed, which is IMHO the only >> way >> to sanely increase the volume of just 1 single app (when it needs >> adjusting >> the master volume). >> 5) minimal code changes. >> >> What do you think? >> > > I have looked into this patch idea, and I think that even more minimal > changes on pulseaudio side (but not minimal overall) are possible. However, > your approach has an advantage of actually having a patch :) > > Please note that, under your proposal, and also without any patch, any > application can introspect and set any sink volume directly, but no > application except dedicated mixer applications currently does this. > > So here is a strawman counterproposal that should have a similar effect. > Feel free to test whether the idea is implementable, and compare. > > 1. All apps operate with non-flat volumes. Thus, we don't have to > implement any policy in pulseaudio, and can even remove all the flat-volume > code. > > 2. Alter the logic for presenting sink input volumes to the user in > gnome-control-center and all other mixer applications. That is, it should > introspect both sink and sink input volumes, and move the slider to the > correct position according to the product of them. If a user moves the > slider, adjust the sink input volume if possible (i.e. if it is left of the > sink volume). If not, adjust both the sink volume and volumes of all sink > inputs connected there. > > I.e., move all flat volume logic from pulseaudio into mixer applications, > like it is done in Windows 7. Then we would have a very simple rule to > enforce if we want to implement privileged/unprivileged app separation: > "privileged app" = "has access to sink volumes". > > > Yes, I understand that this proposal looks at odds with my previous "ack" > to Arun's idea. That "ack" is still in force. > > -- > Alexander E. Patrakov > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20151020/45a3cc94/attachment.html>
