search

arkq / bluez-alsa

Bluetooth Audio ALSA Backend
MIT License
864 stars 189 forks source link

Enable dbus delay signals for internal processing delay. #734

Open borine opened 3 weeks ago

borine commented 3 weeks ago

I've raised this as a draft PR for discussion because:

  1. I'm not sure if there is a reason why D-Bus signalling was omitted originally.
  2. I'm not sure of the GIO dbus thread handling. This solution emits dbus signals from the transport I/O thread, but without any locking. Is that safe?
  3. My choice of a 10ms difference threshold to limit the rate that signals can be emitted is entirely arbitrary with no specific evidence to justify it.
codecov[bot] commented 3 weeks ago

Codecov Report

Attention: Patch coverage is 91.66667% with 2 lines in your changes missing coverage. Please review.

Project coverage is 70.44%. Comparing base (f93a6e8) to head (79c4b9c).

Files with missing lines Patch % Lines
test/test-a2dp.c 0.00% 2 Missing :warning:
Additional details and impacted files ```diff @@ Coverage Diff @@ ## master #734 +/- ## ========================================== + Coverage 70.30% 70.44% +0.14% ========================================== Files 96 96 Lines 15799 15967 +168 Branches 2502 2504 +2 ========================================== + Hits 11107 11248 +141 - Misses 4575 4602 +27 Partials 117 117 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

arkq commented 3 weeks ago

I'm not sure if there is a reason why D-Bus signalling was omitted originally.

It was omitted due to lack of time to implement that :D Many thanks for that!

I'm not sure of the GIO dbus thread handling. This solution emits dbus signals from the transport I/O thread, but without any locking. Is that safe?

Yes, it should be safe. Internally signal is just a D-Bus message, and messages are sent by g_dbus_connection_send_message which is thread safe.

My choice of a 10ms difference threshold to limit the rate that signals can be emitted is entirely arbitrary with no specific evidence to justify it.

I'm going to use such delay for the client-delay signaling as well and it's also arbitrary decision (based on commersial headset delay report updates). However, during testing, I've also added time-rate limiting logic (https://github.com/arkq/bluez-alsa/pull/516/files#diff-8bfb2124e7db1e5681c384f69b807d2a22821e0db287cab13d9ea0eb000cff81R827) because during playback start I could unnecessarily flood other device with lots of delay reports (the 1s rate limit is also based on some commercial headset). It's implemented on the client side, but maybe it should be moved to the bluealsad... I'll have to check how this delay report signaling will work with your PR. I hope that the client-delay will be merged soon (after support on BlueZ side will fully land in upstream).