Hi-Fi playback on Android (developers/testers only) - General Topics

Each and every app on Google Play makes use of Android audio system to play music files (excluding my old andLess and the "USB Audio Recorder PRO" for external usb). The trouble with such playback is that you get a perfect 16/48000 or (44100) stream no matter the source file which is first downsampled then (digitally) clipped to the requested volume. Just try running this while playing _any_ file ("pcm15p" is for Qualcomm-based devices only, "15" needs be replaced with a different number for other ones):
Code:
adb shell cat /proc/asound/card0/pcm15p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 240
buffer_size: 480
As the time goes by and new devices receive better hardware, you'd expect this to change. No such luck with Android yet.
So I wrote a test app that plays lossless FLAC files directly through the ALSA driver.
The disgrace is:
1) It's targeted to recent msm8974 or apq8084 based devices and has no built-in support for other ones. If you've got an unsupported device, you have to modify the cards.xml file settings before anything, and this may be tricky (see below).
2) Root access is a must. A Permissive selinux setup may also be required (adb shell; setenforce Permissive).
3) No formats other than 16/24-bit FLAC or 16-bit APE are supported. There's a curious bug with 24-bit APE (won't be fixed);
-- All files not recognised for playback will be routed to Android;
-- If a particular sample rate (e.g., 176400) is not supported by hardware, it will be silently downsampled to its base rate (88200 or 44100 in this example);
-- If a particular format (i.e. a compressed stream, or 24-bit pcm or even 16-bit on some usb devices) is not supported, an error will be shown
4) In ALSA mode, volume controls work only when the app is in foreground (to be fixed);
5) Switching to/fro the Compr device may reboot your phone (kernel bug; workaround will be included later);
The settings file is called "/sdcard/.alsaplayer/cards.xml" and it's well commented. If you have a device missing there, all settings go in this file. A simple tip is checking the output of a mixer program like tinymixer and adding the diff when the device is playing and when it's not. These ALSA contrtols will be executed each time before the device is opened/closed/volume managed. The periods size/number to be added later.
This app also tries to play on "compressed" (a.k.a. "offload") Qualcomm devices, but you'll not be able to play FLAC files ulesss your kernel is patched; all newer msm8974/apq8084 devices support the hardware FLAC decoding, please ask your kernel developer to add the code like https://github.com/CyanogenMod/andr...mmit/f961d70994fe5f097b90e2cb5cfd87e90302c456 (I'm not providing a patch intentionally as (1) it's straightforward for an experienced developer (2) the codeaurora interface is really broken). For me, an offload FLAC playback sounds +worse+ than the direct pcm one (and I don't know the reasons why) -- I'm testing with the sennheiser IE-80 & audiotechnica ath 1000D headphones.
The program is opensource https://github.com/avs333/alsaplayer
The kudos go to skvalex who wrote almost all java part!

If change name flac to wav, it work.

Dear @avs333,
So.. this alsaplayer is great.
I can config cards.xml to make it work with my Lenovo Vibe X3(that havs built-in Sarbe DAC es9018c2m). So It can work with 24 bits FLAC file in direct PCM mode( that can not work with other, even with Poweramp alpha in HI-RES Mode).
I just need to ask you for support.
+ Can you add support for WAV file?( I mean in alsa PCM mode)
+In offload mode, I know in my device it will use PCM divices number 9, with Control - MultiMedia 4. But it's hidden, I can config it in cards.xml but it il not show in devices list. Of course the pcm device 9 does not show when I tried to list it "alsa_aplay -L".
Thank you

