Re: gnome-sdk update and TODOs
- From: Bastien Nocera <hadess hadess net>
- To: Alexander Larsson <alexl redhat com>
- Cc: gnome-os-list <gnome-os-list gnome org>
- Subject: Re: gnome-sdk update and TODOs
- Date: Fri, 12 Dec 2014 17:42:33 +0100
On Fri, 2014-12-12 at 17:08 +0100, Alexander Larsson wrote:
On fre, 2014-11-28 at 16:07 +0100, Alexander Larsson wrote:
* Audio
There is no audio support atm. Neither alsa libs, not device nodes.
I think the best approach is to use pulseaudio, but this needs
careful consideration in terms of ABI/IPC compat, performance,
latency, etc.
Today I looked at audio via pulseaudio. This is kind of tricky, it seems
to me like the pulseaudio protocol follows the X11 style permissions
method. I.e. if you're able to authenticate to the daemon you have full
privs, including loading modules into the daemon.
Furthermore, the "normal" mode of using shared memory to send audio
relies on a single global /dev/shm, which breaks with any kind of
containerization and allows any client to read any other clients data.
I don't see why theoretically pulseaudio couldn't allow shared memory
buffers in a contained mode, via e.g. fd passing of the shared memory
instead of a shared namespace. However, anything like this involves
upstream changes to the protocol. For now i'm disabling shared memory
in the app, which is not ideal but at least allows apps to play sounds.
Lennart did mention that PulseAudio could make use of kdbus for passing
buffers around, and I guess that Wim's "PulseVideo" (for the lack of a
better name) could also make use of it.
Finer permissions are necessary in any case. You can probably allow any
app to play sound, but you might not want to allow microphone access to
most applications.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]