Always reschedule the timeout based on the new quantum. If the
quantum descreased we want to wait some more until the buffer only
has the new quantum of samples left.
Only adjust the timeout when the quantum increases so that we end u
with exactly the number of samples of the new quantum.
Suppose we are handling a quantum of 1024, we wake up with 1024
samples in the device, we now notice a quantum of 8192 and will pull
in the 8192 samples, we then have 1024 + 8192 samples in the buffer.
Schedule a timeout for 1024 samples so that we end up in the timout
with 8192 samples in the device.
Remove some magic constants that are not needed anymore with the
headroom.
Clamp the error to some reasonable value so that we don't adjust the
rate too much but still apply all of the correction calculated by the
dll.
Remove the bandwidth adjustment.
Also update the matching and resample fields when we reassign the
node to a new driver. This could cause the new follower to not activate
the adaptive resampler and get out of sync.
node.latency also influences the pipeline latency in that it can
push the latency above the default value.
node.max-latency, instead, is only used to clamp the final latency
of the pipeline.
This may avoid infinite loops if parameters are being set based on events
sent by parameter changes. It's also what alsa-acp devices do, so bluez5
should follow.
This will prevent to run the different backends concurrently.
The native backend will only register to BlueZ if neither oFono nor
hsphfpd are running. If one of them starts, the native backend will be
unregistered and the corresponding backend will register to its daemon.
Make queueing a codec switch work properly. When receiving the dbus
reply, it should move to latest one. Others should be discarded.
Previously, it instead hit an assert, if there were more than two
queued.
When we have a rate or channels configured, set this in the hw_params
to restrict the enumeration of the remaining parameters. If we,
for example want 8 channels, some cards restrict the formats in that
case and we don't want to enumerate impossible combinations.
Fixes#782
Add save property to Profile and Route params to notify the session
manager that they should be saved. Let the session manager only save
the Profile and Routes with the save flag.
Make pulse-server set the save flag on Profile and Route changes.
The result is that we can make a difference between user requested
changes and automatical changes and only remember the user preferences.
When a port changes availability, first check if we need to perform
a profile switch, if not select the new best port.
Keep track of the param changes with the user counter. Make sure to
flip the serial switch whenever a change is pending. Previously
we copied the param from the channelmixer or follower but that
did not always result in a serial change.
Fixes#764
Not all devices report their A2DP delay. In those cases, use a fallback
value of 150ms by default.
Make the delay adjustable with a SPA_Prop, and expose it as a part of
the route. Implement the corresponding parts in media-session.
Keep track of the subelement we're iterating in the result index upper
bits. Use enum_sync to iterate each param and switch to the next
element when we run out of params.
See !468
In BT_DEFER_SETUP mode, when a connection is accepted, the listening
socket is unblocked but the effective connection setup happens only on
first receive, allowing to configure the accepted socket.
First read from the accepted socket is non-blocking and returns a zero
length buffer.