This starts breaking up the giant monolith that is the pulse-server.c
code into more manageable chunks by trying to split the module code into
individual compilation units.
The simple protocol listens on a socket, creates a new pw_client for
each connected client and reads/writes raw audio bytes on the
socket. Incomming bytes are copied to a playback stream, outgoing
bytes are copied from a capture pw_stream.
Fixes#954
This access module now only checks if the connection is comming
from the portal and tags the ACCESS property with portal in that
case. It will no longer do permission store checks, that's for
the session manager.
This makes it easier to test PipeWire in its "as-installed" state,
for example in an OS distribution.
The .test metadata files in ${datadir}/installed-tests/${package} are
a convention taken from GNOME's installed-tests initiative, allowing a
generic test-runner like gnome-desktop-testing to discover and run tests
in an automatic way.
The installation path ${libexecdir}/installed-tests/${package} is also
a convention borrowed from GNOME's installed-tests initiative.
In addition to the automated tests, I've installed example executables
in the same place, for manual testing. They could be separated into
a different directory if desired, but they seem like they have more
similarities with the automated tests than differences: both are there
to test that PipeWire works correctly, and neither should be relied on
for production use. Some examples are installed in deeper subdirectories
to avoid name clashes.
Signed-off-by: Simon McVittie <smcv@debian.org>
Add Profiler object and fields.
Add profiler extension API. It notifies Profiler objects with
real-time performance data.
Add module that implements the profiler extension.
Add pw-profiler tool that binds to the profiler API and dumps the
data into a log file, gnuplot files, a html page and a script to
generate svg graphs. This is almost the same as what JACK2
JackEngineProfiling does.
Metadata allows apps to attach properties to objects that can be
read by other apps.
Not complete yet, properties should be removed when the object is
removed.
For flatpaks we need to be able to support older v0 protocol clients.
To handle this we have:
- the connection detects an old client when it receives the first
message. It can do this by checking the sequence number, on old
versions it contains the message size and is never 0, on new
clients the sequence number is 0.
- We add a new signal at the start of the connection with the detected
version number. This installs the right version of the core proxy.
We also move the binding of the client until the hello message is
received. This way we can have a new client connect (portal),
hand over the connection to an old client, which then removes the
client binding again in the hello request with a v0 version.
There are some changes to the passing of fds in v0 vs v3 which need
to investigated some more.
- bump version of our interfaces to 3. This makes it possible to
have v0 and v3 protocol marshal functions.
- Add version number in the proxy. This is mostly automatically done
internally based on the version numbers the library is compiled
with. Where the version number was in the API before, it is now
actually used to look up the right protocol marshal functions. For
Proxies there is usually just 1 version, the current one. It is the
server that will support different versions.
- Add v0 compat marshal functions to convert from and to v0 format.
This has some complications. v0 has a type map it keeps in sync
with the server. For this we have a static type map with mappings
to our own v3 types. Pods are mostly the same except for objects
that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also
convert between v0 spa_pod_prop and v3 spa_pod_choice.
Formats and commands are also slightly different so handle those
mappings as well.
We only have marshal functions for the server side (resource)
v0 functions.
- Add v0 compatible client-node again. It's a bit tricky to map, v0
client-node basically lets the server to the mixing and teeing
and just does the processing of the internal node.
When the port receives a format, look if we can find a mixer for it
and configure it.
Use the float32 mono mixer when possible.
Use the new pw_buffers in the link.
Let the port allocate buffers between the mixer and node when
requested.
The client-node doesn't need a mixer because mixing is done on the
client.
Remove all mixer and buffer negotiation code from adapter because
it is now done at the port level.
Add a new PortConfig parameter to configure ports of elements that
are marked with the SPA_NODE_FLAG_*_PORT_CONFIG. This is used to
configure the operation of the audioconver/audioadapter nodes and
how it should convert the internal format. We want to use the
Profile parameter only for cases where there is an enumeration of
values, like with device configuration.
Add unit tests for audioconvert and adapter to check if they handle
PortConfig correctly.
Make the media session use the PortConfig to dynamically configure
the device nodes.
Remove audio-dsp, it is not used anymore and can/should be implemented
with a simple audioconvert spa node now and some PortConfig.
Use an adapter instead of the client-stream. This means we run
the audioconverters and resamplers in the client instead of the
pipewire daemon. It also allows us to implement the audio mixing
correctly in the capture client.
The only pending piece is that we now wake up the client with the
period of the server. Maybe we can later optimize that and
accumulate/split buffers before waking the client.
This probably needs fixing with video..
An adapter is like an audio-dsp node and client-stream combined.
It allows tighter control with the device (for rate control and
variable buffer sizes), software volume.
The idea is to also implement the client-stream with this
eventually.
Make the code to export objects more generic. Make it possible for
modules to register a type to export.
Make the client-node also able to export plain spa_nodes.
Let the remote signal the global of the exported object if any. We can
then remote the (unused) remote_id from the proxy.
Rename the flatpak module to access module. The access module should
either let the client connect or mask the client busy while the
permissions are being configured. It is then up to the session manager
to collect the right permissions of the objects and configure those
in the client.
Let the media session monitor the clients and configure the permissions.
Make it possible to assign an arbitary node as the port mixer.
Also remove dynamically added ports.
Improve negotiation and allocation on the mixer ports
Add some more SSE optimisations
Move float mixer from the audio dsp to the port
Remove pw_node_get_free_port() and do things more explicitly.
Handle mixer ports in client-node
A client stream is a more specialized way to send 1 stream to pipewire.
On the client side and receiver side it can do conversion and the
buffer size of the client can be choosen arbitrarily.
Add an audio dsp module that adds an interleaver for each audio sink
and only allows 1 buffer size and format on the ports. The idea is that
dsp (pro-audio) nodes can be inserted in this part of the pipeline.
