Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2015-03-18 Thread Arun Raghavan
On 11 March 2015 at 19:32, Tanu Kaskinen tanu.kaski...@linux.intel.com wrote: Hi Arun, As you requested, I'm reviving the per-stream flat volumes discussion. Thanks for helping revive this! My preference would still be to add a separate stream-local volume control pointer to

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2015-03-18 Thread Tanu Kaskinen
On Wed, 2015-03-18 at 17:08 +0530, Arun Raghavan wrote: On 11 March 2015 at 19:32, Tanu Kaskinen tanu.kaski...@linux.intel.com wrote: Hi Arun, As you requested, I'm reviving the per-stream flat volumes discussion. Thanks for helping revive this! My preference would still be to add

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2015-03-11 Thread Tanu Kaskinen
Hi Arun, As you requested, I'm reviving the per-stream flat volumes discussion. My preference would still be to add a separate stream-local volume control pointer to pa_sink_input_info, but assuming that you haven't changed your mind, that idea doesn't seem feasible to get through. You seemed

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2014-08-15 Thread Tanu Kaskinen
On Wed, 2014-08-13 at 16:58 +0530, Arun Raghavan wrote: On 11 August 2014 20:31, Tanu Kaskinen tanu.kaski...@linux.intel.com wrote: I don't really agree on the API niceness argument, because in my proposal there are just two uint32_t fields added (indexes of the always-relative volume

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2014-08-11 Thread Arun Raghavan
On 6 August 2014 14:15, Tanu Kaskinen tanu.kaski...@linux.intel.com wrote: On Wed, 2014-08-06 at 13:31 +0530, Arun Raghavan wrote: I guess we're in disagreement there. We can discuss this further, either in a separate thread, or at GstConf (or both), but I would like to get some more opinions

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2014-08-11 Thread Tanu Kaskinen
On Mon, 2014-08-11 at 19:32 +0530, Arun Raghavan wrote: On 6 August 2014 14:15, Tanu Kaskinen tanu.kaski...@linux.intel.com wrote: On Wed, 2014-08-06 at 13:31 +0530, Arun Raghavan wrote: I guess we're in disagreement there. We can discuss this further, either in a separate thread, or at

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2014-08-06 Thread Alexander E. Patrakov
06.08.2014 14:45, Tanu Kaskinen wrote: On Wed, 2014-08-06 at 13:31 +0530, Arun Raghavan wrote: I guess we're in disagreement there. We can discuss this further, either in a separate thread, or at GstConf (or both), but I would like to get some more opinions on getting this patch in soon, since

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2014-08-06 Thread Rémi Denis-Courmont
Le 2014-08-06 11:45, Tanu Kaskinen a écrit : 3) Add a second volume control to streams, one which represents the stream's own volume only, i.e. never flat volume. Applications that want to avoid flat volume can use that volume control instead of the primary volume control. Looking beyond

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2014-08-06 Thread Tanu Kaskinen
On Wed, 2014-08-06 at 15:45 +0300, Rémi Denis-Courmont wrote: Le 2014-08-06 11:45, Tanu Kaskinen a écrit : 3) Add a second volume control to streams, one which represents the stream's own volume only, i.e. never flat volume. Applications that want to avoid flat volume can use that volume

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2014-08-06 Thread Rémi Denis-Courmont
Le 2014-08-06 16:10, Tanu Kaskinen a écrit : The answer to your question: no, the normal stream volume and the relative volume are very tightly tied together (and when flat volumes are not in use, they're exactly the same thing). You can't change one without affecting the other, and both are

[pulseaudio-discuss] [RFC] Per-client flat-volumes control

2014-08-05 Thread Arun Raghavan
Hi folks, Alexander's already brought up the issue of websites that can set the volume on a stream programmatically, and either unwittingly or malicious set the system volume to 100% when using flat-volumes, and while I've been against having to deal with this on the PulseAudio side, I think we

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2014-08-05 Thread Alexander E. Patrakov
06.08.2014 00:54, Arun Raghavan wrote: Hi folks, Alexander's already brought up the issue of websites that can set the volume on a stream programmatically, and either unwittingly or malicious set the system volume to 100% when using flat-volumes, and while I've been against having to deal with

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2014-08-05 Thread Arun Raghavan
On 6 August 2014 01:12, Alexander E. Patrakov patra...@gmail.com wrote: 06.08.2014 00:54, Arun Raghavan wrote: Hi folks, Alexander's already brought up the issue of websites that can set the volume on a stream programmatically, and either unwittingly or malicious set the system volume to

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2014-08-05 Thread Alexander E. Patrakov
06.08.2014 06:31, Arun Raghavan wrote: On 6 August 2014 01:12, Alexander E. Patrakov patra...@gmail.com wrote: I think that the real problem that needs to be solved is not only that flat volumes are inapplicable to the web, but also that PulseAudio doesn't provide any API for intra-application

Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control

2014-08-05 Thread Arun Raghavan
On 6 August 2014 09:09, Alexander E. Patrakov patra...@gmail.com wrote: 06.08.2014 06:31, Arun Raghavan wrote: On 6 August 2014 01:12, Alexander E. Patrakov patra...@gmail.com wrote: I think that the real problem that needs to be solved is not only that flat volumes are inapplicable to the