On 2015-10-04 17:05, Zeno Endemann wrote:
Hi,
I have two suggestions how the device reservation can be improved for
app developers wanting to have exclusive access to an alsa card:
1.
I knew about this scheme only by accident, so I think the
discoverability should be improved. Adding a few li
Thx for review and changes, looks better indeed. I also confirm it still
works.
Cheers, Julien
On 19 October 2015 at 04:23, Arun Raghavan wrote:
> On Sat, 2015-10-10 at 20:11 +0100, Julien Isorce wrote:
> > fchmod is denied in chromium sandbox.
> > ---
> > src/pulsecore/core-util.c | 2 +-
> >
Thx for the review. Indeed I double checked and prctl should be blocked. It
seems in chromium gpu process and plugin process, they enable it that why
we did too. Though there is a todo saying to block it :)
In our case we can directly block it.
For my patch it means the condition "prctl(PR_GET_SEC
On Mon, 2015-10-19 at 09:37 +0200, David Henningsson wrote:
>
> On 2015-10-04 17:05, Zeno Endemann wrote:
> > 2.
> > The spec implies that the reservation is for a whole device (ie. alsa
> > card), so I believe a well-behaving client should not touch a reserved
> > alsa card in any way. But PA onl
On 2015-05-21 12:36, Tanu Kaskinen wrote:
On Thu, May 21, 2015, at 11:46, David Henningsson wrote:
This patch looks broken: Profile availability is not a boolean, it's a
tristate (yes/no/unkown).
In the libpulse API it's a boolean, however. I think it should be
boolean in the D-Bus API too.
Pushed now. Thanks for the contribution!
On 2015-04-19 16:29, John Horan wrote:
---
src/modules/dbus/iface-device-port.c | 65 ++--
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git a/src/modules/dbus/iface-device-port.c
b/src/modules/dbus/iface-dev
We currently only support one and two channels for volumes, and
bail out otherwise. This makes Xonar users unhappy because they
have a volume with eight channels, and bailing out means they
don't have a path/port at all.
This way they will at least have a port, which will in turn make
the gnome/un
19.10.2015 14:16, David Henningsson wrote:
We currently only support one and two channels for volumes, and
bail out otherwise. This makes Xonar users unhappy because they
have a volume with eight channels, and bailing out means they
don't have a path/port at all.
This way they will at least have
Hi folks,
Thought I'd restart this thread since it's been a while. Let me
summarise the discussion so far.
The decision to use flat-volumes has certainly been controversial.
However, I'm convinced it provides a better user experience than the
standard model of having separate per-app and device vo
19.10.2015 14:49, Arun Raghavan wrote:
Hi folks,
Thought I'd restart this thread since it's been a while. Let me
summarise the discussion so far.
The idea is that only controlling the stream within the application's
volume slider would have this non-flat behaviour. Mixer applications
such as pav
On Mon, 2015-10-19 at 15:19 +0530, Arun Raghavan wrote:
> Hi folks,
> Thought I'd restart this thread since it's been a while. Let me
> summarise the discussion so far.
>
> The decision to use flat-volumes has certainly been controversial.
> However, I'm convinced it provides a better user experie
On Mon, 2015-10-19 at 13:30 +0300, Tanu Kaskinen wrote:
> On Mon, 2015-10-19 at 15:19 +0530, Arun Raghavan wrote:
> > * I'm inclined to keep the implementation of the relative volume
> > calculation server-side,
>
> If we want a policy module to be able to enforce the behaviour at the
> server sid
On 19 October 2015 at 05:41, Tanu Kaskinen wrote:
>> (Side note: I would have liked to see the device reservation protocol on
>> the system bus instead of the session one, but that's likely too late to
>> change now)
>
> I think it's probably possible to do the transition to the system bus,
> if w
On Tue, 2015-05-05 at 17:01 +0200, David Henningsson wrote:
> It can be useful for routing modules to know if a profile consists
> of an output and input part, in order to e g change output profile
> while keeping the input profile unchanged.
n_sinks and n_sources already tell if a profile consist
On 2015-10-19 15:56, Tanu Kaskinen wrote:
On Tue, 2015-05-05 at 17:01 +0200, David Henningsson wrote:
It can be useful for routing modules to know if a profile consists
of an output and input part, in order to e g change output profile
while keeping the input profile unchanged.
n_sinks and n
On Mon, 2015-10-19 at 16:11 +0200, David Henningsson wrote:
>
> On 2015-10-19 15:56, Tanu Kaskinen wrote:
> > On Tue, 2015-05-05 at 17:01 +0200, David Henningsson wrote:
> > > It can be useful for routing modules to know if a profile consists
> > > of an output and input part, in order to e g chan
Hi all,
Now that we are talking about flat volumes again (but I don't want to
hijack the other thread), I would like to present another alternative to fix
the problems with flat-volumes.
The idea is that all apps, by default, operate in non-flat volume mode.
This means all volume control done fro
On 2015-10-19 16:32, Tanu Kaskinen wrote:
On Mon, 2015-10-19 at 16:11 +0200, David Henningsson wrote:
On 2015-10-19 15:56, Tanu Kaskinen wrote:
On Tue, 2015-05-05 at 17:01 +0200, David Henningsson wrote:
It can be useful for routing modules to know if a profile consists
of an output and inp
19.10.2015 19:38, Wim Taymans wrote:
Hi all,
Now that we are talking about flat volumes again (but I don't want to
hijack the other thread), I would like to present another alternative to fix
the problems with flat-volumes.
The idea is that all apps, by default, operate in non-flat volume mode.
On Mon, 2015-10-19 at 17:11 +0200, David Henningsson wrote:
>
> On 2015-10-19 16:32, Tanu Kaskinen wrote:
> > On Mon, 2015-10-19 at 16:11 +0200, David Henningsson wrote:
> > >
> > > On 2015-10-19 15:56, Tanu Kaskinen wrote:
> > > > On Tue, 2015-05-05 at 17:01 +0200, David Henningsson wrote:
> > >
>>
>> We currently only support one and two channels for volumes, and
>> bail out otherwise. This makes Xonar users unhappy because they
>> have a volume with eight channels, and bailing out means they
>> don't have a path/port at all.
>>
>> This way they will at least have a port, which will in tu
On 19 Oct 2015 09:37:05 +0200, David Henningsson wrote:
> On 2015-10-04 17:05, Zeno Endemann wrote:
>> Hi,
>>
>> I have two suggestions how the device reservation can be improved for
>> app developers wanting to have exclusive access to an alsa card:
>>
>> 1.
>> I knew about this scheme only by acc
Seccomp-BPF uses SIGSYS signal to trigger
the trap handler attached to sys_open.
If the signal is blocked then the kernel kills
the process whenever pulse audio calls 'open'.
The result backtrace is terminating in sys_open.
That's why it is required to keep SIGSYS unblocked
if it is currently unbl
On Tue, 2015-05-05 at 17:01 +0200, David Henningsson wrote:
> Signed-off-by: David Henningsson
> ---
> src/pulsecore/device-port.c | 1 +
> src/pulsecore/device-port.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/src/pulsecore/device-port.c b/src/pulsecore/device-port.c
> index cfe
On Tue, 2015-05-05 at 17:01 +0200, David Henningsson wrote:
> diff --git a/src/modules/module-card-restore.c
> b/src/modules/module-card-restore.c
> index 5c55cec..5d278c1 100644
> --- a/src/modules/module-card-restore.c
> +++ b/src/modules/module-card-restore.c
> @@ -375,8 +385,44 @@ finish:
>
On Tue, 2015-05-05 at 17:01 +0200, David Henningsson wrote:
> diff --git a/src/modules/module-switch-on-port-available.c
> b/src/modules/module-switch-on-port-available.c
> index eb8f2d7..8de68a3 100644
> --- a/src/modules/module-switch-on-port-available.c
> +++ b/src/modules/module-switch-on-port
On Mon, 2015-10-19 at 16:38 +0200, Wim Taymans wrote:
> Hi all,
>
> Now that we are talking about flat volumes again (but I don't want to
> hijack the other thread), I would like to present another alternative
> to fix
> the problems with flat-volumes.
>
> The idea is that all apps, by default, o
On Mon, 2015-10-19 at 13:30 +0300, Tanu Kaskinen wrote:
> On Mon, 2015-10-19 at 15:19 +0530, Arun Raghavan wrote:
> > Hi folks,
> > Thought I'd restart this thread since it's been a while. Let me
> > summarise the discussion so far.
> >
> > The decision to use flat-volumes has certainly been contr
On Mon, 2015-10-19 at 15:30 +0500, Alexander E. Patrakov wrote:
> 19.10.2015 14:49, Arun Raghavan wrote:
[...]
> > * I'd also like to add a policy module to allow blacklisting
> > specific
> > applications, and forcing this behaviour on them. This will need a
> > protocol update to set a stream fla
On Tue, 2015-10-20 at 10:34 +0530, Arun Raghavan wrote:
> On Mon, 2015-10-19 at 13:30 +0300, Tanu Kaskinen wrote:
> > On Mon, 2015-10-19 at 15:19 +0530, Arun Raghavan wrote:
> > > * We add a new stream volume API -- pa_stream_get_volume(),
> > > pa_stream_set_volume(), pa_stream_set_volume_callback
On 2015-10-19 14:27, Felipe Sateler wrote:
On 19 October 2015 at 05:41, Tanu Kaskinen wrote:
(Side note: I would have liked to see the device reservation protocol on
the system bus instead of the session one, but that's likely too late to
change now)
I think it's probably possible to do the
31 matches
Mail list logo
