[pulseaudio-discuss] Bluetooth A2DP AAC passthrough?

[Arun Raghavan]

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.

-- Arun