SNAP containers have two main "audio" security rules:
* audio-playback: the applications inside the container can
send audio samples into a sink
* audio-record: the applications inside the container can
get audio samples from a source
Also, old SNAP containers had the "pulseaudio" rule, which just
exposed the pulseaudio socket directly, without limits. This
is similar to the current Flatpak audio permissions.
In the pulseaudio days, a specific pulseaudio module was used
that checked the permissions given to the application and
allowed or forbade access to the pulseaudio operations.
With the change to pipewire, this functionality must be
implemented in pipewire-pulse to guarantee the sandbox
security.
This patch adds support for sandboxing permissions in the
pulseaudio module, and implements support for the SNAP audio
security model, thus forbiding a SNAP application to record
audio unless it has permissions to do so.
The current code for pipewire-pulseaudio checks the permissions
of the snap and adds three properties to each new client:
* pipewire.snap.id: contains the Snap ID of the client.
* pipewire.snap.audio.playback: its value is 'true' if the client
has permission to play audio, or 'false' if not.
* pipewire.snap.audio.record: its value is 'true' if the client
has permission to record audio, or 'false' if not.
These properties must be processed by wireplumber to add or
remove access permissions to the corresponding nodes. That
code is available in a separate patch: https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/567
Add a /core message to set the log level of the pulse-server.
An alternative would be to watch the settings metadata and follow the
server settings. This is however less flexible so the custom message
was chosen.
Add a function to check if a specfic custom log level has been defined
for a topic.
We can use this to dynamically check if we need to do the connection debug
messages.
We can also get rid of the conn.* pattern hack to disable connection
messages by default.
get_device_info() requires us to call update_object_info() in the added
and updated events.
Fixes a bug where the properties were invalid in the avahi txt record.
That is indeed 0 for nearly any device. However the NTP value in the session identification part plays a crucial role for distinguishing between streams in some implementations, e.g. Dante.
Dante Controller does not recognize next stream having the same NTP value. Work around that by adding current number of sessions to the time and the magic value.
Co-authored-by: Dewi Seignard <dewiweb@gmail.com>
This should be done to match packet size requirements (e.g. 1 ms) while allowing user's software to run at higher buffer size to not stutter.
This will require scheduling multiple rtp_audio_flush_packets calls per one rtp_audio_process_capture call
The monitor sources also list the port of the sink and so the active
port needs to be collected as well so it doesn't fall back to the first
port (which might not be available).
Check for errors when loading the geometry instead of silently failing.
The points need to be given in the user locale and so might fail to
parse when given in JSON format.
Format the geometry nicely when loading the module.
Some AirPlay devices will announce their IPv4 addresses
over IPv6 mDNS if both are available, so the determined
IP version was not reliable.
The prop is not used by module-raop-sink, so its
removal should be safe.
The Pro Link 1 replies with Audio-latency=0, patch that up to
1500ms to make it work again.
Previously it configured 1500ms as the default latency but that seems
unnecessary in the usual case.
Fixes#3698
We always need to add the Props param because it contains the
debug.aec.wav-path key, which is always available, even when the AEC
implementation has no properties.
Also add the debug.aec.wav-path PropInfo.