Hi @ctheanh!
Thank you for the comments!
Playing WAVs is currently supported in offload mode only, due to some obscure bug with Java I'm failing to find. A good news is that @skvalex (who is much more experienced in Java) has recently decided to join the project, so it'd be fixed soon I believe. He's planning to make a decent interface for this app, which is very rudimentary for the time being (and I'm really sorry for that!).
As to the offload playback, the devices have to be called "/dev/snd/comprCXDY" to be detectable (you need to make a link to such names if they're called otherwise by your specific driver). alsa_play won't show them as they're not pcms.

Hi @avs333
If you need tester, of course I am willing to join.
I am still optimize something with cards.xml to let it works smoothly. Still got some problem with volume( breaking my ear when changing from 24 bits to 16 bit). And the music will stop when receiving notification.
And, stupid question. How can I config to show offload device in device list?

ctheanh said:
Hi @avs333
If you need tester, of course I am willing to join.
I am still optimize something with cards.xml to let it works smoothly. Still got some problem with volume( breaking my ear when changing from 24 bits to 16 bit). And the music will stop when receiving notification.
And, stupid question. How can I config to show offload device in device list?
Click to expand...
Click to collapse
You have to specify different volume ranges for 24-bit and for 16-bit/offload playback in cards.xml as the standard QC controls are a bit strange, to say the least. For digital controls, I'm using 0-84 for 16-bit pcms (or *any* offloads) and 40-124 for 24-bit pcms with reasonable defaults (please see the original cards.xml), but using analog controls looks more promising.
To avoid the conflicts with notifications, select a device that is not used for them as they may stop the device even if they fail opening it.
The devices (including offload ones) shown in the "Settings->Device name" list are those specified in "cards.xml" if it is present (to filter out irrelevant playback ones) , or +all+ playback devices otherwise. You can "cat /proc/asound/pcm" to find their ids (and names). E.g., use <device id="17" offload="1"> if you see "00-17: (Compress2) : : playback 1". Please let me know if this doesn't work for some reason.

Is development dead? This is an awesome player! I'm asking my friends if they wanna contribute into this project, or we can team up, to push android audio further (you can see our team work with my sig picture link)

This seems very interesting.. I've been trying to get this working for AGES and have only successfully played 24 bit over Android O. ALSA is luckily very useful and I believe that card config can also be systemically implemented (as done in AINUR SAURON).
I'll happily join this project if you wish.

It seems to be a very good player
However I cannot play the file in external SD.

Hi everyone,
Looks like someone has forked this project on GitHub and made several commits to it:
https://github.com/cerg2010cerg2010/alsaplayer/graphs/commit-activity
Can anyone build the APK with the newest commits?

m00nlighter said:
Hi everyone,
Looks like someone has forked this project on GitHub and made several commits to it:
https://github.com/cerg2010cerg2010/alsaplayer/graphs/commit-activity
Can anyone build the APK with the newest commits?
Click to expand...
Click to collapse
Other methods exist for HiFi such as OpenSL ES HD and aaudio but this still send interesting so I'll take a look.

LazerL0rd said:
Other methods exist for HiFi such as OpenSL ES HD and aaudio but this still send interesting so I'll take a look.
Click to expand...
Click to collapse
Any news?

Lotoss said:
Any news?
Click to expand...
Click to collapse
On modern Android devices, I don't see why this is needed anymore. On older devices, if the kernel is set up correctly, this would work in theory as most devices allowed 24-bit PCM playback. Nowadays you got OpenSL ES HD, HiRes APIs from certain OEMs, HiRes paths for other OEMs, and probably stuff I missed out. In a post-Oreo world, I don't see why OEMs would have an excuse not to (or even custom ROM/kernel devs) unless the hardware has a limitation (unlikely).

LazerL0rd said:
On modern Android devices, I don't see why this is needed anymore. On older devices, if the kernel is set up correctly, this would work in theory as most devices allowed 24-bit PCM playback. Nowadays you got OpenSL ES HD, HiRes APIs from certain OEMs, HiRes paths for other OEMs, and probably stuff I missed out. In a post-Oreo world, I don't see why OEMs would have an excuse not to (or even custom ROM/kernel devs) unless the hardware has a limitation (unlikely).
Click to expand...
Click to collapse
I agreed that the OEMS should have no excuses to set up the path correctly nowadays. However the fact is that, they DO NOT
I have lost the OpenSL ES HD since I updated my Samsung Galaxy S7 Edge to Oreo:silly:

tidusdacapo said:
I agreed that the OEMS should have no excuses to set up the path correctly nowadays. However the fact is that, they DO NOT
I have lost the OpenSL ES HD since I updated my Samsung Galaxy S7 Edge to Oreo:silly:
Click to expand...
Click to collapse
Via modding mixers and audio routes you *may* be able to get it back.

LazerL0rd said:
Via modding mixers and audio routes you *may* be able to get it back.
Click to expand...
Click to collapse
Is there any clues for letting me to modify the audio path? Thx for the reply:good:

tidusdacapo said:
Is there any clues for letting me to modify the audio path? Thx for the reply:good:
Click to expand...
Click to collapse
Comparing is about it. There's no necessity for OEMs to implement a normal naming scheme there such as "hifi" but it's worth a shot to look for that.

AWESOME PLAYER!!!
Thank you very much!

Related

divx support ported from new samsung phone?

according to http://www.engadget.com/2009/11/15/samsung-unveils-android-equipped-galaxy-spica-i5700/
the new spica comes equipped with built in divx support. Is this a codec or is it an app that needs ported?
Anyone have any idea?
Nobody knows yet, as there hasn't been a dump from this device made available yet. Also, this should probably be moved to the Q&A area (or general) until there's something development wise that can happen.
Mi|enko said:
Nobody knows yet, as there hasn't been a dump from this device made available yet. Also, this should probably be moved to the Q&A area (or general) until there's something development wise that can happen.
Click to expand...
Click to collapse
What about the LG Eve dump that popped up a few days ago? Now I'm no dev, but I did a little bit of peeking around in it, and there is a bunch of stuff referencing DivX and mpeg4, h264, etc.
Am I wrong in assuming something can be done with those?
Moot
Whether it's a program to be ported or a codec to be included plays no real part in the answer to your question. The simple fact of the matter is that the G1 is too underpowered to do justice to DivX, h.264 or any other high capacity codec. The Spica is coming out with an 800 MHz processor, enabling it to jump through graphical hoops that we can't.
I agree that either way, just codecs or a (hopefully) simple port of a program, that we can at least try watching DivX, but I'm not getting my hopes up.
I bet it's got the decoder in hardware. That'd be a much easier, cheaper way to do it.
zapyourit said:
Whether it's a program to be ported or a codec to be included plays no real part in the answer to your question. The simple fact of the matter is that the G1 is too underpowered to do justice to DivX, h.264 or any other high capacity codec. The Spica is coming out with an 800 MHz processor, enabling it to jump through graphical hoops that we can't.
I agree that either way, just codecs or a (hopefully) simple port of a program, that we can at least try watching DivX, but I'm not getting my hopes up.
Click to expand...
Click to collapse
My 200mhz T-Mobile Wing with 64MB of ram did DivX just fine with TCPMP media player. The G1 can easily handle it if it can bypass the java interpreter.
Sumanitu said:
My 200mhz T-Mobile Wing with 64MB of ram did DivX just fine with TCPMP media player. The G1 can easily handle it if it can bypass the java interpreter.
Click to expand...
Click to collapse
Agreed, especialy if there swap running and other tweaks. Playback shouldn't be a problem but encoding and decoding would not be practical. But I guess we will see. But why not just encode to a format the g1 can handle that's what I do, so there is no need for other codec support.
marixsmith said:
according to http://www.engadget.com/2009/11/15/samsung-unveils-android-equipped-galaxy-spica-i5700/
the new spica comes equipped with built in divx support. Is this a codec or is it an app that needs ported?
Anyone have any idea?
Click to expand...
Click to collapse
The LG dump has divx support as well it looks like an entire media center, video editor and everything. From what i saw its hard coded libraries.
Libmmp_divxreg.so
zapyourit said:
Whether it's a program to be ported or a codec to be included plays no real part in the answer to your question. The simple fact of the matter is that the G1 is too underpowered to do justice to DivX, h.264 or any other high capacity codec. The Spica is coming out with an 800 MHz processor, enabling it to jump through graphical hoops that we can't.
I agree that either way, just codecs or a (hopefully) simple port of a program, that we can at least try watching DivX, but I'm not getting my hopes up.
Click to expand...
Click to collapse
My G1 plays back x.264 video just fine (all of my videos I encode for my phone are x.264 with AAC audio), and when I check on my PC (without hardware acceleration enabled) x.264 takes a little more juice than a similarly encoded MPEG4 ASP codec such as DivX or XviD would. Your argument is flawed.
jmotyka said:
Playback shouldn't be a problem but encoding and decoding would not be practical.
Click to expand...
Click to collapse
And how would playback without decoding the DivX video be carried out?
/Mats
Has anybody tried the yxflash app in the market? It does wmv pretty well and does do DivX video although not convinced how well. Sometimes it's kind of jerky but not sure if that's because it's the trial version. They want $20 on their web site for the full version and I'm not going to pay that without being sure it works all the time every time. But it still gives me hope that we will be able to play DivX on our G1s one day.
Charlie
Have the phone on hands but need help of some specialist to take out rom and player from there.
pls contact me ICQ 7120916
gtalk: [email protected]
Managed to install adb drivers, but because of idiotic rom could not install any apps on it...
Have tried to play divx file- http://www.hpc.ru/soft/software.phtml?id=20980 it did, my htc magic didn't
viewing a "divx" file is simple;
1) you need to switch out the fourcc tag to one that is reconized properly (and compatible -- mpeg4-asp i.e. H263) since nobody in the real world has heard of or cares about "divx",
2) use a recognized CONTAINER format (i.e. 3gp)
3) stick to resolutions and bitrates and other encoding parameters that make sense for the particular device.
Note: The device HAS an mpeg4 decoder chip capable of mpeg4-asp (h263/divx) and mpeg4-avc (h264). The CPU is IRRELEVANT since the decoding is all done in a dedicated video decoder chip.
lbcoder said:
viewing a "divx" file is simple;
1) you need to switch out the fourcc tag to one that is reconized properly (and compatible -- mpeg4-asp i.e. H263) since nobody in the real world has heard of or cares about "divx",
2) use a recognized CONTAINER format (i.e. 3gp)
3) stick to resolutions and bitrates and other encoding parameters that make sense for the particular device.
Note: The device HAS an mpeg4 decoder chip capable of mpeg4-asp (h263/divx) and mpeg4-avc (h264). The CPU is IRRELEVANT since the decoding is all done in a dedicated video decoder chip.
Click to expand...
Click to collapse
Apologies. I did not realize the G1 had a dedicated chip for such things.
zapyourit said:
Apologies. I did not realize the G1 had a dedicated chip for such things.
Click to expand...
Click to collapse
Even if it didnt have the mp4 decoder it still has enough power for divx, every windows phone I had has lower specs or the same processor and played them fine.
The G1 def has enough power I am not sure where you got the information, not being cocky but thats some bad information to spread around.
1Way
lbcoder said:
viewing a "divx" file is simple;
1) you need to switch out the fourcc tag to one that is reconized properly (and compatible -- mpeg4-asp i.e. H263) since nobody in the real world has heard of or cares about "divx",
2) use a recognized CONTAINER format (i.e. 3gp)
3) stick to resolutions and bitrates and other encoding parameters that make sense for the particular device.
Note: The device HAS an mpeg4 decoder chip capable of mpeg4-asp (h263/divx) and mpeg4-avc (h264). The CPU is IRRELEVANT since the decoding is all done in a dedicated video decoder chip.
Click to expand...
Click to collapse
So, having some kind of app decoding h263 when fourcc is divx or dx5 ecc instead, the main problem reduces to the support of common PC "containers" like avi, i'm right?
1wayjonny said:
Even if it didnt have the mp4 decoder it still has enough power for divx, every windows phone I had has lower specs or the same processor and played them fine.
The G1 def has enough power I am not sure where you got the information, not being cocky but thats some bad information to spread around.
Click to expand...
Click to collapse
Agreed.
My Windows Mobile 2003 Samsung SCH-i730 played any video file I threw at it flawlessly.
Flawlessly.
Saying that the G1 is too underpowered is just complete and utter misinformation.
1wayjonny said:
Even if it didnt have the mp4 decoder it still has enough power for divx, every windows phone I had has lower specs or the same processor and played them fine.
The G1 def has enough power I am not sure where you got the information, not being cocky but thats some bad information to spread around.
1Way
Click to expand...
Click to collapse
Every windoze phone you had also had a decoder chip. So what?
fl3xo said:
So, having some kind of app decoding h263 when fourcc is divx or dx5 ecc instead, the main problem reduces to the support of common PC "containers" like avi, i'm right?
Click to expand...
Click to collapse
No, the trick is to simply *change* the fourcc to h263 and/or be able to RECOGNIZE divx AS h263. Adding in more DEMUXERS (not decoders) would also help with dealing with additional containers, HOWEVER, there really isn't much point in supporting avi, since it is a terrible container that doesn't take A/V synchronization into account, AND it is typically used for video's that are over the resolution and bitrate limits.
Note: there may be licensing issues when dealing with certain container formats. I suggest staying as far as possible away from anything that carries a microshaft label on it (like avi, wmv, etc.).
lbcoder said:
Every windoze phone you had also had a decoder chip. So what?
Click to expand...
Click to collapse
What? Man you do not even make sense pfff
The point was a phone with less or equal to hardware specs could play the video fine.
Oh and BTW you should also know that the Windows Mobile Platform never optimized ANYTHING for the decoders built in the phones.
Most recent windows phone for the past a few years has a 3D accelerator that was NEVER used nor optimized expect by a Sony game released for the xperia. (which other phone could run with the correct DLL copied over as well, showing microsoft was lazy on 3D acceleration)
So much for not using the decoders eh?
The point in case you missed it is that WITH or WITHOUT the decoder the G1 has enough power to play the video.
Please use google if you need spoon fed information ...

