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. > > As a start, I'd look at just passing through data as is, and ignoring > latencies from PulseAudio buffering altogether on such streams. > Eventually, we might be able to explore options such as passing > additional duration metadata on buffers to be able to do accurate > latency reporting. > > I think the LG folks had something along these lines, but I've not > heard from them about upstreaming their efforts in a while. > > Cheers, > Arun > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss >
