Bluetooth: mSBC workaround code for kernel problem on pre 5.9/5.10 kernels produces garbled audio while recording

System Setup

• Ubuntu 20.04 / Linux version 5.4.0-59-generic
• Pipewire 0.3.19
• Ofono

Observation:

• After enabling mSBC in media-config, the recorded audio is garbled

Expected behaviour:

• Have good audio

Analysis:

Apparently, all-zero packets (i.e. 48 zeros in the packet) get inserted into the packet stream somewhere (kernel?) which do not have anything to do with the payload data stream.

And this "augmented" stream is then processed in the following way in sco-source.c, function sco_source_cb():

• The "workaround" code in msbc_buffer_append_byte() searches for the mSBC packet header
• When it identifies the packet header, it starts moving the packet to an interim buffer and moves all the data until the end of the (current) packet
• When the next packet arrives, msbc_buffer_append_byte() just continues to add bytes to the interim buffer until the msbc interim buffer has reached the size on the encoded MSBC packet (MSBC_ENCODED_SIZE). The surprising thing: When the packet is an (non-paylod) "all-zero" packet, then this means that "rest" of the msbc interim buffer is filled with zeros, leading to a "faulty" msbc packet
• But: Those "faulty" msbc packets are not detected as faulty by sbc_decode() checksum calculations (I don't exactly understand how/why that is the case) - sbc_decode just processes them happily
• The msbc_buffer_append_byte() then waits for the next packet header - and then starts processing. Because of this, the sequence number checks work out and there are no errors/warnings in the log.

Proposed "fix" (works for me):

• Change the code in sco-source.c: Check if the raw input packet consists of "all zeros". If this is the case, just ignore the input packet.