Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 pa_sink_input_info, but assuming that you haven't changed your mind, that idea doesn't seem feasible to get through. You seemed positive about extending the pa_stream API by adding pa_stream_get_volume() and pa_stream_set_volume(), and some mechanism to choose whether those functions should deal with the stream local volume or the possibly-flat volume. You suggested using a stream flag for controlling the volume mode, but using a flag would prevent the application from switching the mode after creating the stream, so maybe pa_stream_set_volume_mode() would be better? My reasoning with using a flag rather than a new function was that a new function increases the API surface, whereas a flag is merely an opt-in parameter on an existing API -- most developers won't have to look at or use this. The only thing the API buys us is the ability to switch behaviour at runtime, but I can't see any reason that apps might want to do this (so it's extra API surface for flexibility that, afaict, we don't need). Another solution would be to have separate functions for dealing with the stream-local volume and the possibly-flat volume. For example: pa_stream_get_volume() (possibly-flat) pa_stream_set_volume() (possibly-flat) pa_stream_get_local_volume() (stream-local) pa_stream_set_local_volume() (stream-local) I prefer a single API for the reasons I mentioned above. Then there's the question of whether to use pa_cvolume or something else. My opinion is that we shouldn't use pa_cvolume - I'm trying to move away from that representation with the volume control work. If we don't use pa_cvolume, then the alternatives are to use pa_bvolume or separate attributes for volume and balance (and mute?). (A note about pa_bvolume: while the current plan is to introduce pa_bvolume in the volume control work, I'm not 100% sure that that plan is going to hold - I have some suspicion that pa_bvolume might not be needed after all. Instead, it might be better to have separate attributes for volume, balance and mute in volume controls.) My concern here is that we don't know how the overall API will look, and other volume API we have uses pa_cvolume. Not using it in this one case just makes it inconsistent. I guess we should figure out how to deal with the transition away from pa_cvolume, if that's what we want, but I'd like to avoid an intermediate state where we have one part of the API that follows one convention, and another that follows something different (unless we can break it up into something simple like for all pa_volume_control* API, pa_cvolume is not used, and even that I'd like to eventually make consistent). Another open question is that should pa_stream_get_volume() be an async operation, or should the pa_stream object automatically track the stream and device volume? I'd prefer the getter function(s) to not be asynchronous, that is, pa_stream would automatically subscribe to stream and device changes and cache the volume locally in the application process. If that's what we should do, the next question is that should *every* application subscribe to the changes even if the application doesn't actually care about the volume? If not, then the subscription needs to be explicitly enabled somehow, for example with pa_stream_set_track_volume(). At the risk of sounding like a broken record (or a stuck ringbuffer), I'd like to avoid new API if possible. -- Tanu Here's my earlier mail to which I never got an answer, in case you want to review it before replying: On Fri, 2014-08-15 at 20:06 +0300, Tanu Kaskinen wrote: 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 control objects), one to pa_sink_input_info and one to pa_source_output_info. I don't see much difference to adding a flag. It's not just a matter of number of fields, but also the number of ideas the developer using our API has to walk through to use it successfully. Most developers don't need to deal with this problem, so we not add complexity for them. I suppose the complexity that you mean is the need to make a choice between using the volume_control field or the relative_volume_control field. The same choice has to be made with the flag: should the flag be used or not. When you say don't need to deal with this problem, I suppose not dealing means being ignorant about the possibility of using relative volume. It may indeed be easier to be ignorant of the
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 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 positive about extending the pa_stream API by adding pa_stream_get_volume() and pa_stream_set_volume(), and some mechanism to choose whether those functions should deal with the stream local volume or the possibly-flat volume. You suggested using a stream flag for controlling the volume mode, but using a flag would prevent the application from switching the mode after creating the stream, so maybe pa_stream_set_volume_mode() would be better? My reasoning with using a flag rather than a new function was that a new function increases the API surface, whereas a flag is merely an opt-in parameter on an existing API -- most developers won't have to look at or use this. The only thing the API buys us is the ability to switch behaviour at runtime, but I can't see any reason that apps might want to do this (so it's extra API surface for flexibility that, afaict, we don't need). Yes, the flexibility quite possibly won't be needed. If you think that the intrusiveness of a new function is that much greater than a new flag that it justifies the risk of adding a limited API that will possibly (but not likely) need to be extended later on, then let's agree to disagree (as I explained earlier, I don't see much difference in the intrusiveness). Another solution would be to have separate functions for dealing with the stream-local volume and the possibly-flat volume. For example: pa_stream_get_volume() (possibly-flat) pa_stream_set_volume() (possibly-flat) pa_stream_get_local_volume() (stream-local) pa_stream_set_local_volume() (stream-local) I prefer a single API for the reasons I mentioned above. Then there's the question of whether to use pa_cvolume or something else. My opinion is that we shouldn't use pa_cvolume - I'm trying to move away from that representation with the volume control work. If we don't use pa_cvolume, then the alternatives are to use pa_bvolume or separate attributes for volume and balance (and mute?). (A note about pa_bvolume: while the current plan is to introduce pa_bvolume in the volume control work, I'm not 100% sure that that plan is going to hold - I have some suspicion that pa_bvolume might not be needed after all. Instead, it might be better to have separate attributes for volume, balance and mute in volume controls.) My concern here is that we don't know how the overall API will look, and other volume API we have uses pa_cvolume. What overall API do you mean? The volume control API? Yes, that's still pending final approval. I think the initial patches will be ready relatively soon, and once the volume control API is agreed upon, then I think would be the time for deciding the details of the new pa_stream_get/set_volume() API. Not using it in this one case just makes it inconsistent. I guess we should figure out how to deal with the transition away from pa_cvolume, if that's what we want, but I'd like to avoid an intermediate state where we have one part of the API that follows one convention, and another that follows something different (unless we can break it up into something simple like for all pa_volume_control* API, pa_cvolume is not used, and even that I'd like to eventually make consistent). Another open question is that should pa_stream_get_volume() be an async operation, or should the pa_stream object automatically track the stream and device volume? I'd prefer the getter function(s) to not be asynchronous, that is, pa_stream would automatically subscribe to stream and device changes and cache the volume locally in the application process. If that's what we should do, the next question is that should *every* application subscribe to the changes even if the application doesn't actually care about the volume? If not, then the subscription needs to be explicitly enabled somehow, for example with pa_stream_set_track_volume(). At the risk of sounding like a broken record (or a stuck ringbuffer), I'd like to avoid new API if possible. Do I interpret correctly, that out of the three options: 1) asynchronous pa_stream_get_volume(), with the problems of more complex API and inconsistency with other pa_stream_* query functions, which are all synchronous (with the exception of pa_stream_update_timing_info(), but there's a good reason why that's asynchronous) 2) synchronous pa_stream_get_volume() with redundant event monitoring in clients that do streaming but don't care about the volume
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 positive about extending the pa_stream API by adding pa_stream_get_volume() and pa_stream_set_volume(), and some mechanism to choose whether those functions should deal with the stream local volume or the possibly-flat volume. You suggested using a stream flag for controlling the volume mode, but using a flag would prevent the application from switching the mode after creating the stream, so maybe pa_stream_set_volume_mode() would be better? Another solution would be to have separate functions for dealing with the stream-local volume and the possibly-flat volume. For example: pa_stream_get_volume() (possibly-flat) pa_stream_set_volume() (possibly-flat) pa_stream_get_local_volume() (stream-local) pa_stream_set_local_volume() (stream-local) Then there's the question of whether to use pa_cvolume or something else. My opinion is that we shouldn't use pa_cvolume - I'm trying to move away from that representation with the volume control work. If we don't use pa_cvolume, then the alternatives are to use pa_bvolume or separate attributes for volume and balance (and mute?). (A note about pa_bvolume: while the current plan is to introduce pa_bvolume in the volume control work, I'm not 100% sure that that plan is going to hold - I have some suspicion that pa_bvolume might not be needed after all. Instead, it might be better to have separate attributes for volume, balance and mute in volume controls.) Another open question is that should pa_stream_get_volume() be an async operation, or should the pa_stream object automatically track the stream and device volume? I'd prefer the getter function(s) to not be asynchronous, that is, pa_stream would automatically subscribe to stream and device changes and cache the volume locally in the application process. If that's what we should do, the next question is that should *every* application subscribe to the changes even if the application doesn't actually care about the volume? If not, then the subscription needs to be explicitly enabled somehow, for example with pa_stream_set_track_volume(). -- Tanu Here's my earlier mail to which I never got an answer, in case you want to review it before replying: On Fri, 2014-08-15 at 20:06 +0300, Tanu Kaskinen wrote: 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 control objects), one to pa_sink_input_info and one to pa_source_output_info. I don't see much difference to adding a flag. It's not just a matter of number of fields, but also the number of ideas the developer using our API has to walk through to use it successfully. Most developers don't need to deal with this problem, so we not add complexity for them. I suppose the complexity that you mean is the need to make a choice between using the volume_control field or the relative_volume_control field. The same choice has to be made with the flag: should the flag be used or not. When you say don't need to deal with this problem, I suppose not dealing means being ignorant about the possibility of using relative volume. It may indeed be easier to be ignorant of the existence of the flag than being ignorant about the relative_volume_control field, but as soon as the developer reads through the list of available stream flags, s/he will be hit by the same complexity either way. But I don't strictly need the relative_volume_control fields in the client API, so I may as well leave those out, if a satisfactory solution is found for the UI problems in your original proposal. The fields may be added later if needed. One option is to have the relative volume not be exposed as API, but be the volume that is controlled if this stream flag is set (i.e. pa_sink_input_set_volume() would modify the relative volume if the stream flag is set). So the idea is that the browser sees relative volume, but pavucontrol sees flat volume. This would otherwise work, but since the browser and pavucontrol use the same API, there's no way for the server to know which behaviour is desired for a given set or get volume operation, except by making the flag client-specific, and that seems ugly to me. What if you want to implement pavucontrol in the browser and the in-browser-pavucontrol and the stream share the same client connection? In that case the server has absolutely no way to distinguish which behaviour is wanted for a given get/set volume operation. I possibly
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 control objects), one to pa_sink_input_info and one to pa_source_output_info. I don't see much difference to adding a flag. It's not just a matter of number of fields, but also the number of ideas the developer using our API has to walk through to use it successfully. Most developers don't need to deal with this problem, so we not add complexity for them. I suppose the complexity that you mean is the need to make a choice between using the volume_control field or the relative_volume_control field. The same choice has to be made with the flag: should the flag be used or not. When you say don't need to deal with this problem, I suppose not dealing means being ignorant about the possibility of using relative volume. It may indeed be easier to be ignorant of the existence of the flag than being ignorant about the relative_volume_control field, but as soon as the developer reads through the list of available stream flags, s/he will be hit by the same complexity either way. But I don't strictly need the relative_volume_control fields in the client API, so I may as well leave those out, if a satisfactory solution is found for the UI problems in your original proposal. The fields may be added later if needed. One option is to have the relative volume not be exposed as API, but be the volume that is controlled if this stream flag is set (i.e. pa_sink_input_set_volume() would modify the relative volume if the stream flag is set). So the idea is that the browser sees relative volume, but pavucontrol sees flat volume. This would otherwise work, but since the browser and pavucontrol use the same API, there's no way for the server to know which behaviour is desired for a given set or get volume operation, except by making the flag client-specific, and that seems ugly to me. What if you want to implement pavucontrol in the browser and the in-browser-pavucontrol and the stream share the same client connection? In that case the server has absolutely no way to distinguish which behaviour is wanted for a given get/set volume operation. I possibly don't understand this - the browser sets the flag on the stream that it wants to apply this behaviour to, so the client connection it sets up is unaffected by it. Did I interpret you wrong then, you did not mean to make a difference between how pavucontrol and the web browser see the volume of the web browser's stream? What does this proposal (I mean the quoted part above: One option is to have...) solve, then - how is the end result any different from what you proposed first? One solution would be to add pa_stream_set_volume() and pa_stream_get_volume() functions instead of the flag, which would be available only to the stream owner. Those functions could then have a boolean argument for deciding between relative/absolute. But then this is certainly not any simpler than the two added integers that I proposed for the introspect API... I like the idea of a set/get volume API, but not of exposing the relative vs. absolute thing (for the same reason of added API complexity). I would rather have the flag set on the stream and have the API pick the right behaviour based on that. Do you mean that the flag would be a client-side-only thing? A client-side flag + pa_stream_get/set_volume() should work without the UI problems of the original proposal. If we go this route, what's your opinion about the choice between pa_cvolume and pa_bvolume in the pa_stream_get/set_volume() API? I'd suggest using pa_bvolume, because in my mind pa_cvolume is legacy stuff that should not be used in new APIs. One alternative would be to only add pa_stream_get_volume_control(), which would just return the volume control index (different index depending on the new flag), and actual volume manipulation would be done through the control API. This would require one extra pa_context_get_control_info_by_index() round-trip to get the initial volume, though... -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 on getting this patch in soon, since it's a practical fix that we can use now. Ok, so we have two proposals for preventing web apps from having access to flat volume: 1) Disable flat volume for individual streams. 2) Introduce substreams that the browser would group under a single tab stream. Web apps would only have access to the substream volumes, which would not interact with the flat volume logic. I have one of my own (I already mentioned this in [1]): 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. Even if proposals 1 and 2 are implemented, I'd still like to implement proposal 3 too, because it's simple (I need the second volume control at server side anyway, and adding it to the client API is just a matter of adding one field to pa_sink_input_info and pa_source_output_info) and because it provides some new possibilities for applications: for example, pavucontrol could have an option to not show flat volumes even when flat volumes are enabled. While in theory I like this, I have one pretty large reservation - I would like to only expand the API for clearly defined use-cases. If not, adding another volume control for very specific use cases makes the overall API more complex for the general case (I am approaching this from a usability point-of-view for developers trying to understand and use our API). Do you see concrete client-side use-cases for this other than the flat-volume case I'm trying to solve (for which, I think my solution is nicer from the API perspective, if not as clean as yours, implementation-wise). One option is to have the relative volume not be exposed as API, but be the volume that is controlled if this stream flag is set (i.e. pa_sink_input_set_volume() would modify the relative volume if the stream flag is set). If proposal 3 is implemented, proposal 1 becomes unnecessary, so I'd prefer to not merge Arun's patch. The per-stream disabling of flat volume also makes mixer UIs behave oddly. Alexander mentioned inconsistency in what is the desirable position for different streams, but I think a bigger problem is that strange things will happen if a flat volume stream pushes the device volume up. If there's also a non-flat volume stream playing to the same device, there are two ways to deal with that: either the non-flat volume stream's volume appears to go down in the UI (while there's no real change in volume), or alternatively the non-flat volume stream's volume appears to stay the same in the UI, while in reality it grows along with the device volume. I'm a bit confused about what you mean here. Will try to sync on IRC about what this implies. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 GstConf (or both), but I would like to get some more opinions on getting this patch in soon, since it's a practical fix that we can use now. Ok, so we have two proposals for preventing web apps from having access to flat volume: 1) Disable flat volume for individual streams. 2) Introduce substreams that the browser would group under a single tab stream. Web apps would only have access to the substream volumes, which would not interact with the flat volume logic. I have one of my own (I already mentioned this in [1]): 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. Even if proposals 1 and 2 are implemented, I'd still like to implement proposal 3 too, because it's simple (I need the second volume control at server side anyway, and adding it to the client API is just a matter of adding one field to pa_sink_input_info and pa_source_output_info) and because it provides some new possibilities for applications: for example, pavucontrol could have an option to not show flat volumes even when flat volumes are enabled. While in theory I like this, I have one pretty large reservation - I would like to only expand the API for clearly defined use-cases. If not, adding another volume control for very specific use cases makes the overall API more complex for the general case (I am approaching this from a usability point-of-view for developers trying to understand and use our API). Do you see concrete client-side use-cases for this other than the flat-volume case I'm trying to solve (for which, I think my solution is nicer from the API perspective, if not as clean as yours, implementation-wise). I mentioned the case of a mixer application like pavucontrol that wants to show non-flat volumes to the user (maybe with an option to switch between the two modes). I don't have other use cases in mind. 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 control objects), one to pa_sink_input_info and one to pa_source_output_info. I don't see much difference to adding a flag. One option is to have the relative volume not be exposed as API, but be the volume that is controlled if this stream flag is set (i.e. pa_sink_input_set_volume() would modify the relative volume if the stream flag is set). So the idea is that the browser sees relative volume, but pavucontrol sees flat volume. This would otherwise work, but since the browser and pavucontrol use the same API, there's no way for the server to know which behaviour is desired for a given set or get volume operation, except by making the flag client-specific, and that seems ugly to me. What if you want to implement pavucontrol in the browser and the in-browser-pavucontrol and the stream share the same client connection? In that case the server has absolutely no way to distinguish which behaviour is wanted for a given get/set volume operation. One solution would be to add pa_stream_set_volume() and pa_stream_get_volume() functions instead of the flag, which would be available only to the stream owner. Those functions could then have a boolean argument for deciding between relative/absolute. But then this is certainly not any simpler than the two added integers that I proposed for the introspect API... -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 it's a practical fix that we can use now. OK, I will go to GstConf. Ok, so we have two proposals for preventing web apps from having access to flat volume: 1) Disable flat volume for individual streams. Please note that Arun's patch does more than just this. It also introduces an environment variable that triggers this logic. 2) Introduce substreams that the browser would group under a single tab stream. Web apps would only have access to the substream volumes, which would not interact with the flat volume logic. I have one of my own (I already mentioned this in [1]): 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. It looks like a good proposal, especially useful for simple cases where there is only one stream. Even if proposals 1 and 2 are implemented, I'd still like to implement proposal 3 too, because it's simple (I need the second volume control at server side anyway, and adding it to the client API is just a matter of adding one field to pa_sink_input_info and pa_source_output_info) and because it provides some new possibilities for applications: for example, pavucontrol could have an option to not show flat volumes even when flat volumes are enabled. I have an opinion on this, but let's respect Arun's request to discuss this in a separate thread. If proposal 3 is implemented, proposal 1 becomes unnecessary, so I'd prefer to not merge Arun's patch. The per-stream disabling of flat volume also makes mixer UIs behave oddly. Alexander mentioned inconsistency in what is the desirable position for different streams, but I think a bigger problem is that strange things will happen if a flat volume stream pushes the device volume up. If there's also a non-flat volume stream playing to the same device, there are two ways to deal with that: either the non-flat volume stream's volume appears to go down in the UI (while there's no real change in volume), or alternatively the non-flat volume stream's volume appears to stay the same in the UI, while in reality it grows along with the device volume. I think that I can make an additional (possibly unfeasible) strawman proposal, more in line with (1), that partially takes this into account. Here it is: 4) Make PA_STREAM_NO_FLAT_VOLUME a client-only flag that is accepted in pa_stream_connect_playback() and friends, but not encoded in the protocol. The fact that the flag has been specified should be remembered by libpulse. Every time the client wants to change the volume, the library should query the sink volume, convert the desired volume to possibly-flat, and encode the resulting possibly-flat volume into the protocol. Also, the library should convert the volume for this stream from possibly-flat into non-flat representation on introspections, and update the client's idea of the volume when it uses the subscription interface to be notified about volume changes (be it from the sink or from the sink input). All other mixer applications should see the resulting possibly-flat volume. If this is feasible, then I would rank it above (1), but below (2) and (3). And of course, if (3) is implemented, then (4) becomes unneeded. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 HTML5, could that also cover per-stream replay gain? I mean, can applications both set the normal stream volume (as per user interaction) and the second stream volume (as per something else), and expect things to work? -- Rémi Denis-Courmont ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 control instead of the primary volume control. Looking beyond HTML5, could that also cover per-stream replay gain? I mean, can applications both set the normal stream volume (as per user interaction) and the second stream volume (as per something else), and expect things to work? First of all, some terminology. I don't want to keep talking about the second volume... I'll call the second stream volume relative volume, to distinguish it from the normal stream volume that can sometimes be absolute in relation to the device volume. I've also been using relative_volume_control as a variable name in the code I've written, but other name ideas are welcome. 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 expected to be user-controlled. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 expected to be user-controlled. Then I don't really see how and why the PulseAudio daemon would have to care about that new volume. The browser can simply divide/multiply the stream volume by its source/sink volume if the flat volume flag is on. You might or might not want to provide libpulse-level helpers for it, but that's pretty much it, AFAICT. -- Rémi Denis-Courmont ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 this on the PulseAudio side, I think we will have to after all. The practical part of this problem really is websites that set the stream volume to 1.0 as intialisation. There's nothing in the HTML5 spec that mandates this, but that doesn't seem to be stopping people from doing this. The Firefox folks, who are trying to use PA stream volumes are now also hitting this. I like how flat-volumes work on the desktop (and I know this is not a unanimous view), but pragmatically, for the website case, there does not seem to be a way to make this work. As a compromise, I propose a mechanism to allow streams to disable flat volumes for themselves. I'm attaching a patch that does this (which needs more thorough review by myself as well). Thoughts? [please treat this e-mail as neutral thoughts, i.e. neither support nor opposition, even though the text reads as opposition] If your patch is applied, I think (I have not tested) that there will be inconsistency in the volume controls displayed by the GUIs. I.e. the desired position of some volume controls would be 100%, and of the others it would be much less, and there is no real way for the user to discern, except by listening. 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 mixing. Please see my earlier thoughts on it here (point 7): http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-February/019968.html In other words: please add new API that would allow a browser to implement a per-tab (flat or non-flat, as configured in daemon.conf) visible volume control, with several substreams being mixed for each tab by PulseAudio. The javascript inside the browser should be able to set, invisibly for the user, tab-relative (and thus non-flat) volumes for each substream. Here is a test page for you: http://www.kibagames.com/Game/Kiba_Kumba_Jungle_Chaos -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 100% when using flat-volumes, and while I've been against having to deal with this on the PulseAudio side, I think we will have to after all. The practical part of this problem really is websites that set the stream volume to 1.0 as intialisation. There's nothing in the HTML5 spec that mandates this, but that doesn't seem to be stopping people from doing this. The Firefox folks, who are trying to use PA stream volumes are now also hitting this. I like how flat-volumes work on the desktop (and I know this is not a unanimous view), but pragmatically, for the website case, there does not seem to be a way to make this work. As a compromise, I propose a mechanism to allow streams to disable flat volumes for themselves. I'm attaching a patch that does this (which needs more thorough review by myself as well). Thoughts? [please treat this e-mail as neutral thoughts, i.e. neither support nor opposition, even though the text reads as opposition] If your patch is applied, I think (I have not tested) that there will be inconsistency in the volume controls displayed by the GUIs. I.e. the desired position of some volume controls would be 100%, and of the others it would be much less, and there is no real way for the user to discern, except by listening. Yes. I think this is inevitable if (as I want), we continue to keep the global flat volume concept. 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 mixing. Please see my earlier thoughts on it here (point 7): http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-February/019968.html In other words: please add new API that would allow a browser to implement a per-tab (flat or non-flat, as configured in daemon.conf) visible volume control, with several substreams being mixed for each tab by PulseAudio. The javascript inside the browser should be able to set, invisibly for the user, tab-relative (and thus non-flat) volumes for each substream. I don't think this really feasible - in this case, you need some way to control per-tab volume as well, and that's a UI change that we are in no position to effect across browsers. Regards, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 mixing. Please see my earlier thoughts on it here (point 7): http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-February/019968.html In other words: please add new API that would allow a browser to implement a per-tab (flat or non-flat, as configured in daemon.conf) visible volume control, with several substreams being mixed for each tab by PulseAudio. The javascript inside the browser should be able to set, invisibly for the user, tab-relative (and thus non-flat) volumes for each substream. I don't think this really feasible - in this case, you need some way to control per-tab volume as well, and that's a UI change that we are in no position to effect across browsers. Yes, what I am proposing is a big change in the volume model. External UIs such as pavucontrol should still be able to introspect and control stream volumes as usual, but a new class of streams (those that don't send samples themselves, but only allow their slave substreams to do so) would be introduced. Substream volumes should not be introspectable and should apply in a non-flat fashion on top of the stream volume. Browsers are expected to create this two-level hierarchy of streams: one master stream per tab, with a description matching the tab title, and as many substreams for that master stream as there are audio elements or other sound-producing HTML5 thingies on that tab. Basically, not what's on the attached screenshot (taken with non-flat volumes). Any browser that does this three sliders with meaningless titles in one tab thing is buggy. Note that Tanu has not flagged my proposal as unfeasible. On the contrary, he said that he could mentor this. So, I would like to see some discussion between you. I do agree that it is not feasible for PulseAudio 6.0. If you still think that it is unfeasible at all, then there is exactly nothing to do on the PulseAudio side. In this case, or if depending on PulseAudio 7.0 is unacceptable, we should propagate the following idea to the browser vendors: play one stream per tab, mix in-tab sources yourself and apply javascript-settable volumes before sending the result to PulseAudio. Please see commit 3535fd7a076228fdeae3755cf8ac6fdcfa28741d, it already does this kind of propaganda. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
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 web, but also that PulseAudio doesn't provide any API for intra-application mixing. Please see my earlier thoughts on it here (point 7): http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-February/019968.html In other words: please add new API that would allow a browser to implement a per-tab (flat or non-flat, as configured in daemon.conf) visible volume control, with several substreams being mixed for each tab by PulseAudio. The javascript inside the browser should be able to set, invisibly for the user, tab-relative (and thus non-flat) volumes for each substream. I don't think this really feasible - in this case, you need some way to control per-tab volume as well, and that's a UI change that we are in no position to effect across browsers. Yes, what I am proposing is a big change in the volume model. External UIs such as pavucontrol should still be able to introspect and control stream volumes as usual, but a new class of streams (those that don't send samples themselves, but only allow their slave substreams to do so) would be introduced. Substream volumes should not be introspectable and should apply in a non-flat fashion on top of the stream volume. Browsers are expected to create this two-level hierarchy of streams: one master stream per tab, with a description matching the tab title, and as many substreams for that master stream as there are audio elements or other sound-producing HTML5 thingies on that tab. Adding such a mechanism would not be as painful as adding a new type of stream to just set volumes. We could just as easily add a per-application volume mechanism and apply that as a volume factor on all of an application's streams. That's not to say I think this is a good solution to this problem. You didn't address my actual concern here - making such a change would either require the user to use their desktop volume control to change browser volume, or have browsers have a volume control widget for the browser volume. The first makes for bad UX, the second is impractical. Basically, not what's on the attached screenshot (taken with non-flat volumes). Any browser that does this three sliders with meaningless titles in one tab thing is buggy. The titles should be more meaningful, in which case I find this to be acceptable UI - I can then modify per-tab volumes from the mixer, if I wish. Note that Tanu has not flagged my proposal as unfeasible. On the contrary, he said that he could mentor this. So, I would like to see some discussion between you. I do agree that it is not feasible for PulseAudio 6.0. If you still think that it is unfeasible at all, then there is exactly nothing to do on the PulseAudio side. In this case, or if depending on PulseAudio 7.0 is unacceptable, we should propagate the following idea to the browser vendors: play one stream per tab, mix in-tab sources yourself and apply javascript-settable volumes before sending the result to PulseAudio. I still think the patch I've posted makes for an acceptable middle ground between keeping the usability aspect on the desktop app side while mitigating automated volume control on the web side. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
