[pulseaudio-discuss] Bluetooth A2DP AAC passthrough?

[Arun Raghavan]

On 2 May 2016 at 21:56, Pierre-Louis Bossart
<pierre-louis.bossart at linux.intel.com> wrote:
> 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.

Hmm, good point. We could have that on the format info of the sink.

> 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

You should be able to get an RTP/LATM stream with aacparse and
rtpmp4apay already.

Regards,
Arun