[pulseaudio-discuss] Bluetooth A2DP AAC passthrough?

[Pierre-Louis Bossart]

On 5/2/16 8:50 AM, Arun Raghavan wrote:
> On 2 May 2016 at 19:06, Pierre-Louis Bossart
> <pierre-louis.bossart at linux.intel.com> wrote:
>> On 4/29/16 10:17 PM, Arun Raghavan wrote:
>>>
>>> On 29 April 2016 at 18:57, Tanu Kaskinen <tanuk at iki.fi> wrote:
>>>>
>>>> On Wed, 2016-04-27 at 16:53 +0200, Nicole Færber wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I know this has been a topic several times now. I searched the
>>>>> mailinglist archives, FAQ, current GIT and other internet resources for
>>>>> a practical way with current versions of BlueZ5 and Pulse Audio but it
>>>>> seems that most proposed patches have been dropped, am I correct with
>>>>> this assessment?
>>>>>
>>>>> My personal goal would be to have a mode to playback AAC content to a
>>>>> paired and connected A2DP device capable of A2DP-AAC - in my case a
>>>>> Parrot Zik2.0. If such a way already exists I would be really happy for
>>>>> an advice on how to actually use it, e.g. using paplay?
>>>>>
>>>>> If such a mode does not yet exist are there plans to implement other
>>>>> codecs? At least as pass-through? What is needed? Is it already being
>>>>> worked on? Can I give a hand? As usual time is limited and my knowledge
>>>>> on A2DP and especially Pulse Audio is limited but I am willing to help.
>>>>
>>>>
>>>> Compressed audio passthrough with bluetooth is not supported. I think
>>>> the feature would be welcome, though. I'm not aware of anyone working
>>>> on it.
>>>>
>>>> We already support compressed passthrough with alsa, so it's not
>>>> necessary to start from absolute scratch. Alsa wants compressed audio
>>>> wrapped in "IEC 61937" encapsulation, and that format also makes it
>>>> easier for pulseaudio to deal with the data, because the encapsulation
>>>> makes it possible to convert between number of bytes and time (that is,
>>>> a certain number of bytes always corresponds to the same amount of
>>>> time, which isn't true with plain AAC audio). For that reason we
>>>> require applications to do the encapsulation, so pulseaudio doesn't
>>>> have to do any changes to the data.
>>>>
>>>> I suppose bluetooth doesn't use the IEC 61937 encapsulation, so the
>>>> question arises if we should use it in pulseaudio when doing
>>>> passthrough with bluetooth. I think it would make sense to use
>>>> encapsulation at least in the initial implementation, because that
>>>> would then retain the nice property that we don't have to understand
>>>> anything about the AAC format as such. The bluetooth module would then
>>>> have to do the unpacking of the AAC data from the IEC 61937
>>>> encapsulation, which hopefully is reasonably straightforward.
>>>
>>>
>>> Pierre-Louis Bossart did a PoC based on this and I'd expanded on this
>>> a while back, for MP3:
>>>
>>>   https://cgit.freedesktop.org/~arun/pulseaudio/log/?h=bt-passthrough
>>>
>>> However, this is a hack and doesn't make sense as the solution we
>>> upstream.
>>>
>>> We need to be able to deal with compressed audio as-is. The compressed
>>> API supports this at the ALSA layer, and I really want to be able to
>>> expose that cleanly. I'm not in favour of adding codec-specific code
>>> in PulseAudio, but I think it should be possible to have something
>>> working without that.
>>
>>
>> Bluetooth adds format changes and RTP packetization that is not needed for
>> compressed data playback in a sound card. if you are thinking of having a
>> single layer to handle compressed playback, well, that is not going to work.
>> You will need extra code in Bluetooth sinks.
>>
>> Specifically for AAC over A2DP the data needs to be reshuffled to add the
>> LATM layer. The documentation for this is not quite self-explanatory.
>
> We could push the reshuffling into LATM to a higher layer, same as for
> the IEC61937 payloading, and we should be able to do the same for the
> RTP payloading as well.

Then this higher layer would need to have access to configuration 
parameters such as MTU, etc. Not sure how that information would be 
propagated.

Regardless, if anyone wants AAC support it'd be easier to prototype with 
gstreamer and push the data into BlueZ. the integration in pulseaudio 
can be done later.
If it helps here are some pointers

https://developer.apple.com/hardwaredriver/BluetoothDesignGuidelines.pdf
https://tools.ietf.org/html/rfc3016