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
