When we receive volume updates with a different number of channels
than we are configured for, remap them to our number of channels.
This currently involves taking the average volume until we actually
have a channelmap associated with the volume updates.
See #320
When a port is plugged/unplugged, first update all the profile states
and then emit a profile change only for the current profile. This way
the device can look at all the updated profiles to select the best one.
Some drivers seem to only use 2 buffers when asked for 16 buffers. We
can see this because the buffer is already queued. In this case, just
use the 2 buffers.
See #294
When we have accurate enough hardware volume, set the software volume to
1.0. Also fixes the issue of going to 0 volume and then staying silent
until we raise the volume above 1.0.
The flag means that the process function might not complete
synchronously.
We can use this knowledge to improve the adapter. In sync mode we
can pull before scheduling the converter. In async mode we need to
schedule the follower after the converter to get the data ready for
the next iteration.
We can also improve the stream when it is operating async to schedule
a process call when a new buffer is ready to be filled.
This reduces a cycle latency from alsa and improves latency in
pulse.
Handle the case where the converter in a source needs more output
buffers (-EPIPE). Schedule the follower in that case and try to
run the converter again until we have output or we can't make progress
anymore.
If the converter needs more data, schedule the follower before we
exit the loop with the data. This gives the follower a chance to get
more data asynchronously for the next iteration.
If we are already in the loop thread and flushing, this means we
added a new invoke item on the list from a callback. Place the
item on the queue and let the flush code take care of it after the
callback completes.
Required to fix some issues with draining in pulse where a stream
is destroyed from the drained callback which then invokes a pause.
Release transport when endpoint connection property is updated to false.
This also checks if the transport is already created when receiving
endpoint properties update to prevent multiple transport creation.
Because the signal can't be removed from the callback we can
simply iterate backwards and then forwards.
The first added hook (the unlock/lock pair) is called last before
going into the poll and first when leaving. This executes all other
callbacks inside a locked situation. And removing them with the lock
is not going to cause problems.
Use a safer version of the before and after hooks. First call
all before hooks and save them in reverse order in a save list.
Then call the after event for the ones remaining in the save list
and move them back to the hook list.
This makes it possible to remove the hooks from one the callbacks or
even from other threads with the right locks. Found as a solution to
the following problem as observed in vlc:
main thread thread_loop
pw_thread_loop_lock() before hook: lock suspend thread
pw_context_destroy()
- removes before hook to flush clients
pw_thread_loop_unlock()
before hook: lock acquired, resume
before hook: flush client hook executed
*crash*
pw_thread_loop_stop()
pw_thread_loop_destroy()
Any of the safer cursor methods (like spa_hook_list_call()) would also
work but are more expensive and don't reverse the before/after
order.
Don't change the resampler delay value, we need it to make sure
we keep samples around for the next round. With small period sizes,
we set the delay to 0 and mess up the resampler and cause dropouts
and clicking.
Fixes#287
