Enable dbus delay signals for internal processing delay.

[borine]

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]

Codecov Report

Attention: Patch coverage is 84.21053% with 6 lines in your changes missing coverage. Please review.

Project coverage is 70.44%. Comparing base (e00c1a5) to head (3c14b48).

Files with missing lines	Patch %	Lines
src/ba-transport-pcm.c	83.33%	4 Missing ⚠️
test/test-a2dp.c	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #734      +/-   ##
==========================================
+ Coverage   70.39%   70.44%   +0.04%     
==========================================
  Files          96       96              
  Lines       16025    16047      +22     
  Branches     2515     2520       +5     
==========================================
+ Hits        11281    11304      +23     
+ Misses       4625     4624       -1     
  Partials      119      119              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[arkq]

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).

[arkq]

I can see that you've used ba_transport_pcm_delay_sync to notify everyone about delay change, but the ba_transport_pcm_delay_sync function does not have any hysteresis/throttling for sending D-Bus signals (it has that for updating BlueZ Delay property). I think that at least some kind of hysteresis might be required there otherwise we will DDoS D-Bus daemon :D

[arkq]

During testing I've discovered one issue (thanks to this PR). The processing delay calculated in the encoder loop takes into account the BT write time, which in case of BT connection instability might increase much (up to BT connection timeout). So, before pushing this into the master I will have to think about changing the place where the delay is calculated (maybe it should be calculated before BT write, to account codec processing only, since it's named processing_delay_dms :D). The case is, that right now, when the BT socket is almost full, the "processing_delay_dms" value jitters beyond 10ms which still floods D-Bus. However, the logic in this PR is OK for me as it is.