When `val` was used, it was always a true-ish since the
address of an array on the stack was assigned to it.
Remove this variable altogether, and use `name` directly.
Only use `name` when it is valid - when `key && value`.
`impl->default_sink` is dynamically allocated, but previously
it was not freed when the containing struct was being destroyed.
Fix that by freeing it in `session_destroy()`.
There's no particular problem to have default.configured to point to a
non-existent device, it will be ignored. This was left over when
default and configured default were made separate things.
default-nodes also doesn't need to track the id of the configured
default, so remove also other stuff that's no longer necessary. It can
simply load the values to metadata on startup, and save them to a file
when they are changed, without needing to understand what the values
mean.
Also fixes commit 7071562334 causing defaults to be forgotten when
nodes are removed.
We only want to call process() from Start when we are not a driver and
not realtime.
When we are a driver, the user will need to call _trigger_process()
to kick things of.
When we are asked to schedule process from the realtime thread, we
need to wait until the RT thread is scheduled.
In all other cases we can call _process() from the mainloop so that
the RT thread has something to collect when it gets scheduled.
When the node is driving, we need to call trigger_process()
otherwise we don't and we simply need to wait for the process() to
be called, triggered by the driver node.
See #1484
It has the DRIVER flag set and sets a PW_KEY_PRIORITY_DRIVER value
to something higher than the source so that it becomes the driver.
Every timeout it does pw_stream_drive() to start the graph, which
will eventually call the process function with a pulled buffer to
display.
The framerate is set to something lower (80ms between frames) to
show the pull effect.
fixes#1484
This method is meant for driver streams when they have data or need
data.
Previously only source (output) streams could drive the graph and
indirectly by doing pw_stream_queue_buffer(). This behaviour is now
deprecated (but will still work) in favour of calling
pw_stream_drive() explicitly.
pw_stream_drive() will call the process function immediately (if
driver) or later (when not a driver) so that the same code paths
can be used when running as a driver or not.
In a similar way, a consumer (input) driver stream can now be
written. It will call pw_stream_drive() when it wants data and the
process function will be called when the data is ready.
See #1484
We need to check the position vs the clock to see if we are currently
driving the graph. We can only call the node ready callback when
we are actually driving the graph.
"restored" describes a state but the only case we actually set this
value if we want to restore our previously saved profile. Rename a
variable to indicate this, makes it easier to understand.
Add module that switches bluez device profile to HFP/HSP if an input
stream (non-monitor, autoconnect) appears, and the current default
output device is bluez one that does not have input route.
When all input streams are gone, switch all changed profiles back.
Pending restore state is saved to session manager state files, in order
to restore it if e.g. devices get disconnected. This usually is not
currently necessary since the bluez5 plugin prefers to connect to A2DP
over HFP, but might matter in future with backchannel-enabled A2DP
codecs.
This test needs an environment set up to load everything correctly,
running it directly results in a segfault. Let's make sure we assert on
a NULL loop to make this look slightly more planned.
Use the port_set_mix_info event to get the id of the peer port for the
mixer input.
When asked for the buffer of one of those peer ports, we can get it from
the mixer input buffers.
Fixes#1471
Add a new client-node port_set_mix_info event. bump the interface
version to 4 and the event version to 1.
The event is used to send information about the peer object to the
port mixer. This can be used to track what buffers belong to what
peer.