[REQ] Trying to (at least) get AVI playing reinstated

In previous version of Android the media framework supported the AVI container (assuming your hardware also supported the codecs used in a specific file) This appears to have been removed (probably to save time) in Honeycomb. There doesn't seem to be a specific ticket open about this so I started one:
http://code.google.com/p/android/issues/detail?id=16634
Honeycomb is very much unfinished right now, so I'd imagine there is more leeway to get decisions changed by kicking up a stink sooner rather than later. If you feel the same way please feel free to star the bug report. With a following wind we might even be able to push through and get Matroska (MKV) container support as well, it's already been written by three different sources (The omapzoom project, Google for WebM and Samsung)

Support HDMI IN 1080p RECORD,4K&H265 android 4.4 tv box

ZIDOO X9 support hdmi in 1080p record(pvr),4k & H.265 hardware decoding,a great 3D UI,
CPU: MSTAR MSO9180D1R UP TO 1.5GHZ (Cortex-A9)
GPU: 8 cores Mali450
Android 4.4.2 Kitkat OS, Built in Google Play Store
2GB DDR3 RAM and 8GB emmc Storage
Great wifi signals;
Support Dual band wifi 2.4G & 5.8G (wifi module is MT7632)
Support HDMI IN
Support Bluetooth 4.0 version
Support 4K*2K and H265(HEVC) UHD video(4K and H265 hardware decodiing)
Support DTSHD MASTER,TRUEHD 7.1 passthrough
Build in XBMC ZIDOO version, support dolby dts hardware decodiing, also can play 4K, RMVB, Blueray ISO, BDMV,MKV file without any problem;
Support HDMI IN DVR(PVR)
A great launcher, file manager,music player,videoplayer, Album,based on OPENGL 2.0
The following is from KODI forum:
So I received my X9 today and these are my first initial impressions:
The box:
The build quality is very good. No flimsy plastic, but a well build aluminum uni-body. It breaths quality
Good reception for 2.4 and 5ghz Wifi
A nice little VFD, but way too bright. It needs a software option to be dimmed (VFDservice)
The software (X9 UI):
Finally a good attempt to integrate various Android-apps into a user friendly launcher. Definitely aimed for the western user. No frills, but nice and minimalistic. I've used many android boxes and sticks, but they almost all lack a good launcher (just stock android) or are very Asian orientated (no disrespect intended). The Zidoo X9 really distinguishes itself from the competition with this UI!
It has a few (cosmetic) translation errors
For those who are new at media-boxes, it is easy to work with (a very good WAF). No need to use the underlying Android-OS (4.4.2)
For those that are more experienced, it needs to be more configurable (see suggestions)
The software (others):
It comes Pre-Rooted! Very nice! User can access the whole file system with SSH or ADB. All settings needed to install third party apps are set (use unknown sources, usb debugging, etc)
Could not use Google Play initially (with Google account enabled). It says "Check your connection and try again". Installed Aptoide and updated Google Play
The built-in explorer is divided in sections (music, video, image) which scans local memory, attached usb devices or SDcards. The file chooser that follows could be less colorful in my opinion and could make better use of screen availability. Its color settings, font-size and column-width should be adjusted by the user. The fourth File option can make use of all local media or network shares. The context menu, however is still in Chinese
The mediaplayer does a good job. Tested only mkv's though. Fast skipping forward and backwards. Reads external .str files by default, but I learned if a fiddle with the subtitle settlings, I sometimes can't display them anymore. Also the fontsize could be thicker and use a shadow backdrop instead of a red frame.
It has some translation errors (cancle instead of cancel)
The Music Player initially looks nice but has no filter whatsoever in the playlist. It flattens all music files found and shows no filtering in artists, albums etc..............A non-usable app
The Image viewer has some nice transitions, but its media-scanner scans hidden files and folders and the shows numerous thumbnails created by third party apps like XBMC. Also the app crashes a lot
The Game player opens with featured Air Mouse Games. That's a little strange because the remote only has 4 directional mouse steering and no gyroscope (at least I could not get it to use as an air mouse). Did not test games but I presume they run well given the hardware
Finally XBMC. After all, it's the de facto multimedia player. Being a looooong time XBMC user, this HAD to run smooth. And it does. The remote runs swiftly through the menus with no delay whatsoever, but is can use a better button remapping. Multimedia content is added swiftly with the use of content scrapers en consequently played very smooth. (using on a LAN). I’ve only tested HD .mkv content. I’m no video purist and don’t watch 3D content, which in my opinion is a hype soon to be forgotten……….at least with glasses.
I’ve also installed the latest Kodi RC3 and initially noticed no differences in playback or CPU use. I did notice it was not possible to use Audio Passtrough
Suggestions:
System
Standby/Sleep support. The system cannot go to sleep. The android system setting does have a sleep mode but it only dims the screen. The X9 UI only has a screensaver. It must be physically made possible on a device like this. Your average android tablet/phone also can.
Dim the VFD
Add "cifs.ko" (+ support libs) to the kernel for mounting Samba shares at boot. With these present all Android apps can use network shares, not just the ones that support it
Interface
The X9 UI should be more configurable (for the advanced user)
- Theme the main tiles. The UI has theme possibilities but only changes the background. A dark background should also incorporate darkened tiles (grey scales, for instance). A brighter background could have more colorful tiles (like they are now)
- Disable the edit (+) button. Show only when needed
- Sort apps in the submenus
- The possibility to start an app immediately from the main tile (like the Google play tile) instead of showing a sub menu
Better/thicker/more colorful highlight frame in webbrowser. It's sometimes really difficult to find the cursor position
Change the mousepointer into a "normal" one. Get rid of the ugly little hand
Click to expand...
Click to collapse
Is there some discount for xda members?
Zidoo x9 (as a media extender) with Ceton Infinitv 6
I'm trying to find out if it's possible to use the Ceton Infintv 6 on a Windows 7 Professional PC and then use Zidoo x9 (Android Box) or Pipo x7 (Windows 8.1) to access the live channels as well as stream recorded content.
Anyone with any info would be greatly appreciated.
enahsak said:
I'm trying to find out if it's possible to use the Ceton Infintv 6 on a Windows 7 Professional PC and then use Zidoo x9 (Android Box) or Pipo x7 (Windows 8.1) to access the live channels as well as stream recorded content.
Anyone with any info would be greatly appreciated.
Click to expand...
Click to collapse
Sounds crazy. InfiniTV 6 ETH supports CableCARD and connects to any U.S. cable system to receive all SD and HD digital cable channels without needing a set-top box.
Hi there. me too heve this fast and great box.
I just wonder if there is a way to build a loop recorder on the HDMI port. A Timeshift.
Exist yet the recorder and the Zidoo developers release the recorder app code.
Do you think someone could create a timeshift app for this machine?

