Created attachment 359169 [details] [review]
sbcdepay: Add property to ignore input timestamps

This then just counts samples and calculates the output timestamps based
on that and the very first observed timestamp.

When receiving data via Bluetooth, many devices put completely wrong
values into the RTP timestamp field. For example iOS seems to put a
timestamp in milliseconds in there, instead of something based on the
current sample offset (RTP clock-rate == sample rate).

Like a reverse "perfect-rtptime" of the audio payloader base class? :)

Created attachment 359726 [details] [review]
sbcdepay: Add property to ignore input timestamps

This then just counts samples and calculates the output timestamps based
on that and the very first observed timestamp. The timestamps on the
buffers are continued to be used to detect discontinuities that are too
big and reset the counter at that point.

When receiving data via Bluetooth, many devices put completely wrong
values into the RTP timestamp field. For example iOS seems to put a
timestamp in milliseconds in there, instead of something based on the
current sample offset (RTP clock-rate == sample rate).

Any opinions on this otherwise?

I have nothing against, but was thinking we are not the first to have to deal with that. Have you research what PulseAudio would do to survive this ?

Arun told me that they completely ignore RTP timestamps for Bluetooth.

Noted, thanks. Feel free to go ahead.

Attachment 359726 [details] pushed as 58f0eab - sbcdepay: Add property to ignore input timestamps