Re: [pulseaudio-discuss] [PATCH v2 0/3] alsa: Support for only-multichannel devices
Hi David, I uploaded a series of deb packages for PulseAudio to PPA: https://launchpad.net/~mocchi/+archive/ubuntu/instruments Unfortunately, these packages also don't allow my system to handle these devices. I cannot see 'Multichannel' strings in logs. It's my glad to get your advices. Regards Takashi Sakamoto o-taka...@sakamocchi.jp On Aug 6 2014 11:37, Takashi Sakamoto wrote: > 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. ___ 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, > > 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) > Using 7.9 fragments of size 7168 bytes (10.16ms), buffer size is 56320 bytes (79.82ms) Seem bug in driver 0.713| 0.003) D: [pulseaudio] alsa-util.c: Managed to open hw:1 ( 0.713| 0.000) I: [pulseaudio] alsa-util.c: Disabling tsched mode since BATCH flag is set ( 0.713| 0.000) D: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_format(Signed 16 bit Little Endian) failed: Invalid argument ( 0.713| 0.000) D: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_format(Signed 16 bit Big Endian) failed: Invalid argument ( 0.713| 0.000) D: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_format(Float 32 bit Little Endian) failed: Invalid argument ( 0.713| 0.000) D: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_format(Float 32 bit Big Endian) failed: Invalid argument ( 0.713| 0.000) D: [pulseaudio] alsa-util.c: Maximum hw buffer size is 92 ms ( 1.154| 0.441) D: [pulseaudio] alsa-util.c: Set buffer size first (to 3528 samples), period size second (to 441 samples). ( 1.154| 0.000) I: [pulseaudio] alsa-util.c: Device hw:1 doesn't support sample format s16le, changed to s32le. ( 1.167| 0.012) I: [pulseaudio] alsa-source.c: Successfully opened device hw:1. ( 1.167| 0.000) I: [pulseaudio] alsa-source.c: Selected mapping 'Analog 4-channel Input' (analog-4-channel-input). ( 1.167| 0.000) I: [pulseaudio] alsa-source.c: Cannot enable timer-based scheduling, falling back to sound IRQ scheduling. ( 1.167| 0.000) I: [pulseaudio] alsa-source.c: Successfully enabled mmap() mode. ( 1.167| 0.000) I: [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:1' ( 1.168| 0.000) D: [pulseaudio] core-subscribe.c: Dropped redundant event due to change event. ( 1.168| 0.000) I: [pulseaudio] source.c: Created source 2 "alsa_input.firewire-0x000d6c03002b7e2e.analog-4-channel-input" with sample spec s32le 4ch 44100Hz and channel map aux0,aux1,aux2,aux3 ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.resolution_bits = "24" ( 1.168| 0.000) I: [pulseaudio] source.c: device.api = "alsa" ( 1.168| 0.000) I: [pulseaudio] source.c: device.class = "sound" ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.class = "generic" ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.subclass = "generic-mix" ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.name = "FW Audiophile PCM" ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.id = "BeBoB" ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.subdevice = "0" ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.subdevice_name = "subdevice #0" ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.device = "0" ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.card = "1" ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.card_name = "FW Audiophile" ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.long_card_name = "M-Audio FW Audiophile (id:13, rev:1), GUID 000d6c03002b7e2e at fw1.0, S400" ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.driver_name = "snd_bebob" ( 1.168| 0.000) I: [pulseaudio] source.c: device.bus_path = "pci-:02:01.0" ( 1.168| 0.000) I: [pulseaudio] source.c: sysfs.path = "/devices/pci:00/:00:1e.0/:02:01.0/fw1/fw1.0/sound/card1" ( 1.168| 0.000) I: [pulseaudio] source.c: udev.id = "firewire-0x000d6c03002b7e2e" ( 1.168| 0.000) I: [pulseaudio] source.c: device.bus = "firewire" ( 1.168| 0.000) I: [pulseaudio] source.c: device.vendor.name = "Ricoh Co Ltd" ( 1.168| 0.000) I: [pulseaudio] source.c: device.product.name = "R5C832 IEEE 1394 Controller" ( 1.168| 0.000) I: [pulseaudio] source.c: device.string = "hw:1" ( 1.168| 0.000) I: [pulseaudio] source.c: device.buffering.buffer_size = "56320" ( 1.168| 0.000) I: [pulseaudio] source.c: device.buffering.fragment_size = "7168" ( 1.168| 0.000) I: [pulseaudio] source.c: device.access_mode = "mmap" ( 1.168| 0.000) I: [pulseaudio] source.c: device.profile.name = "analog-4-channel-input" ( 1.168| 0.000) I: [pulseaudio] source.c: device.profile.description = "Analog 4-channel Input" ( 1.168| 0.000) I: [pulseaudio] source.c: device.description = "R5C832 IEEE 1394 Controller Analog 4-channel Input" ( 1.168| 0.000) I: [pulseaudio] source.c: alsa.mixer_name = "FW Audiophile" ( 1.168| 0.000) I: [pulseaudio] source.c: module-udev-detect.discovered = "1" ( 1.168| 0.000) I: [pulseaudio] source.c: device.icon_name = "audio-card-firewire" ( 1.168| 0.000) I: [pulseaudio] alsa-source.c: Using 7.9 fragments of size 7168 bytes (10.16ms), buffer size is 56320 bytes (79.82ms) ( 1.168| 0.000) D: [pulseaudio] alsa-source.c: hwbuf_unused=0 ( 1.168| 0.000) D: [pulseaudio] alsa-source.c: setting avail_min=1 ( 1.168| 0.000) D: [pulseaudio] alsa-util.c: snd_pcm_dump(): ( 1.168| 0.000) D: [pulseaudio] alsa-util.c: Hardware PCM card 1 'FW Audiophile' device 0 subdevice 0 ( 1.168| 0.000) D: [pulseaudio] alsa-util.c: Its setup is: ( 1.168| 0.000) D:
Re: [pulseaudio-discuss] [PATCH] util: Fix pa_get_binary_name() on Debian/kFreeBSD
On Mon, Aug 4, 2014 at 10:52 AM, Peter Meerwald wrote:
>
>> > Debian GNU/kFreeBSD uses a FreeBSD kernel and GLIBC,
>> > it #defines __FreeBSD_kernel__, but not __FreeBSD__ nor __linux__
>> > Debian GNU/kFreeBSD does have a /proc/self/exe
>> >
>> > FreeBSD #defines __FreeBSD__ and __FreeBSD_kernel__
>> >
>> > problem reporte here:
>> > http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-July/020998.html
>> >
>> > Signed-off-by: Peter Meerwald
>> > ---
>> > src/pulse/util.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/src/pulse/util.c b/src/pulse/util.c
>> > index 50f90b8..42b160a 100644
>> > --- a/src/pulse/util.c
>> > +++ b/src/pulse/util.c
>> > @@ -193,7 +193,7 @@ char *pa_get_binary_name(char *s, size_t l) {
>> > }
>> > #endif
>> >
>> > -#ifdef __linux__
>> > +#if defined(__linux__) || defined(__FreeBSD_kernel__)
>>
>> If FreeBSD does not have /proc/self/exe, but defines
>> __FreeBSD_kernel__ then this check will pass, which I don't think is
>> intended.
>
> on FreeBSD it will call pa_readlink("/proc/self/exe") which will return
> NULL and then continue with the FreeBSD-specific code
>
>> Perhaps the check needs to be defined(__FreeBSD_kernel__) &&
>> !defined(__FreeBSD__)?
>
> would work as well, I prefer simpler #defines;
> defined(__FreeBSD_kernel__) && defined(__GLIBC__) should do as well
>
> one extra readlink() doesn't hurt
I just found out about this possibility[1]:
#include
[...]
Dl_info DLInfo;
int err = dladdr(&main, &DLInfo);
if (err != 0) {
// DLInfo.dli_fname has the executable name.
}
This should work on all glibc systems. I can prepare a patch if this
solution is acceptable too.
[1]
https://www.gnu.org/software/hurd/hurd/translator/procfs/jkoenig/discussion.html#index7h1
--
Saludos,
Felipe Sateler
___
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 16:42 +0300, Rémi Denis-Courmont wrote: > 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. My original motivation for the new relative volume control was on the server side. When I implemented audio groups, there was a need to form master-slave relationships between volume controls: audio group volume controls could be masters for other audio group volume controls, and also for stream volume controls. Having a master-slave relationship means that when the master volume changes, the same change is propagated to slave volume controls (and also the other way around, so the relationship is more like peer-to-peer, but a hierarchical structure makes the traversal easier when propagating the changes). I got frustrated when it turned out to be rather complex to propagate the volume between audio groups and streams. I expected the operation to be simple, but since the audio group volume represents the relative volume, I had to add special casing to the propagation code in case the slave was a stream volume control. When doing master->slave propagation, I'd have to check if the slave was a sink input or source output, check whether the sink or source had flat volume enabled, and if so, remap the sink/source volume to the stream channel map, then divide the propagated volume by the sink/source volume, and finally call pa_control_set_volume() on the slave volume control. When doing slave->master propagation, similar dance is needed. With a separate relative control the propagation is very simple. I'm not sure that the separate relative volume control approach results in fewer lines of code, but I like it for several other reasons: * The volume control code doesn't have to do any special casing depending on what the control is being used for. * The volume controls that share the volume with each other have the exact same volume instead of stream volume controls being affected by the sink/source volume. * The stream relative volume is visible in "pactl list volume-controls", which can be nice for debugging. This could be achieved also by implementing the flat->relative conversion logic in pactl, but with the separate relative volume controls this feature comes for free. * If the relative volume controls are exposed to clients, implementing that is much simpler than some kind of libpulse-only helper thing that would have to make an extra round-trip for getting the sink/source state and do the volume calculations. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/3] fix PA test suite failure
On Wed, Aug 6, 2014 at 5:47 AM, Peter Meerwald wrote: > PA's mix-test fails on big endian systems as discovered by Felipe > > mix-test was in a rather embarassing state, reorganize to make it more > logical hopefully > > tested on Debian/Wheezy PPC in QEMU I'll try these patches on the debian build farm as soon as possible, but I can't today. -- Saludos, Felipe Sateler ___ 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
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 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] pa_simple_write blocks too long
On Thu, 2014-07-31 at 19:46 +, Stossel, Darrell (Insight/CSBU/RGS/Tucker) wrote: > I’ve been tasked with migrating our project from using two different > sound libraries to use only pulse. > > I’m stuck with 0.9.21 on RHEL6 as the release because too many > customers are on this version to force a migration. > > > > With this version, the asynchronous version I’ve found to be too > unreliable. Asserts get thrown about 5% of the time for conditions > that should not be true, even when using example code on the pulse > site. Can you point out which example code is crashing, and what is the failing assertion? > So, I’ve gone to the simple api. Outside of our product, I’ve gotten > both the record and play versions to work. Inside our product, the > record part works fine. However, the playback version blocks in > pa_simple_write (the first write when the buffer is made small, once > full in a large buffer) with no sound ever being played. I’ve tried > setting the buffer attributes to different settings with no success. > Using pacmd, both the sink and the sink input are shown in the running > state. No other applications are using audio at the same time. If you do try to play to the same sink with some other application, for example paplay, while your own application is stuck in pa_simple_write(), does that other application work? I don't see any other reason for pa_simple_write() getting stuck on a running sink than the sink getting stuck. What kind of sink is it? Alsa? -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] My opinion on Tanu's "second volume control" proposal
06.08.2014 17:39, I wrote: 06.08.2014 17:11, Tanu Kaskinen wrote: On Wed, 2014-08-06 at 16:35 +0600, Alexander E. Patrakov wrote: Tanu proposed: 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. The idea is well supplanted with a use case, but I think that this could use some more discussion. The potential problem with "just exporting" the field is that the proposal specifies only one additional volume factor with no clear ownership policy, and I am afraid that various agents (the server and the client) will fight over it. OTOH, especially if we design the API to avoid "set this extra volume to this value" operation and only allow relative changes, this may as well be a non-problem. The ownership policy for the new volume control would be the same as with the current stream volume, i.e. the user is the owner, and volume changes not originating from user action are most likely a bad idea. I'm not sure what kind of fight between agents you're thinking of, but with this ownership policy I think there shouldn't be any conflicts any more than there is with the current stream volume - stupid applications can always fight with the user, but the server will only do what clients ask it to do. OK, I was mistakenly under impression that the "volume changes not originating from user action are most likely a bad idea" policy would not apply to this second control. But, as it applies, there is indeed no fighting. After re-reading, I changed my opinion on the proposal. My new opinion is: The proposed feature has good justification, independent from the web use case, and should thus be implemented. However, when evaluating its positioning as a solution to the web browser 100% volume problem, one should keep in mind that this positioning relies on the "bad idea" mentioned above (because the root of the evil is that the browser changes the volume without user interaction). But the same also applies to Arun's patch. So, at best, when applied to this problem, both proposals are workarounds. Still, I prefer Tanu's proposal to be implemented, as it is more general and has an independent use case. For a perfect solution to the intra-application mixing problem (aka the web browser problem, or DirectSound emulation problem), there has to be a place where the "user is the owner" policy does not apply, and "application is the owner" policy applies instead. This implies that this volume factor should not be exposed in external volume control GUIs. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] My opinion on Tanu's "second volume control" proposal
06.08.2014 17:11, Tanu Kaskinen wrote: On Wed, 2014-08-06 at 16:35 +0600, Alexander E. Patrakov wrote: Tanu proposed: 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. The idea is well supplanted with a use case, but I think that this could use some more discussion. The potential problem with "just exporting" the field is that the proposal specifies only one additional volume factor with no clear ownership policy, and I am afraid that various agents (the server and the client) will fight over it. OTOH, especially if we design the API to avoid "set this extra volume to this value" operation and only allow relative changes, this may as well be a non-problem. The ownership policy for the new volume control would be the same as with the current stream volume, i.e. the user is the owner, and volume changes not originating from user action are most likely a bad idea. I'm not sure what kind of fight between agents you're thinking of, but with this ownership policy I think there shouldn't be any conflicts any more than there is with the current stream volume - stupid applications can always fight with the user, but the server will only do what clients ask it to do. OK, I was mistakenly under impression that the "volume changes not originating from user action are most likely a bad idea" policy would not apply to this second control. But, as it applies, there is indeed no fighting. Maybe, instead of having one extra volume control, we need to be able to create and destroy additional possibly-invisible volume controls on as-needed basis, with the final extra gain determined by the product of their volumes? E.g., one volume can be used for volume groups, one can be used for ducking when it is in effect, and one for client-specific needs. We have server-side capability for this already (see pa_sink_input.volume_factor_items), what's missing is a way for applications to create their own extra volume controls for cases where the user-controlled volume is not appropriate. I think this feature can and should co-exist with the "second volume control" that I proposed. I agree. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] My opinion on Tanu's "second volume control" proposal
On Wed, 2014-08-06 at 16:35 +0600, Alexander E. Patrakov wrote: > Tanu proposed: > > > 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. > > The idea is well supplanted with a use case, but I think that this could > use some more discussion. > > The potential problem with "just exporting" the field is that the > proposal specifies only one additional volume factor with no clear > ownership policy, and I am afraid that various agents (the server and > the client) will fight over it. OTOH, especially if we design the API to > avoid "set this extra volume to this value" operation and only allow > relative changes, this may as well be a non-problem. The ownership policy for the new volume control would be the same as with the current stream volume, i.e. the user is the owner, and volume changes not originating from user action are most likely a bad idea. I'm not sure what kind of fight between agents you're thinking of, but with this ownership policy I think there shouldn't be any conflicts any more than there is with the current stream volume - stupid applications can always fight with the user, but the server will only do what clients ask it to do. > Maybe, instead of having one extra volume control, we need to be able to > create and destroy additional possibly-invisible volume controls on > as-needed basis, with the final extra gain determined by the product of > their volumes? E.g., one volume can be used for volume groups, one can > be used for ducking when it is in effect, and one for client-specific needs. We have server-side capability for this already (see pa_sink_input.volume_factor_items), what's missing is a way for applications to create their own extra volume controls for cases where the user-controlled volume is not appropriate. I think this feature can and should co-exist with the "second volume control" that I proposed. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] My opinion on Tanu's "second volume control" proposal
Tanu proposed: 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. The idea is well supplanted with a use case, but I think that this could use some more discussion. The potential problem with "just exporting" the field is that the proposal specifies only one additional volume factor with no clear ownership policy, and I am afraid that various agents (the server and the client) will fight over it. OTOH, especially if we design the API to avoid "set this extra volume to this value" operation and only allow relative changes, this may as well be a non-problem. Maybe, instead of having one extra volume control, we need to be able to create and destroy additional possibly-invisible volume controls on as-needed basis, with the final extra gain determined by the product of their volumes? E.g., one volume can be used for volume groups, one can be used for ducking when it is in effect, and one for client-specific needs. -- 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 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
[pulseaudio-discuss] [PATCH 0/3] fix PA test suite failure
PA's mix-test fails on big endian systems as discovered by Felipe mix-test was in a rather embarassing state, reorganize to make it more logical hopefully tested on Debian/Wheezy PPC in QEMU Peter Meerwald (3): tests: Cleanup mix-test core: Fix PA_MAYBE_INT16_SWAP() macro tests: Fix mix-test on big-endian systems src/pulsecore/endianmacros.h | 4 +- src/tests/mix-test.c | 231 +++ 2 files changed, 57 insertions(+), 178 deletions(-) -- 1.9.1 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 3/3] tests: Fix mix-test on big-endian systems
the mix test code never worked on big-endian systems
patch saves a lot of duplicate test and uses more logical naming
see
http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-August/021035.html
Signed-off-by: Peter Meerwald
Reported-by: Felipe Sateler
---
src/tests/mix-test.c | 229 ---
1 file changed, 54 insertions(+), 175 deletions(-)
diff --git a/src/tests/mix-test.c b/src/tests/mix-test.c
index c0cd559..d5bae13 100644
--- a/src/tests/mix-test.c
+++ b/src/tests/mix-test.c
@@ -56,79 +56,37 @@ static const uint8_t ulaw_result[3][10] = {
{ 0x00, 0xff, 0xff, 0x80, 0x91, 0x31, 0x00, 0xe9, 0x12, 0x13 },
};
-/* PA_SAMPLE_S16LE */
-static const uint16_t s16le_result[3][10] = {
+static const uint16_t s16ne_result[3][10] = {
{ 0x, 0x, 0x7fff, 0x8000, 0x9fff, 0x3fff, 0x0001, 0xf000, 0x0020,
0x0021 },
{ 0x, 0x, 0x7332, 0x8ccd, 0xa998, 0x3998, 0x, 0xf199, 0x001c,
0x001d },
{ 0x, 0xfffe, 0x7fff, 0x8000, 0x8000, 0x7997, 0x0001, 0xe199, 0x003c,
0x003e },
};
-/* PA_SAMPLE_S16BE */
-static const uint16_t s16be_result[3][10] = {
-{ 0x, 0x, 0x7fff, 0x8000, 0x9fff, 0x3fff, 0x0001, 0xf000, 0x0020,
0x0021 },
-{ 0x, 0x, 0x8bff, 0x7300, 0xa8ff, 0x52ff, 0xe600, 0xd700, 0xcc1c,
0xb31d },
-{ 0x, 0xfeff, 0x0aff, 0xf300, 0x47ff, 0x91fe, 0xe601, 0xc701, 0xcc3c,
0xb33e },
-};
-
-/* PA_SAMPLE_FLOAT32LE */
-static const float float32le_result[3][10] = {
-{ 0.00, -1.00, 1.00, 4711.00, 0.222000, 0.33, -0.30,
99.00, -0.555000, -0.123000 },
-{ 0.00, -0.899987, 0.899987, 4239.837402, 0.199797, 0.296996, -0.269996,
89.098679, -0.499493, -0.110698 },
-{ 0.00, -1.899987, 1.899987, 8950.837891, 0.421797, 0.626996, -0.569996,
188.098679, -1.054493, -0.233698 },
-};
-
-/* PA_SAMPLE_FLOAT32BE */
-static const float float32be_result[3][10] = {
+static const float float32ne_result[3][10] = {
{ 0.00, -1.00, 1.00, 4711.00, 0.222000, 0.33, -0.30,
99.00, -0.555000, -0.123000 },
{ 0.00, -0.899987, 0.899987, 4239.837402, 0.199797, 0.296996, -0.269996,
89.098679, -0.499493, -0.110698 },
{ 0.00, -1.899987, 1.899987, 8950.837891, 0.421797, 0.626996, -0.569996,
188.098679, -1.054493, -0.233698 },
};
-/* PA_SAMPLE_S32LE */
-static const uint32_t s32le_result[3][10] = {
+static const uint32_t s32ne_result[3][10] = {
{ 0x0001, 0x0002, 0x7fff0003, 0x8004, 0x9fff0005, 0x3fff0006,
0x00010007, 0xf008, 0x0029, 0x0021000a },
{ 0x, 0x199b, 0x7332199c, 0x8ccd0003, 0xa998d99e, 0x3998999f,
0xe66c, 0xf199a007, 0x0018, 0x001db32e },
{ 0x0001, 0xfffe199d, 0x7fff, 0x8000, 0x8000, 0x799799a5,
0x0001e673, 0xe199a00f, 0x003cccd1, 0x003eb338 },
};
-/* PA_SAMPLE_S32BE */
-static const uint32_t s32be_result[3][10] = {
-{ 0x0001, 0x0002, 0x7fff0003, 0x8004, 0x9fff0005, 0x3fff0006,
0x00010007, 0xf008, 0x0029, 0x0021000a },
-{ 0x0066e600, 0x65b2cd01, 0xf117b402, 0x73989903, 0x0ee48004, 0xb8496705,
0xe6ca4c06, 0xd7303307, 0xccb21908, 0xb3190009 },
-{ 0x0066e601, 0x64b2ce03, 0x7017b505, 0xf3989907, 0xade38109, 0xf748680b,
0xe6cb4c0d, 0xc731330f, 0xccd21911, 0xb33a0013 },
-};
-
-/* PA_SAMPLE_S24LE */
-static const uint8_t s24le_result[3][30] = {
-{ 0x00, 0x00, 0x01, 0xff, 0xff, 0x02, 0x7f, 0xff, 0x03, 0x80, 0x00, 0x04,
0x9f, 0xff, 0x05, 0x3f, 0xff, 0x06, 0x01, 0x00, 0x07, 0xf0, 0x00, 0x08, 0x20,
0x00, 0x09, 0x21, 0x00, 0x0a },
-{ 0x66, 0xe6, 0x00, 0x31, 0xb3, 0x02, 0x23, 0x99, 0x03, 0x0b, 0x9a, 0x03,
0x0c, 0x66, 0x05, 0x1c, 0x4c, 0x06, 0xca, 0x4c, 0x06, 0x07, 0x34, 0x07, 0xb2,
0x19, 0x08, 0x19, 0x00, 0x09 },
-{ 0x66, 0xe6, 0x01, 0x30, 0xb3, 0x05, 0xa2, 0x98, 0x07, 0x8b, 0x9a, 0x07,
0xab, 0x65, 0x0b, 0x5b, 0x4b, 0x0d, 0xcb, 0x4c, 0x0d, 0xf7, 0x34, 0x0f, 0xd2,
0x19, 0x11, 0x3a, 0x00, 0x13 },
-};
-
-/* PA_SAMPLE_S24BE */
+/* attention: result is in BE, not NE! */
static const uint8_t s24be_result[3][30] = {
-{ 0x00, 0x00, 0x01, 0xff, 0xff, 0x02, 0x7f, 0xff, 0x03, 0x80, 0x00, 0x04,
0x9f, 0xff, 0x05, 0x3f, 0xff, 0x06, 0x01, 0x00, 0x07,
-0xf0, 0x00, 0x08, 0x20, 0x00, 0x09, 0x21, 0x00, 0x0a },
-{ 0x00, 0x00, 0x00, 0xff, 0xff, 0x1b, 0x73, 0x32, 0x1c, 0x8c, 0xcd, 0x03,
0xa9, 0x98, 0xde, 0x39, 0x98, 0x9f, 0x00, 0xe6, 0x6c,
-0xf1, 0x99, 0xa7, 0x1c, 0xcc, 0xc8, 0x1d, 0xb3, 0x2e },
-{ 0x00, 0x00, 0x01, 0xff, 0xfe, 0x1d, 0x7f, 0xff, 0xff, 0x80, 0x00, 0x00,
0x80, 0x00, 0x00, 0x79, 0x97, 0xa5, 0x01, 0xe6, 0x73,
-0xe1, 0x99, 0xaf, 0x3c, 0xcc, 0xd1, 0x3e, 0xb3, 0x38 },
+{ 0x00, 0x00, 0x01, 0xff, 0xff, 0x02, 0x7f, 0xff, 0x03, 0x80, 0x00, 0x04,
0x9f, 0xff, 0x05, 0x3f, 0xff, 0x06, 0x01, 0x00, 0x07, 0xf0, 0x00, 0x08, 0x20,
0x00, 0x09, 0x21, 0x00, 0x0a },
+{ 0x00, 0x00, 0x00, 0xff, 0xff, 0x1b, 0x73, 0x32, 0x1c, 0x8c, 0xcd, 0x03,
0xa9, 0x98, 0xde, 0x39, 0x98, 0x9f, 0x00, 0xe6, 0x6c, 0xf1, 0x99, 0xa7, 0x1c,
0xcc, 0xc8, 0x1d, 0xb3, 0x2e },
+{ 0x00, 0x00, 0x01, 0xff, 0xfe, 0x1d, 0x7f, 0xff, 0xff, 0x
[pulseaudio-discuss] [PATCH 1/3] tests: Cleanup mix-test
indentation and use of fabsf() for floats
Signed-off-by: Peter Meerwald
---
src/tests/mix-test.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/tests/mix-test.c b/src/tests/mix-test.c
index 9e5a0cc..c0cd559 100644
--- a/src/tests/mix-test.c
+++ b/src/tests/mix-test.c
@@ -202,7 +202,7 @@ static void compare_block(const pa_sample_spec *ss, const
pa_memchunk *chunk, in
for (i = 0; i < chunk->length / pa_frame_size(ss); i++) {
float uu = ss->format == PA_SAMPLE_FLOAT32NE ? *u :
PA_FLOAT32_SWAP(*u);
-fail_unless(fabs(uu - *v) <= 1e-6, NULL);
+fail_unless(fabsf(uu - *v) <= 1e-6f, NULL);
++u;
++v;
}
@@ -215,7 +215,7 @@ static void compare_block(const pa_sample_spec *ss, const
pa_memchunk *chunk, in
for (i = 0; i < chunk->length / pa_frame_size(ss); i++) {
float uu = ss->format == PA_SAMPLE_FLOAT32NE ? *u :
PA_FLOAT32_SWAP(*u);
-fail_unless(fabs(uu - *v) <= 1e-6, NULL);
+fail_unless(fabsf(uu - *v) <= 1e-6f, NULL);
++u;
++v;
}
@@ -385,7 +385,7 @@ static pa_memblock* generate_block(pa_mempool *pool, const
pa_sample_spec *ss) {
for (i = 0; i < 10; i++)
u[i] = PA_FLOAT32_SWAP(float_samples[i]);
} else
- memcpy(d, float_samples, sizeof(float_samples));
+memcpy(d, float_samples, sizeof(float_samples));
break;
}
--
1.9.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 2/3] core: Fix PA_MAYBE_INT16_SWAP() macro
PA_MAYBE_INT16_SWAP() should call PA_INT16_SWAP(), not PA_INT32_SWAP
PA_MAYBE_INT16_SWAP() is not used (yet), so no big deal :)
Signed-off-by: Peter Meerwald
---
src/pulsecore/endianmacros.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/pulsecore/endianmacros.h b/src/pulsecore/endianmacros.h
index 2b18cf8..4822fc4 100644
--- a/src/pulsecore/endianmacros.h
+++ b/src/pulsecore/endianmacros.h
@@ -82,8 +82,8 @@ static inline float PA_FLOAT32_SWAP(float x) {
return t.f;
}
-#define PA_MAYBE_INT16_SWAP(c,x) ((c) ? PA_INT32_SWAP(x) : (x))
-#define PA_MAYBE_UINT16_SWAP(c,x) ((c) ? PA_UINT32_SWAP(x) : (x))
+#define PA_MAYBE_INT16_SWAP(c,x) ((c) ? PA_INT16_SWAP(x) : (x))
+#define PA_MAYBE_UINT16_SWAP(c,x) ((c) ? PA_UINT16_SWAP(x) : (x))
#define PA_MAYBE_INT32_SWAP(c,x) ((c) ? PA_INT32_SWAP(x) : (x))
#define PA_MAYBE_UINT32_SWAP(c,x) ((c) ? PA_UINT32_SWAP(x) : (x))
--
1.9.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Slackware 14.1
Let me start over: I first installed pulseaudio and what I *think/assume* were it's dependencies, 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
[pulseaudio-discuss] Slackware 14.1
I'm having a problem getting pulseaudio to work. /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 /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. -- In God we trust. <>< ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Slackware 14.1
Starting pulseaudio... No protocol specified E: [pulseaudio] client-conf-x11.c: xcb_connection_has_error() returned true On Tue, Aug 5, 2014 at 10:28 AM, terry wrote: > I'm having a problem getting pulseaudio to work. > > /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 > > /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. > > > > -- > In God we trust. > <>< > > -- In God we trust. <>< ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Slackware 14.1
reading /etc/pulse/daemon.conf and I see "daemonize = no" (is that supposed to be?) On Tue, Aug 5, 2014 at 10:28 AM, terry wrote: > I'm having a problem getting pulseaudio to work. > > /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 > > /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. > > > > -- > In God we trust. > <>< > > -- 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
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. 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. Proposal 2 solves additionally the problem of too many streams in mixer UIs, so that's not made redundant by proposal 3. If someone is willing to implement the substream concept, great. [1] http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/19752/focus=20703 -- 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 12:10, Alexander E. Patrakov wrote: > 06.08.2014 12:15, Arun Raghavan wrote: >> >> On 6 August 2014 10:28, Alexander E. Patrakov wrote: [...] >>> 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. 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. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