[Q] [DEV] Use AOSP AAC Encoder for Bluetooth Audio (A2DP) Instead of SBC?

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.
Seriously, is really nobody interested in that? Or am I completely wrong with my assumptions?
Please, if someone knows anything about the inner workings of audio via bluetooth in AOSP, share your knowledge. Maybe there exists documentation that I haven't found yet, even just a link would be very appreciated.
This is the only bump of the thread, promised.
It's not that nobody is interested, it's that it's much more complicated than that. Bluedroid does support aac sure, but for an app to support sink for aac then it has to include hardware-specific headers. In an open platform like Android, this is difficult for developers to do.
From what I understand, there is no setting/code in kernels or bluedroid to make any app automagically support aac over a2dp - the apps themselves need to have HCI natives/interfaces. And these may very well be patented by the Oem e.g
Broadcomm.
Sent via Tapatalk on my Xperia Z
This is very insightful, thanks.
I wasn't aware that the apps themselves needed specific support. I thought this was one system-wide thing: Once paired with the bluetooth receiver, the same codec will be used for all A2DP audio. If that's not the case, I see that this makes it even more complicated.
If there are even patents and complicated hardware-specific code required, I understand it's more difficult than I thought.
But impossible? Aren't at least the Nexus devices open enough to try something?
I could be mistaken, this is how I understand it though. I actually investigated this myself a couple years ago and never got anywhere, I needed source code for the *receiver* too. Apparently it's not quite standard or something.
Things may have changed since, at least I bumped the thread maybe someone else knows more
Edit: I wouldn't get your hopes up though. It might be possible, but not legal. Aac is not "free", having the codec doesn't mean they're legally allowed to implement it in every level (I.e. A2dp is different to local file encoding in camera recording) and as the Nexus devices are developer devices not designed for general consumer use I don't see it having support for it. An Xperia device is another story though for example, we even have ATRAC support (obviously requires a Sony headset/device to pair with though).
Sent via Tapatalk on my Xperia Z
CosmicDan said:
I bumped the thread maybe someone else knows more
Click to expand...
Click to collapse
Nah, you've definitely provided some thoughts that I didn't have before. Thanks for that.
CosmicDan said:
Aac is not "free", having the codec doesn't mean they're legally allowed to implement it in every level (I.e. A2dp is different to local file encoding in camera recording)
Click to expand...
Click to collapse
If this is true, how are the FDK AAC and opencore-amr guys doing it? As far as I know, they extracted the AAC code from AOSP and are using it at their leisure without legal consequences. It would be really weird (but possible, I guess), if the AAC code in AOSP may only be used for certain functionality, e.g. camera videos, but not A2DP.
CosmicDan said:
and as the Nexus devices are developer devices not designed for general consumer use I don't see it having support for it.
Click to expand...
Click to collapse
I understand that, but since you said there was some low level access required for some parts of the hardware or firmware, isn't it the developer devices that have the best chance for some solution?
CosmicDan said:
An Xperia device is another story though for example, we even have ATRAC support (obviously requires a Sony headset/device to pair with though).
Sent via Tapatalk on my Xperia Z
Click to expand...
Click to collapse
Sure, there may be manufacturers that are using their own proprietary codecs like ATRAC, but I'm not really interested in that. It's an even worse situation than with apt-X, because the latter is already supported by a variety of devices, while ATRAC will be mostly Sony-only. That's just my assumption, of course.
AAC is supported by a lot more devices, probably due to licensing stuff.
In any case, I'm thankful for your replies.
I'm not sure about those guys, but Ffmpeg for example doesn't include/support aac for patent reasons. The codec is not free, use of an existing codec is free though. http://www.vialicensing.com/licensing/aac-faq.aspx
Edit: Fdk is Fraunhofer, they're actually a shared holder of the patent. So yeah they have the rights to do it. Ffmpeg supports aac, but it's a violation to distribute aac encoding binaries without license so it's DIY in that case.
I did some more research, seems Lg did indeed pay for Aac encoder in Nexus 4. Most recent android devices do.... So I guess there is no legal barrier at all, I'm just talking nonsense
My guess is that there is missing hardware to support viable aac over a2dp, seems strange that it hasn't been done already. Or the aac encoder is separate to bluedroid; and requires a *second* license (along with reimplementation) for it to work with aac. Both seem just as possible to me.
Sent via Tapatalk on my Xperia Z
Yeah, this licensing stuff is very confusing. There's different information on the web, Wikipedia'd description is quite telling... "License: Liberal,[3] but not a license of patented technologies".
They're referencing the official AOSP license file that's included in the source: https://android.googlesource.com/platform/external/aac/+/master/NOTICE
And this document is really confusing to me. An important sentence is;
AOSP NOTICE said:
You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized
by appropriate patent licenses.
Click to expand...
Click to collapse
But it's defined nowhere what these authorized purposes are.
So you could be right about them needing a second license for a different "authorized purpose". And additionally there could be hardware restrictions, that's true. I'm not familiar enough about how this works on a device. Like, is there hardware acceleration for AAC encoding/decoding, or is it done entirely in software. Must the bluetooth chipset specifically support certain codecs, or can it be used as "generic" device and the audio codec is all software stuff? Or is there something specific in the firmware for that chipset/radio etc. I really have no idea.
I'd still like a developer, who knows BlueDroid and maybe the Nexus devices, to explain this. ELI5. And we'll probably need a lawyer to explain the patent/licensing stuff. :laugh:
I *think* the Neon extension in ARM supports aac hardware encoding, or at the very least something in modern soc's would use hardware based encoding. Maybe only decoding, and that's the issue? Software based encoding could be a factor. I don't think it's done entirely in software, not decoding anyway - no idea about encoding to be honest. Probably varies per device. Apparently Samsung's support aptx so that could be an exynos thing for example.
Afaik the a2dp protocol can passthrough already-encoded aac streams regardless as it's part of the specification but I was thinking more of a highspeed (or additional) bus to allow the higher bitrates to work. But I'm just speculating here.
Maybe you'll have better luck asking on the Cyanogenmod forums? Xda is pretty crowded these days. This section is loaded with Chinese related firmware hacking and super-duper script "tweaks".
Sent via Tapatalk on my Xperia Z
Well seems like Google solved it now

