Re: [pulseaudio-discuss] Question about Pulseaudio hardware abstraction

2020-04-29 Thread Georg Chini 

On 29.04.20 10:57, Jim Kent wrote:


I have a question about how Pulseaudio functions between sound 
hardware and applications in Linux and spins. I noticed both Firefox 
and Chromium internally report many hardware details, including the 
sound output chipset and connected Bluetooth devices (with unique 
identifiers).


I am not sure this information is taken from pulseaudio. If you do 
"pactl list sinks", you can

see what is exposed to clients.

I assumed that Pulseaudio behaved as an opaque interface between 
software and hardware, in other words, applications send and receive 
inputs and outputs to Pulseaudio, which in turn mixes and exclusively 
communicates with sound hardware. Instead, I have noticed many 
instances where browsers exhibit unintended control over sound 
outputs, for instance, playing a youtube video will sometimes abruptly 
disconnect a Bluetooth headset.


This sounds weird and I never heard about such a behavior. If the 
browser is doing such things it is certainly
not through PA. A disconnect may happen if there are issues with the 
bluetooth connectivity, but in that case

the problem should not be application related and is below the PA level.


Is this behavior by design? Is it possible to sandbox applications 
from the sound hardware so that they only communicate and have a view 
of Pulseaudio, rather than the underlying hardware? Could something 
like Jack accomplish this?




___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Question about Pulseaudio hardware abstraction

2020-04-29 Thread Pali Rohár 
On Wednesday 29 April 2020 01:57:14 Jim Kent wrote:
> Is it possible to sandbox applications from the
> sound hardware so that they only communicate and have a view of Pulseaudio,
> rather than the underlying hardware?

Yes, you need to disallow access to /dev/snd/... devices for your
application. E.g. by permissions, ACLs or MAC (selinux / apparmor) or by
chrooting (without providing these devices) or running in container
(again without those devices). Just choose your favourite sandboxing
technique.

> Could something like Jack accomplish this?

No, application can again ignore jack and access sound hardware, just
like it did with pulseaudio.

You can e.g. play with "amixer" application. If you run it as
"amixer -D pulse" it will connect to pulseaudio (via unix socket) and
show mixer control which pulseaudio told it. If you run it with
"amixer -c 0" it will directly access sound card 0 (via /dev/snd/...)
and show state of sound card 0.

-- 
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss