Good morning to you all!
I've posted this in the thread about the apt-x petition, but didn't get any replies so far. And since it's also partially off topic there, I thought I'd open a new thread.
Beloved mods, if this is the wrong section, then please move it into a more fitting area. I also wasn't sure about the correct thread title prefix, so if this one is inappropriate, please change it to a better one. Thanks!
I'll basically repeat what I said in the thread over there. The thread title actually is a good tl;dr, so here's the longer version:
Apt-x is not a viable alternative as bluetooth codec in Android devices, due to various reasons explained in the thread above. But AAC could be a nice alternative. It's a much more complex and powerful codec than SBC, theoretically resulting in much higher audio quality, if the playback device/bluetooth receiver supports AAC decoding. Maybe AAC isn't as efficient as apt-x, but it's definitely a great format - in low bitrate ranges with HE-AAC and in high bitrate ranges with low complexity AAC (the latter is what's being sold by Apple in the iTunes store at high bitrates).
AOSP does contain a high quality AAC encoder since Jelly Bean (nothing like the FAAC or ffmpeg encoders for AAC, they're not providing good quality), the code has even been extracted for use in other applications that need a high quality AAC encoder, for example the popular video transcoding tool Handbrake. It's available under the name FDK-AAC (also see http://sourceforge.net/projects/opencore-amr/).
My main concern is: I don't see why it shouldn't be possible that AOSP ROMs could use this encoder for encoding audio for A2DP. There can't be any licensing issues, because the codec already is in AOSP, right?. I know that if it were that easy, someone probably would have already implemented that in some custom ROM (or even Google would have enabled AAC over A2DP per default), but I don't understand what the technical problems here are. The only thing I can think of is processing power. Encoding AAC needs moch more power than SBC, but I'd assume that modern smartphones shouldn't have a problem with that. We're talking about playback-speed encoding, it's not like you want to use the encoder on your phone to transcode you music library that should work as quickly as possible. I don't have any numbers, but my common sense tells me that power shouldn't be the issue. Isn't AAC encoding maybe even hardware accelerated on some SoCs, considering that AAC is also being used as audio codec in most video recording formats?
Maybe someone could clear that up for me.
To clarify: I'm not looking for an immediate practical solution, this question is more of theoretical nature. I'd really appreciate it, if someone, who understands this whole bluetooth audio situation in Android, could explain it in words that I (no developer, semi-advanced user with experience in audio formats) can understand. I'd also be thankful for any links to documentation or specifications, which might help to explain things.
I hope you understand what my question is. If not, please ask me, and I'll try to explain it in other words.
I've posted this in the thread about the apt-x petition, but didn't get any replies so far. And since it's also partially off topic there, I thought I'd open a new thread.
Beloved mods, if this is the wrong section, then please move it into a more fitting area. I also wasn't sure about the correct thread title prefix, so if this one is inappropriate, please change it to a better one. Thanks!
I'll basically repeat what I said in the thread over there. The thread title actually is a good tl;dr, so here's the longer version:
Apt-x is not a viable alternative as bluetooth codec in Android devices, due to various reasons explained in the thread above. But AAC could be a nice alternative. It's a much more complex and powerful codec than SBC, theoretically resulting in much higher audio quality, if the playback device/bluetooth receiver supports AAC decoding. Maybe AAC isn't as efficient as apt-x, but it's definitely a great format - in low bitrate ranges with HE-AAC and in high bitrate ranges with low complexity AAC (the latter is what's being sold by Apple in the iTunes store at high bitrates).
AOSP does contain a high quality AAC encoder since Jelly Bean (nothing like the FAAC or ffmpeg encoders for AAC, they're not providing good quality), the code has even been extracted for use in other applications that need a high quality AAC encoder, for example the popular video transcoding tool Handbrake. It's available under the name FDK-AAC (also see http://sourceforge.net/projects/opencore-amr/).
My main concern is: I don't see why it shouldn't be possible that AOSP ROMs could use this encoder for encoding audio for A2DP. There can't be any licensing issues, because the codec already is in AOSP, right?. I know that if it were that easy, someone probably would have already implemented that in some custom ROM (or even Google would have enabled AAC over A2DP per default), but I don't understand what the technical problems here are. The only thing I can think of is processing power. Encoding AAC needs moch more power than SBC, but I'd assume that modern smartphones shouldn't have a problem with that. We're talking about playback-speed encoding, it's not like you want to use the encoder on your phone to transcode you music library that should work as quickly as possible. I don't have any numbers, but my common sense tells me that power shouldn't be the issue. Isn't AAC encoding maybe even hardware accelerated on some SoCs, considering that AAC is also being used as audio codec in most video recording formats?
Maybe someone could clear that up for me.
To clarify: I'm not looking for an immediate practical solution, this question is more of theoretical nature. I'd really appreciate it, if someone, who understands this whole bluetooth audio situation in Android, could explain it in words that I (no developer, semi-advanced user with experience in audio formats) can understand. I'd also be thankful for any links to documentation or specifications, which might help to explain things.
I hope you understand what my question is. If not, please ask me, and I'll try to explain it in other words.