Dev for Hire?

Hi, I hope I am not violating forum rules by posting this.
I am interested in hiring a developer to create a rom for a project related to a specific series of digital audio players that are all based on relatively the same hardware and software platform. The model numbers are Pioneer XDP-100R, XDP-300R, Onkyo DP-X1 and DP-X1a. These are all running an AOSP 5.1.1 and carry very similar hardware. They are made in the same plant, by the same parent company.
The main use case for a new ROM is that these devices all include specialty audio hardware that is currently only utilized when using the bundled music player. 3rd party music players, and streaming services like Spotify and Tidal, route audio through the integrated DAC on the Snapdragon chip. It would be preferable to use the higher quality ESS Sabre DAC(s) that is utilized by the onboard music player. I have no clue at how involved this would be, but LG has done it with the V10/V20.
Would also be interested in possibly incorporating other features, most likely based on disabling services that are not required for playing music. The idea is lean and light.
If you have any insight on what would be involved in a system level change to route audio through the Sabre chip please feel free to post here. If you are interested in working on the project, please PM me.
Thanks
YES!!!!
YES!!!!
I am absolutly interested in this !!!
Im willing to contribute $ as well
A Full featured audio oriented custom rom for my xdp-300r b personally that sounds like a dream come true
Currently i use (Athame) to download Tidal songs/playlists/Albums from my personal account
theres options in settings for MASTER quality audio files,,
Simply copy paste web address of the page you want to rip music from (sharebutton:url)
into athame and it will compile and click download
easy and simple and fast....
I just hosted it incase you or anyone wants access let me know ill send a download link
PCLOUD LINK BY REQUEST ONLY
MAKE SURE TO CONFIGURE SETTING FOR USER ACCOUNT
its simple just cut paste audio tracks onto SD card
use the integrated music player and enjoy your hifi dac in all its glory
I NEVER USE XDAP THE TRANSFER WILL FAIL!!!
also heres a different idea i recently had------->
although just to let you know, porting music apps through kodi is a much more user friendly approach......
on kodi just do some research and find the audio plugins you need and install them through repo's
HERES MY FAV BUILD REPO
http:angel:://kbully.:angel:esy.:angel:es
im thinking that its possible to design an APK for android that can monitor apps and create a profile for how they decode and encode data for audio and video data,,,,
a simple plugin and widget for android that intercepts and reroutes all app audio transmission through the integrated audio hardware thus your apps like Tidal,, even netflix and youtube would not have to be modified, the audio transmission paths would simply be rerouted as if it were playing through the integrated plugin's
so instead of modifying hardware plugins and to avoid modifications to copyrighted app's
simply create a middle man diskjocky to intercept and redistribute data transmissions by lane switching and protocol interception redirection
this idea is forked from an idea i had for a bluetooth app for transmitting audio to many different speakers at once sort of like (Airfoil) either by modulating transmission across many transmission lanes at once by splitting them into thousands of bits and cloning data transmission like dealing identical cards to all players very fast like refresh rates faster than the ear can distinguish so that every speaker system gets the same audio transmission at the same time and in sync,,,,
possibly helper plugins that you install on all your devices with bluetooth hardware,,, so that when not in use they could maintain a shared connection to the host player for sharing the BT hardware so that audio could be synced and distributed to different recievers locally at a decent sync level offloading cpu needs to devices that are not being used by owners,,,,
that is also forked from an idea i had about an open source application that people would use for extreme data crunching needs by utilizing unused hardware from other users globally, like a Social Global Cloud Computing Project the data is so small individually that it is secure in the nature of data size alone thus never needing additional security updates all data would flow through micro VPN's
there are times processing power is needed and others simply have a computer or mobile device running and not in use, or not completing processing tasks of significant hardware needs,,,, imagine if anyone on any device could instantly process complex operations by sharing unused power????
at the rate network speeds are increasing cloud computing is inevitable and that will be the end to custom roms and os development,,, how do you flash a mobile device that is only a peripheral device with streaming capabilities,,, the OS firmware would be operated virtually on servers and physical user hardware would become the past............
anyways i totally had szhit to do and got stuck on here for over 2 hours typing this up loll lmao
to infinity and beyond fellow human
~Killacam~
"don't wash their mouths with soap assuming it will clean their mistakes,
expose their mouths to Dirt so that they may taste and experience their faults"
I've rooted XDP-300R and just ported TWRP over to it tonight. Seems to be working! I've already had a working build.prop mod to skip android encoding and push directly to DAC. But this hopefully allows more work without fear of bricks
https://cdn.head-fi.org/a/10245543_thumb.jpg

Categories

Resources