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
