Related
Hi Guys,
I have been on the search to find a bluetooth headphone that will allow you to listen to music through bluetooth on your I-mate/XDA 2 etc.
I came accross the Sonorix OBH-0100.
Site:http://www.sonorix.com/eng/sono_product_obh0100.html
Review:http://www.worldofppc.com/HWTests/openbt2.htm
I sent an e-mail to the company asking whether this set would work with Pocket PC (XDA 2). They replied back saying that current pocket pc's would need a A2DP (advanced audio distribution profile) to be able to use your bluetooth headphones to listen to music from your device.
Does anyone know how we could go about adding this extra bluetooth feature.
Im sure that alot of you would like this option / accessory. So if anyone could help that would be appreciated.
Thanks
Hi, well done on finding the BT headphones, I've been trying to find something like this for a while...
first, on other parts of this site there are links to the following place:
http://bluetooth.i-networx.de/index_e.html
This guy is busy writing BT software for the XDA to fill in the shortfalls, and slowly including more profiles into his BT tools, He may be able to help with the profile problem for the XDA...
Also, are they actually selling these units yet? The URL you supplied only seems to supply 'sample' sets for traders, I would like to know where it is being sold, and if not when it is being released if the info is available..
http://forum.xda-developers.com/viewtopic.php?t=6816&highlight=bluetooth+stereo
people say that the quality is horrible if it worked
Hmm I dunno, maybe it is possible to send the audio across the BT link compressed (maybe MP3 like) and do the decompression back into audio locally, this would possibly make it possible to send resonable quality over the BT link bitrate (I think it's about 700k).
Their website claims to have reached CD quality audio.
yeah suppose you could do that but it would require
a uncompression in the head set
it would be possible of cause but from that guy who tried it
it may require more then just a std profile
Yes, a special profile is required as mentioned in the first post, apparently it is an advanced audio digital profile (a2dp), but no hand held units have it yet, we were hoping someone may be able to write profile support for the XDA...
I sent an e-mail to Tobias at Pocket Bluetooth tools about these particular headphones and he replied that he has no ordered the headphones and will work on the A2DP profile as soon as he recieves the headphones.
Hope something good comes out of this.
Will keep you updated 8)
Great news, now we only need to sit back and wait.
I had a look at the site but they only seem to be selling trader samples? Do we know where these items can be bought yet and how much? if not do we know a release date?
No, they havent mentioned anything about a release date but I have heard that many people have ordered the trade samples to test them out.
I think trade samples is the ony way you can buy for the time being ...$220 is the price as I remember and this excludes delivery and tax that you might have to pay.
But I have to admit they look very cool and if Tobias can solve this problem soon, I would certainly order one for myself.
BT audio transport
Hi folks,
I'm on the search for BT headset that also plays back the audio output of my MDA II (e.g. direction info of tomtom nav 3 ...)ยด. When I found this thread I thought that's it, but there is now follow up after Apr. 24th.
Any news yet?
Still no news!?!?!?!
:x
what you need is a bluetooth profile which have support for
Advanced Audio Distribution Profile
ms really dont like bluetooth all that much and their stack lack most bluetooth profiles
maybe the latest vidcomm stack support it
more about bluetooth profiles
http://www.palowireless.com/infotooth/tutorial/profiles.asp
maybe you should look into this product
http://www.bluetake.com/products/BT420EX.htm
but some guy in the forum had one for test and said the phone quality was pretty poor
RE
OK guys!
A short review has been posted here:-
http://www.ppcsg.com/forums/viewtop...t=iphono&sid=6d3d546329a09353b6817f1c28cdca86
From another thread Pocket Bluetooth Tools doesn't work very well with iPHONO bluetooth headphone and the digital Bluespoon bluetooth headset. However, it creates a non-dynamic serial port and enables printing from the O2 XDA II to HP 450CBi bluetooth portable printer.
http://www.ppcsg.com/forums/viewtopic.php?t=38299&sid=6d3d546329a09353b6817f1c28cdca86
:roll:
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!
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
Has anyone connected bluetooth to the PS3 playstation with whyred was not. Am I just connected via OTG? Are there any higher teachers who help me?
I think kernel needs to support it.
NEWBIE
deathbearer said:
I think kernel needs to support it.
Click to expand...
Click to collapse
i think. kernek support OTG. No support bluetooth
Kernel does not matter
only need for bluetooth driver to support it
try sixaxis controller
you first need to change the host of the ps3 via sixaxis pair tool
and use the sixaxis android app
needs root to use the app
http://dancingpixelstudios.com/sixaxis-controller/
im pretty sure that this will work
Never worked for me on whyred. Doesn't work with otg or bluetooth. Although it worked kenzo 8.1 roms.
I got it working once while using AOSP Extended ROM with a magisk module called Sony Framework, never got it working in ANY ROMs whatsoever except that one, if you have some ways to make it work, I'm extremely interested by it ^^
Hi anyone please help to increase the earpiece volume. It is too low
Tell me which line i have to edit in mixer paths for earpiece only...
ps4 controller run...there is no null to map it
Anyone manage to get Dex to work with Sony bravia Android TV from 2017. It supports miracast but some how the phone cant find it.
angka8 said:
Anyone manage to get Dex to work with Sony bravia Android TV from 2017. It supports miracast but some how the phone cant find it.
Click to expand...
Click to collapse
I managed to get it working with our Phillips, but the phone reports the TV isn't optimized for the best performance.
It took several tries getting it to connect.
Try smartview and see if it'll mirror that way.
hello, thanks for information. no problem with smartview. but the tv was not found when using Dex.
angka8 said:
Anyone manage to get Dex to work with Sony bravia Android TV from 2017. It supports miracast but some how the phone cant find it.
Click to expand...
Click to collapse
Sony 900e here, miracast was software removed from my model, if i had to wager a guess, sony did it to yours as well.
shabbypenguin said:
Sony 900e here, miracast was software removed from my model, if i had to wager a guess, sony did it to yours as well.
Click to expand...
Click to collapse
think i may be having the same model but one generation later. i do a search, Sony is saying the screen mirroring feature from the input source menu was using miracast.
oh manage to get it to work. need to go to the screen mirroring source input (stay on the page) on the Sony TV before turning on Dex. it will then find the connection and then you choose to connect.