Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
06.08.2014 12:15, Arun Raghavan wrote: On 6 August 2014 10:28, Alexander E. Patrakov wrote: 06.08.2014 10:20, Arun Raghavan wrote: On 6 August 2014 09:41, Alexander E. Patrakov wrote: 06.08.2014 09:49, Arun Raghavan wrote: [...] Not entirely true - with the patch I've posted, for the browser case, the user needs to worry about the main volume and the custom volume control that the stream might provide. And usually there are quick ways to modify main volume (e.g. scroll on the applet icon) If you say that, then there is obviously some misunderstanding. Let me restate what should work is the page does provide an HTML-based volume control: * main volume (scroll on the applet icon, or go to the Output Devices tab in pavucontrol); * tab volume (visible in pavucontrol on the Playback tab); * HTML-based volume control (visible in the web page, does not correspond to any slider in pavucontrol). If PulseAudio is configured to use non-flat volumes, that we have three factors that, when multiplied, determine the loudness of the sound that should come out. If flat volumes are in effect, then the first two should work in the usual flat fashion (with the main volume being the maximum of all tab volumes and volumes of non-browser applications, and changing them all when being changed by the user), and the HTML-based volume control should apply in a non-flat fashion on top of the tab volume. I think we're talking across each other a bit. I think I'm describing what we have (in which there isn't a per-tab volume just per-stream), and you're talking about what you would like to have. Yes. What I was referring to was that in my scenario (we have per-stream volumes, and global volume), if the browser disables flat-volumes for all its streams, then you have two controls - the JS/browser control on the page, and the main volume. Yes. And also in your scenario the JS control is visible in pavucontrol. Well, I am not sure. The doubt comes out from the possibility of an incompetent web programmer to create many stupid audio contexts from the same tab, thus again returning the slider-pollution problem. I think that sort of use should be considered bad behaviour (on any system, creating and not freeing resources will inevitable hit a limit), so trying to deal with that might not make sense. It does make sense. Instead of (or in addition to) the global limit, we might introduce a per-group limit or something like that, so that it is hit first. But I was talking more about the UI issue, because the limit that is _actually_ hit first is the number of UI elements (sliders in pavucontrol) that the user is willing to tolerate. I.e. I want to enforce the "one slider per tab" rule strictly, even if this means excluding some use cases. -- 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 10:28, Alexander E. Patrakov wrote: > 06.08.2014 10:20, Arun Raghavan wrote: >> >> On 6 August 2014 09:41, Alexander E. Patrakov wrote: >>> >>> 06.08.2014 09:49, Arun Raghavan wrote: [...] >> Not entirely true - with the patch I've posted, for the browser case, >> the user needs to worry about the main volume and the custom volume >> control that the stream might provide. And usually there are quick >> ways to modify main volume (e.g. scroll on the applet icon) > > > If you say that, then there is obviously some misunderstanding. Let me > restate what should work is the page does provide an HTML-based volume > control: > > * main volume (scroll on the applet icon, or go to the Output Devices tab > in pavucontrol); > * tab volume (visible in pavucontrol on the Playback tab); > * HTML-based volume control (visible in the web page, does not correspond > to any slider in pavucontrol). > > If PulseAudio is configured to use non-flat volumes, that we have three > factors that, when multiplied, determine the loudness of the sound that > should come out. If flat volumes are in effect, then the first two should > work in the usual flat fashion (with the main volume being the maximum of > all tab volumes and volumes of non-browser applications, and changing them > all when being changed by the user), and the HTML-based volume control > should apply in a non-flat fashion on top of the tab volume. I think we're talking across each other a bit. I think I'm describing what we have (in which there isn't a per-tab volume just per-stream), and you're talking about what you would like to have. What I was referring to was that in my scenario (we have per-stream volumes, and global volume), if the browser disables flat-volumes for all its streams, then you have two controls - the JS/browser control on the page, and the main volume. [...] >>> You missed the key point in my screenshot: there is only one tab open, >>> and I >>> got three sliders, because the game created three audio elements so far >>> on >>> that tab. One slider per tab (even if there are multiple audio elements >>> on >>> that tab) is indeed what I want. >> >> >> That is a good point. The solution is not immediately apparent to me - >> one possibly overarching option is to have per-tab volume control >> using the stream grouping mechanism I described, but there are likely >> to be cases where you _want_ individual control. > > > Then our disagreement is that you think that your option is possibly > overarching, while I think that it is the only valid one. My more detailed > viewpoint on this issue is: > > * If the application author thinks that there is a use case for the > individual control via an external application (the "external application" > clause is important), he should not group streams. > * All sounds on the same tab should be grouped unconditionally, because > there are web pages that leak (never close) old streams while creating new > ones. > * Javascript-based volume APIs should still be able to change the volume of > each audio element programmatically and independently, as required by the > HTML5 spec. > * And, of course, javascript-settable volume should apply in a non-flat > fashion on top of the tab volume. [...] >> [1]: https://developer.mozilla.org/en-US/docs/Web/API/AudioContext > > > Well, I am not sure. The doubt comes out from the possibility of an > incompetent web programmer to create many stupid audio contexts from the > same tab, thus again returning the slider-pollution problem. I think that sort of use should be considered bad behaviour (on any system, creating and not freeing resources will inevitable hit a limit), so trying to deal with that might not make sense. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio on Slackware 14.1
06.08.2014 03:34, terry wrote: /etc/rc.d/rc.pulseaudio start This init script is for system-wide PulseAudio instance. This is not a recommended way to start it, see http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide/ So, you just have to ignore the init script. Or even erase it so that it doesn't hurt your eyes. The proper way to start PulseAudio is from a user session. The correct command is: pulseaudio --start PulseAudio already contains a desktop file that is used by all non-broken desktop environments to auto-start it on login. See /etc/xdg/autostart/pulseaudio.desktop , so even the "pulseaudio --start" command is not actually needed to be issued. -- 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
06.08.2014 10:20, Arun Raghavan wrote: On 6 August 2014 09:41, Alexander E. Patrakov wrote: 06.08.2014 09:49, Arun Raghavan wrote: 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. Let me address this now :) With my proposal, if a web page draws a volume control using some HTML and javascript, then it should work, and should control the substream volume (which is invisible in pavucontrol). This should have no effect on the tab volume as displayed by pavucontrol. If a web page doesn't draw a volume control, then indeed, the only way to control its volume is via the desktop volume control application, or via the applet that sets the device volume. However, this is also the situation without my proposal, so there is no regression here. And there is an improvement: the user sees one slider per tab instead of potentially many. Not entirely true - with the patch I've posted, for the browser case, the user needs to worry about the main volume and the custom volume control that the stream might provide. And usually there are quick ways to modify main volume (e.g. scroll on the applet icon) If you say that, then there is obviously some misunderstanding. Let me restate what should work is the page does provide an HTML-based volume control: * main volume (scroll on the applet icon, or go to the Output Devices tab in pavucontrol); * tab volume (visible in pavucontrol on the Playback tab); * HTML-based volume control (visible in the web page, does not correspond to any slider in pavucontrol). If PulseAudio is configured to use non-flat volumes, that we have three factors that, when multiplied, determine the loudness of the sound that should come out. If flat volumes are in effect, then the first two should work in the usual flat fashion (with the main volume being the maximum of all tab volumes and volumes of non-browser applications, and changing them all when being changed by the user), and the HTML-based volume control should apply in a non-flat fashion on top of the tab volume. 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. You missed the key point in my screenshot: there is only one tab open, and I got three sliders, because the game created three audio elements so far on that tab. One slider per tab (even if there are multiple audio elements on that tab) is indeed what I want. That is a good point. The solution is not immediately apparent to me - one possibly overarching option is to have per-tab volume control using the stream grouping mechanism I described, but there are likely to be cases where you _want_ individual control. Then our disagreement is that you think that your option is possibly overarching, while I think that it is the only valid one. My more detailed viewpoint on this issue is: * If the application author thinks that there is a use case for the individual control via an external application (the "external application" clause is important), he should not group streams. * All sounds on the same tab should be grouped unconditionally, because there are web pages that leak (never close) old streams while creating new ones. * Javascript-based volume APIs should still be able to change the volume of each audio element programmatically and independently, as required by the HTML5 spec. * And, of course, javascript-settable volume should apply in a non-flat fashion on top of the tab volume. What would be ideal is for the application itself to express logical stream grouping, and for that to be exposed by the browser, and used by PA to group such related streams for a single volume control. Yes, exactly. But note that the application should still be able to set relative-to-group volumes on the group members. Perhaps AudioContext [1] is a good fit for this purpose. -- Arun [1]: https://developer.mozilla.org/en-US/docs/Web/API/AudioContext Well, I am not sure. The doubt comes out from the possibility of an incompetent web programmer to create many stupid audio contexts from the same tab, thus again returning the slider-pollution problem. -- 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:41, Alexander E. Patrakov wrote: > 06.08.2014 09:49, Arun Raghavan wrote: >> >> 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. > > > Let me address this now :) > > With my proposal, if a web page draws a volume control using some HTML and > javascript, then it should work, and should control the substream volume > (which is invisible in pavucontrol). This should have no effect on the tab > volume as displayed by pavucontrol. > > If a web page doesn't draw a volume control, then indeed, the only way to > control its volume is via the desktop volume control application, or via the > applet that sets the device volume. However, this is also the situation > without my proposal, so there is no regression here. And there is an > improvement: the user sees one slider per tab instead of potentially many. Not entirely true - with the patch I've posted, for the browser case, the user needs to worry about the main volume and the custom volume control that the stream might provide. And usually there are quick ways to modify main volume (e.g. scroll on the applet icon) >>> 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. > > > You missed the key point in my screenshot: there is only one tab open, and I > got three sliders, because the game created three audio elements so far on > that tab. One slider per tab (even if there are multiple audio elements on > that tab) is indeed what I want. That is a good point. The solution is not immediately apparent to me - one possibly overarching option is to have per-tab volume control using the stream grouping mechanism I described, but there are likely to be cases where you _want_ individual control. What would be ideal is for the application itself to express logical stream grouping, and for that to be exposed by the browser, and used by PA to group such related streams for a single volume control. Perhaps AudioContext [1] is a good fit for this purpose. -- Arun [1]: https://developer.mozilla.org/en-US/docs/Web/API/AudioContext ___ 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 09:49, Arun Raghavan wrote: 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. Let me address this now :) With my proposal, if a web page draws a volume control using some HTML and javascript, then it should work, and should control the substream volume (which is invisible in pavucontrol). This should have no effect on the tab volume as displayed by pavucontrol. If a web page doesn't draw a volume control, then indeed, the only way to control its volume is via the desktop volume control application, or via the applet that sets the device volume. However, this is also the situation without my proposal, so there is no regression here. And there is an improvement: the user sees one slider per tab instead of potentially many. 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. You missed the key point in my screenshot: there is only one tab open, and I got three sliders, because the game created three audio elements so far on that tab. One slider per tab (even if there are multiple audio elements on that tab) is indeed what I want. 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. Well, no comments here. -- 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 wrote: > 06.08.2014 06:31, Arun Raghavan wrote: >> >> On 6 August 2014 01:12, Alexander E. Patrakov 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
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 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] [PATCH v2 0/3] alsa: Support for only-multichannel devices
> > Looking at the logs, there is no sign of the multichannel profile at > > all. It makes me wonder if you're actually testing with my patch set > > applied, can you double check that there indeed is a "Multichannel" > > mapping in your default.conf? It was applied to git master last Friday. > > The default.conf surely has the mapping configuration. > > I checked out commit 48edd0a00f455df075efcf1986103e5f507c816f, so they > must includes all of your patches. > http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=48edd0a00f455df075efcf1986103e5f507c816f > > In this time, I use utopic (Ubuntu 14.10). I generate deb packages for > PulseAudio and install them. I suspect that I did wrong operations, thus > I'll try to upload the packages into my PPA. Then I hope you to check > them later. > > > If you're sure this is the case, I'll write a patch with some more > > debugging info that hopefully can help us pinpoint why it's working with > > my card but not with yours. > > Thank you. Please wait for my next message about PPA. > Does it mean that pulseaudio mix audio streams in stereo/4 channels and the io thread upmix silence to other channels ? Why the default rewind safeguard in 256 bytes not need to change when pulseaudio use 10 or more channels playback ? ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 0/3] alsa: Support for only-multichannel devices
Hi David, On Aug 5 2014 19:56, David Henningsson wrote: > Looking at the logs, there is no sign of the multichannel profile at > all. It makes me wonder if you're actually testing with my patch set > applied, can you double check that there indeed is a "Multichannel" > mapping in your default.conf? It was applied to git master last Friday. The default.conf surely has the mapping configuration. I checked out commit 48edd0a00f455df075efcf1986103e5f507c816f, so they must includes all of your patches. http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=48edd0a00f455df075efcf1986103e5f507c816f In this time, I use utopic (Ubuntu 14.10). I generate deb packages for PulseAudio and install them. I suspect that I did wrong operations, thus I'll try to upload the packages into my PPA. Then I hope you to check them later. > If you're sure this is the case, I'll write a patch with some more > debugging info that hopefully can help us pinpoint why it's working with > my card but not with yours. Thank you. Please wait for my next message about PPA. Regards Takashi Sakamoto (in summer vacation) o-taka...@sakamocchi.jp ___ 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 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] [PATCH] modules: Disable timer scheduling for a2dp playback to reduce power consumption.
On 8/5/14, 12:35 AM, Sajeesh Sidharthan wrote:
---
src/modules/bluetooth/module-bluez5-device.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/modules/bluetooth/module-bluez5-device.c
b/src/modules/bluetooth/module-bluez5-device.c
index 57b2791..eda7a9d 100644
--- a/src/modules/bluetooth/module-bluez5-device.c
+++ b/src/modules/bluetooth/module-bluez5-device.c
@@ -1170,10 +1170,10 @@ static void thread_func(void *userdata) {
a2dp_reduce_bitpool(u);
}
}
-
-do_write = 1;
-pending_read_bytes = 0;
}
+
+do_write = 1;
+pending_read_bytes = 0;
}
if (writable && do_write > 0) {
@@ -1208,7 +1208,7 @@ static void thread_func(void *userdata) {
sleep_for = PA_USEC_PER_MSEC * 500;
pa_rtpoll_set_timer_relative(u->rtpoll, sleep_for);
-disable_timer = false;
+/* disable_timer = false; *//* Disable timer to reduce
power consumption */
Why would this reduce power consumption, one would think that you want
to buffer up by specifying a large latency. If you disable timers you'll
have to force a specific buffer size for this sink.
Thanks,
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] pulseaudio on Slackware 14.1
I installed pulseaudio and what I *think/assume* were it's dependencies, (from slackbuild scripts) avahi-0.6.31-x86_64-1_SBo json-c-0.11-x86_64-1_SB libasyncns-0.8-x86_64-1_SBo lirc-0.9.0_3.10.17-x86_64-3_SBo jack-audio-connection-kit-0.124.1-x86_64-1_SBo pavucontrol-2.0-x86_64-1_SBo gtkmm3-3.8.1-x86_64-1_SBo alsa-plugins-1.0.26-x86_64-1_SBo pulseaudio-5.0-x86_64-1_SBo (listed in order they were installed) (some were listed as optional dependencies, one of which was orc which previously installed on Jun 17 ) = So I got the first set of errors when trying to start it: > > /etc/rc.d/rc.pulseaudio start > E: [pulseaudio] core-util.c: Failed to create secure directory > (/var/lib/pulse/.config/pulse): No such file or directory > Starting pulseaudio... > W: [pulseaudio] authkey.c: Failed to open cookie file > '/var/lib/pulse/.config/pulse/cookie': No such file or directory > W: [pulseaudio] authkey.c: Failed to load authorization key > '/var/lib/pulse/.config/pulse/cookie': No such file or directory > W: [pulseaudio] authkey.c: Failed to open cookie file > '/var/lib/pulse/.pulse-cookie': No such file or directory > W: [pulseaudio] authkey.c: Failed to load authorization key > '/var/lib/pulse/.pulse-cookie': No such file or directory > W: [pulseaudio] authkey.c: Failed to open cookie file > '/var/lib/pulse/.config/pulse/cookie': No such file or directory > W: [pulseaudio] authkey.c: Failed to load authorization key > '/var/lib/pulse/.config/pulse/cookie': No such file or directory > No protocol specified > E: [pulseaudio] client-conf-x11.c: xcb_connection_has_error() returned true > E: [autospawn] core-util.c: Failed to create secure directory > (/var/lib/pulse/.config/pulse): No such file or directory > W: [autospawn] lock-autospawn.c: Cannot access autospawn lock. > E: [pulseaudio] main.c: Failed to acquire autospawn lock > > And this is what I got after the stop command: > > /etc/rc.d/rc.pulseaudio stop > E: [pulseaudio] core-util.c: Failed to create secure directory > (/var/lib/pulse/.config/pulse): No such file or directory > pulseaudio is not running. > > > I [took it upon myself to] add root to the pulse group and so now I just get /etc/rc.d/rc.pulseaudio start Starting pulseaudio... No protocol specified E: [pulseaudio] client-conf-x11.c: xcb_connection_has_error() returned true And when I stop it: /etc/rc.d/rc.pulseaudio stop Stopping pulseaudio...Done -- In God we trust. <>< ___ 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
[pulseaudio-discuss] [RFC] Per-client flat-volumes control
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? Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] core: Add a per-stream flat-volumes flag
This is not expected to be used by most clients - the default
system-wide setting is preferred to provide a consistent user
experience.
However certain clients (at the moment, this is just web browsers), need
to be able to disable clients from modifying system-wide volume, so
this provides such a mechanism.
---
PROTOCOL| 6 ++
configure.ac| 2 +-
src/modules/module-tunnel.c | 5 +
src/pulse/def.h | 9 -
src/pulse/stream.c | 11 ++-
src/pulsecore/cli-text.c| 3 ++-
src/pulsecore/protocol-native.c | 14 --
src/pulsecore/sink-input.c | 22 +++---
src/pulsecore/sink-input.h | 4 +++-
src/pulsecore/sink.c| 18 ++
10 files changed, 80 insertions(+), 14 deletions(-)
diff --git a/PROTOCOL b/PROTOCOL
index 3c08fea..3fba5eb 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -371,6 +371,12 @@ PA_COMMAND_DISABLE_SRBCHANNEL
Tells the client to stop listening on the additional SHM ringbuffer channel.
Acked by client by sending PA_COMMAND_DISABLE_SRBCHANNEL back.
+## v31, implemented by >= 6.0
+
+new flag at end of CREATE_PLAYBACK_STREAM:
+
+bool no_flat_volume
+
If you just changed the protocol, read this
## module-tunnel depends on the sink/source/sink-input/source-input protocol
## internals, so if you changed these, you might have broken module-tunnel.
diff --git a/configure.ac b/configure.ac
index 837e81e..255212e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -41,7 +41,7 @@ AC_SUBST(PA_MINOR, pa_minor)
AC_SUBST(PA_MAJORMINOR, pa_major.pa_minor)
AC_SUBST(PA_API_VERSION, 12)
-AC_SUBST(PA_PROTOCOL_VERSION, 30)
+AC_SUBST(PA_PROTOCOL_VERSION, 31)
# The stable ABI for client applications, for the version info x:y:z
# always will hold y=z
diff --git a/src/modules/module-tunnel.c b/src/modules/module-tunnel.c
index 193d091..bd45702 100644
--- a/src/modules/module-tunnel.c
+++ b/src/modules/module-tunnel.c
@@ -1757,6 +1757,11 @@ static void setup_complete_callback(pa_pdispatch *pd,
uint32_t command, uint32_t
}
#endif
+#ifdef TUNNEL_SINK
+if (u->version >= 31)
+pa_tagstruct_put_boolean(reply, false); /* allow flat-volumes on this
stream */
+#endif
+
pa_pstream_send_tagstruct(u->pstream, reply);
pa_pdispatch_register_reply(u->pdispatch, tag, DEFAULT_TIMEOUT,
create_stream_callback, u, NULL);
diff --git a/src/pulse/def.h b/src/pulse/def.h
index dfc0c10..d0a37f8 100644
--- a/src/pulse/def.h
+++ b/src/pulse/def.h
@@ -349,11 +349,17 @@ typedef enum pa_stream_flags {
* consider absolute when the sink is in flat volume mode,
* relative otherwise. \since 0.9.20 */
-PA_STREAM_PASSTHROUGH = 0x8U
+PA_STREAM_PASSTHROUGH = 0x8U,
/**< Used to tag content that will be rendered by passthrough sinks.
* The data will be left as is and not reformatted, resampled.
* \since 1.0 */
+PA_STREAM_NO_FLAT_VOLUME = 0x10U,
+/**< Used to disable "flat-volumes" behaviour on an individual stream.
+ * Changes to this stream's volume will not affect device volume, even
+ * if the flat-volumes mode is enabled on the server.
+ * \since 6.0 */
+
} pa_stream_flags_t;
/** \cond fulldocs */
@@ -382,6 +388,7 @@ typedef enum pa_stream_flags {
#define PA_STREAM_FAIL_ON_SUSPEND PA_STREAM_FAIL_ON_SUSPEND
#define PA_STREAM_RELATIVE_VOLUME PA_STREAM_RELATIVE_VOLUME
#define PA_STREAM_PASSTHROUGH PA_STREAM_PASSTHROUGH
+#define PA_STREAM_NO_FLAT_VOLUME PA_STREAM_NO_FLAT_VOLUME
/** \endcond */
diff --git a/src/pulse/stream.c b/src/pulse/stream.c
index 8e35c29..ba5e7fb 100644
--- a/src/pulse/stream.c
+++ b/src/pulse/stream.c
@@ -1213,7 +1213,8 @@ static int create_stream(
PA_STREAM_START_UNMUTED|
PA_STREAM_FAIL_ON_SUSPEND|
PA_STREAM_RELATIVE_VOLUME|
- PA_STREAM_PASSTHROUGH)),
PA_ERR_INVALID);
+ PA_STREAM_PASSTHROUGH|
+ PA_STREAM_NO_FLAT_VOLUME)),
PA_ERR_INVALID);
PA_CHECK_VALIDITY(s->context, s->context->version >= 12 || !(flags &
PA_STREAM_VARIABLE_RATE), PA_ERR_NOTSUPPORTED);
PA_CHECK_VALIDITY(s->context, s->context->version >= 13 || !(flags &
PA_STREAM_PEAK_DETECT), PA_ERR_NOTSUPPORTED);
@@ -1372,6 +1373,9 @@ static int create_stream(
pa_tagstruct_put_boolean(t, flags & (PA_STREAM_PASSTHROUGH));
}
+if (s->context->version >= 31 && s->direction == PA_STREAM_PLAYBACK)
+pa_tagstruct_put_boolean(t, flags & (PA_STREAM_NO_FLAT_VOLUME));
+
pa_pstream_send_tagstruct(s->context->pstream, t);
pa_pdispatch_register_reply(s->context->pdispatch, tag, DEFAULT_TIMEOUT,
pa_create_stream_callback, s, NULL);
@@ -1389,9 +1393,14 @@ int pa_stream_connect
Re: [pulseaudio-discuss] Pulseaudio test suite failures
On Tue, Aug 5, 2014 at 10:47 AM, Peter Meerwald wrote: > >> On Mon, Aug 4, 2014 at 9:10 AM, Peter Meerwald wrote: >> > could you please try to pass --enable-neon-opt for the armhf build? I >> > think ARMHF is supposed to provide NEON support >> >> Armhf seems to be autodetecting neon[1]. However, NEON is not >> guaranteed to be available on armhf, so runtime detection is required. > > right armhf does not imply NEON, see > https://wiki.debian.org/ArmHardFloatPort#NEON Yes, I saw it there too :) > >> [1] >> https://buildd.debian.org/status/fetch.php?pkg=pulseaudio&arch=armhf&ver=5.0-6&stamp=1407203063 > > I managed to get a Debian jessie PPC image running and could reproduce the > mix-test issue; let's see OK, I've anyway uploaded to experimental a build reenabling the tests with both your patches. The results should start appearing at [1] as they become available [1] https://buildd.debian.org/status/package.php?p=pulseaudio&suite=experimental -- Saludos, Felipe Sateler ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio test suite failures
> On Mon, Aug 4, 2014 at 9:10 AM, Peter Meerwald wrote: > > could you please try to pass --enable-neon-opt for the armhf build? I > > think ARMHF is supposed to provide NEON support > > Armhf seems to be autodetecting neon[1]. However, NEON is not > guaranteed to be available on armhf, so runtime detection is required. right armhf does not imply NEON, see https://wiki.debian.org/ArmHardFloatPort#NEON > [1] > https://buildd.debian.org/status/fetch.php?pkg=pulseaudio&arch=armhf&ver=5.0-6&stamp=1407203063 I managed to get a Debian jessie PPC image running and could reproduce the mix-test issue; let's see p. -- Peter Meerwald +43-664-218 (mobile) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio test suite failures
On Mon, Aug 4, 2014 at 9:10 AM, Peter Meerwald wrote: > could you please try to pass --enable-neon-opt for the armhf build? I > think ARMHF is supposed to provide NEON support Armhf seems to be autodetecting neon[1]. However, NEON is not guaranteed to be available on armhf, so runtime detection is required. AFAICS pulse does runtime detect neon, so we should be OK. [1] https://buildd.debian.org/status/fetch.php?pkg=pulseaudio&arch=armhf&ver=5.0-6&stamp=1407203063 -- Saludos, Felipe Sateler ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] core: Closing proper file descriptor when pipe creation fails.
Hi Sajeesh, On 5 August 2014 09:53, Sajeesh Sidharthan wrote: > > Hi Arun, > > This is the first time I have submitted a patch to open source. > > Could you please let me know if I have to do anything further if the change > is acceptable? Nothing to do from your side - the patch is now upstream - http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=7dfffdf8e5e21d3fd0dcdf98bc8ea2136d02d599 Only thing left to do for you is send in more patches. ;-) Just as a note though, the convention in open source mailing lists is to not top-post (i.e. it is preferred to reply inline, as I am now), and to send plain text email rather than HTML. Regards, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 0/3] alsa: Support for only-multichannel devices
On 2014-08-05 05:53, Takashi Sakamoto wrote: > Hi David, > > I tested this functionality with my two devices below. As a result, the > fallback did not work well. Please check the attached files. > > Echo Audio Audiofile 4 (6ch capture/6ch playback) > M-Audio FireWire Audiophile (4ch capture/6ch playback) Thanks for testing! Looking at the logs, there is no sign of the multichannel profile at all. It makes me wonder if you're actually testing with my patch set applied, can you double check that there indeed is a "Multichannel" mapping in your default.conf? It was applied to git master last Friday. If you're sure this is the case, I'll write a patch with some more debugging info that hopefully can help us pinpoint why it's working with my card but not with yours. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
