Hi All,
Hopefully in the right section as I didn't want to add more threads to the dev section but feel free to tell me to move to there is this is the wrong place....
I have an in car dock for my phone and for some time now it hasn't worked with the CM builds. SGSIII users were also facing the same problem up until November last year when they got the relevant patches merged into the CM nightlies to re-enable it for their phones.
I was hoping that the CM team for the N7000 would be kind enough to add it into their to-do list? It's the only thing that is missing from CM10.1 for me and I am sure there must be others out there that would love to have this back in the rom.
thanks!
From the discussion thread....
http://forum.xda-developers.com/showthread.php?p=38900841
Entropy512's statement:
"Needs audio HAL work. I provided the instructions for getting the path data in a few places, don't remember exactly where. I haven't had much time lately, even less motivation to mess with Haxxinos4 devices.
Apply http://review.cyanogenmod.org/#/c/19294/ to a kernel running with the old blob HAL, connect to dock audio, grab the path data from dmesg.
Then add it to our audio HAL. I MIGHT be able to do it with just a dmesg from above - that's the time consuming part I haven't had any chance to mess with."
Quite an impressive coincidence isn't it?! I have nothing to do with this, I promise!
AA1973 said:
From the discussion thread....
http://forum.xda-developers.com/showthread.php?p=38900841
Entropy512's statement:
"Needs audio HAL work. I provided the instructions for getting the path data in a few places, don't remember exactly where. I haven't had much time lately, even less motivation to mess with Haxxinos4 devices.
Apply http://review.cyanogenmod.org/#/c/19294/ to a kernel running with the old blob HAL, connect to dock audio, grab the path data from dmesg.
Then add it to our audio HAL. I MIGHT be able to do it with just a dmesg from above - that's the time consuming part I haven't had any chance to mess with."
Click to expand...
Click to collapse
I'm interested in digging this out. Anyone know what Entropy512 means by blob HAL?
apparently, he's talking about some binary module for audio HAL (wikipedia: binary blob)
i was hoping it had to do with some aosp module (libstagefright or so)
nonetheless, would be great if someone with experience could provide pointers.
apparently, this has already been implemented for the nexus 7 through CM10.1
http://forum.xda-developers.com/showthread.php?p=40079493&highlight=audio#post40079493
need to look in to effort to move this over to the Note
Hi...
Not having USB audio implemented in the latest CM versions is really my only problem with stepping up from 4.0.4 (CM 9.1).
So please, if anyone can spare the time to take a look at this, i'd be eternally thankful...!
...ongoing
FYI...:
There is an Cyanogen issue for this. Unfortunately i'm not yet allowed to post links...
But check out jira on the cyanogenmod site and look for dock audio...status is unresolved.
Dmesg/logcat from CM9 patched dock insertion
AA1973 said:
From the discussion thread....
http://forum.xda-developers.com/showthread.php?p=38900841
Entropy512's statement:
"Needs audio HAL work. I provided the instructions for getting the path data in a few places, don't remember exactly where. I haven't had much time lately, even less motivation to mess with Haxxinos4 devices.
Apply http://review.cyanogenmod.org/#/c/19294/ to a kernel running with the old blob HAL, connect to dock audio, grab the path data from dmesg.
Then add it to our audio HAL. I MIGHT be able to do it with just a dmesg from above - that's the time consuming part I haven't had any chance to mess with."
Click to expand...
Click to collapse
I followed your instructions and have attached a dmesg/logcat from the time related to the insertion/removal of the dock. I attempted to use apollo to output some music but it repeatedly crashed, I changed the volume level several times instead as the volume change tone outputs via the dock audio. Hopefully you will have time to have a look and see whether it would be possible to apply the necessary changes to CM10.1
Thanks
Links onTopic
Here are two interesting links for the whole usb audio topic for android. I thought this may save some people looking for it..:
Cyanogen Mod issue
Google Issue
The Google issue has lately been closed for commenting, but as several issues have been mergred into it, my hopes are high that implementation is at least being looked into right now.
I've finally given up on the in-car USB-dock solution. So i've switched to bluetooth audio. This step made very clear to me, that the audio quality from USB was even more horrible than i thought (compared to BT). Can anyone comprehensively explain to me what kind of signal "comes out" of the USB?
Related
[Reward] $125 Challenge to the community: Fix the infamous "audio lag" problem
Several HTC devices have a very annoying problem. When you playback audio, periodically (usually once every 5 minutes) you will hear a short "skip" in the audio. The sound has been described as a lag/skip/hiccup/tick/blip. It's all the same problem, though.
http://forum.xda-developers.com/showthread.php?t=412065
Whatever standard solution you can think of, it has been tried and failed (post to the above thread if you have a new novel suggestion). The problem appears to be deep in the wave device driver or possibly the hardware wave device itself. The problem does not seem to be present in A2DP. If you have skipping with bluetooth headphones, it's probably not related.
It seems to affect (at least), the Diamond, Touch Pro, HD, and XPeria. Possibly more.
There is a work-around (sort of), however. Some (newest?) versions of HTC's Audio Manager application (the TouchFlo player) ON SOME ROMS (not all) uses a non-standard method for playing back audio via DirectShow. These new versions do not skip, or at least do not skip on the regular five minute interval (it has been reported that some files don't play well through the Audio Manager for other unrelated reasons). However, this does not help the dozens of third party audio players.
I have asked HTC to provide documentation on how they did it. They refuse to respond, sending me a form email saying "we cannot support third party applications."
Conduits (makers of PocketPlayer) have told me they will implement the work around if somebody can figure out how to make it work. Their attempts to reverse engineer Audio Manager discovered this non-standard way, but when they wrote a test application, the skip problem was still present. So there is definitely more to the skip than simply sending audio via DirectShow. However, I think they are on the right track. It's just a matter of further reverse engineering Audio Manager until we get it right!
The Challenge!
The first community member to successfully create a very simple program to demonstrate lag-free audio playback (with full source code open sourced so that anybody else can use the method) will receive a pool of money from donators following this thread. I will personally chip in $15 US. I hope others will make commitments too (post below if you will)! When the solution is confirmed to work and can be replicated by third parties, I will send my donation via paypal and will post in this thread where everybody else should send their donation. If you make a commitment, you better donate!! lol. It likely won't be a whole lot of money, but I figure we have to reward the hard work at least a little!
To help you get started, here is the relevant information from the email conversation I had with Conduits where they explained to me what they found while reverse engineering Audio Manager.
We have done extensive tests regarding the HTC audio skipping issue, and have come to the conclusion that it is not something that Conduits can address. After analyzing the HTC Audio Manager program, and several other files (such as HTC’s DirectShow Audio Renderer HTCRenderFlt2.dll and HTCADXRenderer4.dll), we found that both are making some very special system calls into the WaveOut driver.
Here are some technical details for what we have found. First, we don’t think that thread or process priority have anything to do with the problem. Normal audio application use a cycle of ‘waveOut buffers’ that keep the audio output ‘full’ with audio data for the system to pull from and play. Applications use standard waveOutWrite functions to fill these buffers. From Pocket Player’s standpoint, these buffers are always full, and adjusting the priorities won’t affect this. One way to improve audio skips (that has affected the HTC TyTN) was to boost the thread priority of the WaveOut driver by editing a registry value under HKLM\Drivers\Builtin\WaveOut. This approach did not work here. Interestingly enough, these skipping problems occur on desktop PC’s. There, the problem is related to realtime drivers that take “too long” in their processing, which prevents the audio driver from processing the next batch of sound. This happens in Vista with some MacBook drivers.
The Audio Manager uses a different output mechanism from the standard waveOut calls – it uses the DirectShow audio renderer filter, which is another way to send audio. Looking in the internals of how it works, it is using a completely different mechanism. It is using a proprietary waveOutMessage call to open a new message queue, which audio is then “streamed” through.
Pocket Player (and other applications) could possibly resolve this issue by using the HTC Audio Renderer instead of their own waveOut routines, but then we would lose crossfading and other Pocket Player –specific features. We did some initial tests of creating a DirectShow filter graph (complete with their Audio Renderer) but still experienced the skipping, so there must be additional steps.
As a result, Conduits is now regarding this as a device-specific problem that the manufacturer is obligated to fix. Alternatively, if HTC wants to document their special “streaming mode” for their audio output driver, we could look into adapting to that model.
Click to expand...
Click to collapse
If you extract the Wavedev.dll from a ROM, you will see countless debugging messages regarding “MP3 Streams” and the like, indicating an entirely separate audio path for music coming from their software. If need be, we will rewrite our WaveOut output plugin (our output routines use a private plugin architecture just like our other plugin types) that uses the DirectShow output.
Click to expand...
Click to collapse
THE REWARD
US $15 - thx1200
Euro 8 (~US $10) - Prewien
US $15 - paulosgsf
US $20 - kennyb123
US $5 - john-vogel
US $15 - jay_zhead
US $10 - wired69
US $15 - Vince2301
US $20 - Liquid211
TOTAL: US $105
its a nice challenge for someone who's smart enough to really do this.. but it shouldnt be our problem in the first place
i'm stuck to this phone till nov. 2010.. so if htc doesnt fix this within a reasonble ammount of time and someone here on xda does, my 10 dollars (approx. 8 euros) is in too
I just bought my HTC and must stay with it till 2010 as well.. im on. $10.00
I really want my Fuze to be my primary music player.
I pledge twenty smackaroos...USD.
Let's get this fixed!
If HTC fixes it for 3rd party software, they don't get my cashola, just my appreciation for taking care of an issue that should have never existed in the first place.
5$ from me! (If it will work also with my HD)
The problem has supposedly been fixed in the latest HTC Diamond ROM revision (2.03.x.3).
AnnihilatorSC said:
The problem has supposedly been fixed in the latest HTC Diamond ROM revision (2.03.x.3).
Click to expand...
Click to collapse
Supposedly is the word... The issue is annoyingly present still.
Nothing has been fixed in the latest ROM. It's exactly the same as it was before.
I'd happily pay for a solution for this. Put me down for 15$.
I don't buy HTC touch hd till now cos of this problem, I don't understand why HTC still not fix it, or they can't cos it's hardware problem ?
Put me down for $10 (possibly more if I'm not too skint) but ONLY if the fix works with Pocket Player
Count me in for $15
Today the lag annoyed me more than earlier...
Almost to $100...
Thanks everybody! We're almost to $100.
How do we get mods to sticky this sucker? :-D
im gonna start bugging t mobile now for this... gonna head over to the shop
Updating my donation to $15 so we can have an even $100 reward!
Okay everybody, this is a good reward for a hobbiest! Evangelize this post around the WM community (but don't spam). Get the WM blogs to write about. Get exposure. Let's get some brains working on this problem and also keep increasing the pot.
So I do the same!
Updating my donation to $15!
so more than $100,00 for the one who fix the sound bug..
We were up to $125, but xda crashed and the restore from backup knocked off the last posts. :-( I hope people will repost those donations!
Thanks!
I see my donation of $20 is missing. I'm posting again...
Fix this annoying problem and you shall recieve $20 from me.
Liquid211 said:
I see my donation of $20 is missing. I'm posting again...
Fix this annoying problem and you shall recieve $20 from me.
Click to expand...
Click to collapse
Added back! Thanks!
Fixed:
http://forum.xda-developers.com/showthread.php?t=505928
flinx1 said:
Fixed:
http://forum.xda-developers.com/showthread.php?t=505928
Click to expand...
Click to collapse
I SAW! I just downloaded and will report back if it works with PocketPlayer. So far, people are saying it does. If it's true, I'm happy that HTC has finally acknowledged (let alone fixed) this issue!
EDIT: SCREWED THE OS ON MY SPRINT TOUCH PRO. Won't boot after installing. Please be sure to have a recent backup. Glad I did. I think it may not be CDMA compatible. :-( :-( But if somebody can somehow reverse engineer this sucker and make a CDMA version (or if HTC does), that would be awesome.
Hey guys I am a newbie to app development and I have gotten as far as doing the tip calculator. I am trying to make an intervalometer app based on the ti- calculator app at the link below. Basically, it would use the headphone jack to trigger a camera remote shutter release at a predictable rate for time lapse photography on a Canon DSLR. Here is the TI-83 reference. Any idea how to do this on android. Any help or advice is greatly appreciated.
http://potatoeskillme.com/code/ti-86-intervalometer-for-canon-xti/
Dude, I'm really sorry I'm not skilled enough (yet) to help make this happen.
What a fantastic idea! I would love to see this happen.
Anyone have an idea how to access the audio port in code? I have to close the loop on the headphone jack for an instant and then release it.
You are attacking the wrong hole.
Audio jacks don't behave in the same way as the TI data jack.
Investigate using USB.
I would love to see some sort of wireless control of the camera's basic functions, similar to the hardware wireless control modules for those cameras.
Perhaps easier to accomplish and just as nice would be a way to make the camera a wi-fi storage device for those level Canon cameras. It would be sweet to snap shots to the phone for easy posting to the various places Android supports.
My guess would be that Dalvik (SDK level Code) doesn't have access to hardware level controls.
So this would have to have some Native (NDK Code) in c++ written to make it work. I don't think it would be entirely difficult for someone, but I personally have never tried to use an audio jack for anything other than..well...audio.
Kcarpenter said:
My guess would be that Dalvik (SDK level Code) doesn't have access to hardware level controls.
So this would have to have some Native (NDK Code) in c++ written to make it work. I don't think it would be entirely difficult for someone, but I personally have never tried to use an audio jack for anything other than..well...audio.
Click to expand...
Click to collapse
Yeah, that was kinda what I was afraid of. I have really bitten off more than I can chew with this project.
How I understand the wired remote works is that it just "shorts" the connection.
Now you may be able to simulate that by sending tones through the left/right and/or both poles. (one focuses the other shoots)
You could probably test if this would work by playing music through the cable and see if the camera reacts. I don't have a 1/8th to 1/16th cable or else I would try it myself because I am interested if it would work.
Here is a link of how to make a remote switch which you might find handy if you pursue this.
http://martybugs.net/photography/remote.cgi
Someone mentioned using the usb which would open a whole new world of what you can do. If you have ever played around with the canon software then you know you can control all the camera features from a computer and that should be possible to do on our phones but it would be a lot of work to write an app like that.
centran said:
How I understand the wired remote works is that it just "shorts" the connection.
Now you may be able to simulate that by sending tones through the left/right and/or both poles. (one focuses the other shoots)
You could probably test if this would work by playing music through the cable and see if the camera reacts. I don't have a 1/8th to 1/16th cable or else I would try it myself because I am interested if it would work.
Here is a link of how to make a remote switch which you might find handy if you pursue this.
http://martybugs.net/photography/remote.cgi
Someone mentioned using the usb which would open a whole new world of what you can do. If you have ever played around with the canon software then you know you can control all the camera features from a computer and that should be possible to do on our phones but it would be a lot of work to write an app like that.
Click to expand...
Click to collapse
USB is the way to go. I've written a few apps for windows that control canon cameras using the canon sdk. Unfortunately, the SDK is all C++, so a wrapper is needed to work with java. Plus there are functions that are windows specific. The other option for Linux is libgphoto2. Unfortunately, documentation is not the greatest (nor is it for csdk).
If I had more time, I would have coded this already. But all my coding time is spent programming for work.
centran said:
How I understand the wired remote works is that it just "shorts" the connection.
Now you may be able to simulate that by sending tones through the left/right and/or both poles. (one focuses the other shoots)
You could probably test if this would work by playing music through the cable and see if the camera reacts. I don't have a 1/8th to 1/16th cable or else I would try it myself because I am interested if it would work.
Here is a link of how to make a remote switch which you might find handy if you pursue this.
http://martybugs.net/photography/remote.cgi
Someone mentioned using the usb which would open a whole new world of what you can do. If you have ever played around with the canon software then you know you can control all the camera features from a computer and that should be possible to do on our phones but it would be a lot of work to write an app like that.
Click to expand...
Click to collapse
I am going to test your audio idea and see if it shorts the connection. Yeah, I wish I even knew where to begin with working on the USB. I am very new to this. The farthest I have gotten is building a potential layout for the program.
I just looked up some stuff.
I think the canon remote needs a little over 3volts to trigger the shutter. You are not going to be able to get anywhere close to that with the audio output.
I think the only option is to go through the usb.
centran said:
I just looked up some stuff.
I think the canon remote needs a little over 3volts to trigger the shutter. You are not going to be able to get anywhere close to that with the audio output.
I think the only option is to go through the usb.
Click to expand...
Click to collapse
Thank you for the info. I am downloading the Canon SDK right now(not that I have any idea what to do with it at this point).
is this still going? we are about to make the gsm hero usb-host-mode-able, then all that is missing is libgphoto2 and gphoto2... anyone fancy porting it?
First of all, sorry for my English.
I was searching in Google for something like this and I can't find nothing.
Using the usb is not simple, but the audio option is not crazy at all.
Obviously, that option will require some kind of interface, but can be much simple than the USB option.
You can generate different audio frequencies, for example, 1 KHz for focus and 5 KHz for shutter. With a filter for each frequency you can separate the signal in two circuits. Each circuit can trigger the camera with a transistor, in open collector configuration.
Whatever, if you choose one or another (USB or audio) you will must make some kind of electronic interface.
If someone can works with the software, I can do my part with the circuit. I'm sure that will be easy to build for anyone, even if you don't know electronics.
I am also looking into doing this sort of app, but I am starting with a Pentax k110d... Some camera's only require you to short out the wires, and doing so with the audio headphone jack seems to be possible, from the quick little test I just did with a media player, a 3.5mm jack extension cord, and a multimeter. When the track was playing, i got some resistance across the poles, but when I stopped it, I got nothing registering.
I had actually just given up on the headphone jack, and was looking into doing it over USB as well. I might just have to do several code paths, depending on what kind of camera the person is hooking up /ponder
Alrighty, I just did some more testing with a quick framework app that I had been working on for this. There is apparently a constant 1.7 mV on the headphone jack, which is enough to trigger the shutter release on my camera... boo urns... and when the tone is played, the voltage actually drops, because as all learned ppl know(at least those who paid some attention in physics) is that according to Ohms law, Resistance goes up, Voltage goes down.
Any progress on this?
I would love an intervalometer on Android for my Canon EOS 550D
+1 for the development of such app & hardware it may need.
i hate to bust your bubble but this died over a year ago
ya, development has kinda stalled out... I realized that it is not possible to do over the headphone jack, as there is always voltage there, and I don't know if it is possible just over usb...
The only way I can think that this would be possible would be to get ahold of a google hardware kit/arduino dev kit, and then program that.
Hello,
I really would like to use my "normal" headphones for making calls together with the internal mic. Everytime when I am listen to music and someone is calling me, I've to unplug the headphones...:-( Another example is: I've connected my samsung to my car via "aux-in" to listen to music over my loadspeaker in my car.
That would something like a hands-free system
So... I think/hope this is just a software problem and somebody here is able to manage this??
Thanks in advance!
kedek
I cant see anything about android development... We have a section for questions and answers! Please use the right sections!
if you want...
but I think we need developers to get this working...!?
there's already a thread about this. with an alternative hardware fix.
hanspeterlol said:
if you want...
but I think we need developers to get this working...!?
Click to expand...
Click to collapse
The guidelines for the proper location to post new threads is clearly outlined in the "STOP!! Before You Post, Read This NOW!!" thread at the top of the forum section:
Post What Where:
General - general technical discussion items, news, anything else that does not fit into the other fora categories.
Q&A (Questions and Answers) - all questions, irrespective of type, get posted in here whether they be theme related, accessory related, technical, etc.
Accessories - any items to do with components and/or accessories relating to your device.
Rom Development - only meant for very advanced technical discussion directly related to ROM development activity and the delivery of actual ROMs and ROM components ONLY. Nothing else goes in here.
Themes & Apps - anything to do directly with the development of themes and/or applications. Nothing else goes in here.
Click to expand...
Click to collapse
Adevem said:
there's already a thread about this. with an alternative hardware fix.
Click to expand...
Click to collapse
a fix that surely won't fix the problem with car Aux in, as the gain of the earphone mic is poor.
I think that doing a sw fix for the problem(listening through earphones, talking to the regular mic) will be appreciated by lots of people.
Sorry for posting in a wrong section...
Adevem said:
there's already a thread about this. with an alternative hardware fix.
Click to expand...
Click to collapse
But anyway... this hardware fix will not fix the problem in my car.
And I think a lot of other users wants to get this working? And thats the point why we need developers...
I think theoretically this should be possible..
hanspeterlol said:
But anyway... this hardware fix will not fix the problem in my car.
Click to expand...
Click to collapse
Which hardware fix are you talking about ? Using an adapter like Nokia AD-54 works with any 3.5mm headphone or audio out (including auxiliary line of a card audio system).
Other option is to use an A2DP BT car kit or a BT clip (like this).
Ok thanks... if this is the only solution, I will try it
But I also would like to have a software solution ...someday
Hi Guys
Would really appreciate some help with this one, i am sure it been covered to some degree in other threads.
Since owning my unit I have wanted one application to run and I am not fussed about anything else, the app is ALPconnect.
ALPconnect is a application that connects to my radar detector via BT 4.0 only so it displays all the information on the dash for radar frequencies.
https://play.google.com/store/apps/details?id=com.alpriority.alpconnect&hl=en
Due to the limitations in the Bluetooth, no current rom has been able to allow the application to turn the BT on and search for the ALPconnnect Module
http://www.alpriority.com/product/alpconnect-bluetooth-module-gen2/
Over on the other forum i am apart of http://radarandlaserforum.com, one member has spent upwards of 2000$ buying android head-units to see if this app would run and connect on it.
our small thread is ongoing at @ http://radarandlaserforum.com/showt...-InCar-Enetertainment-unit-ALPconnect-Testing about this issue.
I don't normally ask for help, but I could really use some help and I am sure others on the forum that purchased it for that reason would greatly appreciate it too.
This is the last information I received from agentdr8, thank you aswell
agentdr8 said:
It's severely limited, when compared to any other Android device with BT. This is due to the OEM's choice of the BC5/BC6 module, and their poor BT implementation. Instead of routing BT audio traffic through the Android system, like a normal device would, they route it through the MCU. That would be fine on its own, except they route pretty much all BT interactions through the MCU, via serial AT commands, which is very non-standard. Simple things like pairing, or using SPP profile just don't work, or require a bit of finagling.
On top of that, there's code (at least in MTCB; dunno about newer MTCD) in MTCManager that filters which devices can pair via BT for OBD use. It checks the device name and if it starts with OBD, it will allow it to pass to the next step during pairing. I can only imagine they chose to do that so they could sell their companion BT OBD adapters with the headunits?
My XMTC module had accounted for this limitation in name-based filtering (apparently not the only limitation though; if your adapter was at least v1.4 it should work), but it hasn't been updated to work on any 2016 roms. Since I no longer have time to maintain that project, it's been open sourced on my github. The BT pieces could be extracted into their own module, but I thought I had read someone else (maybe MVG70?) had made a BT xposed module for these devices to try and address compatibility issues.
Click to expand...
Click to collapse
Just as a thought
Would the MTCB be able to support external USB BT 4.0 thus removing the need for the messy internal BT
Sent from my iPhone using Tapatalk
shanetrainST said:
Just as a thought
Would the MTCB be able to support external USB BT 4.0 thus removing the need for the messy internal BT
Click to expand...
Click to collapse
I think it's been discussed before, and no one has successfully added an external BT adapter to these headunits.
Has that group tried the app on the Parrot Asteroid? I know it wasn't the highest rated Android headunit, but it might be more "standard" than how these ones are configured.
agentdr8 said:
I think it's been discussed before, and no one has successfully added an external BT adapter to these headunits.
Has that group tried the app on the Parrot Asteroid? I know it wasn't the highest rated Android headunit, but it might be more "standard" than how these ones are configured.
Click to expand...
Click to collapse
Thanks agentdr8, but it does not really help the ones that splashed out and bought the HuFei units
Is the reasoning behind the external BT not working because nobody is interested in making it work or is it not technically possible?
shanetrainST said:
Thanks agentdr8, but it does not really help the ones that splashed out and bought the HuFei units
Is the reasoning behind the external BT not working because nobody is interested in making it work or is it not technically possible?
Click to expand...
Click to collapse
Since the kernel is not open source, there's very little hope of adding the necessary drivers to support external BT adapters. Aside from that, I don't believe the BT stack that is included in these roms is standard.
I won't say it's impossible, as given enough time and money, anything is possible. But I doubt it's something anyone here can address without the sources.
Guess the manufacturer is reluctant to release the source then.
Sent from my iPhone using Tapatalk
agentdr8 said:
Since the kernel is not open source, there's very little hope of adding the necessary drivers to support external BT adapters. Aside from that, I don't believe the BT stack that is included in these roms is standard.
I won't say it's impossible, as given enough time and money, anything is possible. But I doubt it's something anyone here can address without the sources.
Click to expand...
Click to collapse
Just a couple of questions
1.Do you know if any developer is currently working injecting the drivers into the kernel, as impossible as it sounds.
2.If the manufactures were to fix this issue, what things should they include to make external BT work?
3.Have any of the manufactures hinted at releasing the source and letting other developers fix the issue with custom roms
Just on another note
I have 30 emails from Eonon saying that their tech cannot do this and have assured me that.
We have our own brand and R&D department.
We use our software.
Click to expand...
Click to collapse
Which I don't believe for a second
I'm quite interested in getting this fixed as well - I have both an ODB2 adapter and Navdy that I'm unable to connect due to this limitation. And the fact that there's no available workaround via External BT is infuriating.
shanetrainST said:
Just a couple of questions
2.If the manufactures were to fix this issue, what things should they include to make external BT work?
Click to expand...
Click to collapse
From my understanding, the only way to get this to work is through an external (USB) BT adapter, since the built-in BT stack sends everything through the MCU instead of directly to android. So enabling the proper USB drivers for BT in the Kernel would fix it. I'm not aware of any other USB devices that don't work (maybe gamepads or other HID devices, unconfirmed) so it seems they've cherry picked which USB devices to allow. Considering the otherwise hackable nature of these devices, it'd make sense to me to just enable all available USB devices and let us plug in whatever we want to plug in.
I'm in the same boat. I have an OBD adapter (Hondash) which refuses to pair. I've tried 2 Xposed modules which are supposed to sort this. I'm wondering if my particular issue is down to my 5.1.1 ROM so might try it on my old RK3066 4.4.4 HU which I gave to my Dad.
So I'm monitoring this thread in the hope a fix is found.
I am doubtful, I have contacted Klyde/Eonon/others and nobody is willing to release the kernel source code or address the issue.
So when someone gets a copy from Klyde/some reseller/MTC or whoever and a developer has the motivation to correct it, that can be the only solution.
I have given up hope on this one
Sent from my iPhone using Tapatalk
Does anyone know the location in the Android file system where the Bluetooth pairings are saved?
FINALLY! Someone with a similar issue. I've got a Valentine One, and the BT module for android, (connecting using YaV1) and I've been trying to get my android unit to pair with it as well. In for potential solutions.
This question may be off topic, and I apologize for that, but are you referring to the app not being able to turn on BT and look for the adapter; just getting stuck at "Turning on bluetooth..."?
I have an OBDII scanner which I can pair no problem. When I use a specific app (OBD Card Doctor Pro (or reg)) and attempt to connect it, I get a prompt letting me know that an app wants to turn on BT. I click allow and then it just sits there and never does anything. Is that the problem ALPconnect has?
Torque does not prompt me with this and initiates the BT connection just fine.
The main issue here is that the bluetooth hardware is in effect emulated to the android subsystem for the nice bluetooth dialler front end so android has no real control over the bluetooth hardwrae. These headunits have some real downfalls and this is one of them What we need is to break this open and rewrite it. Without sources we can't do that. We could maybe dissasemble bits and replace them in code but the rom is factory odd and hacked to bits!
monza20vt said:
The main issue here is that the bluetooth hardware is in effect emulated to the android subsystem for the nice bluetooth dialler front end so android has no real control over the bluetooth hardwrae. These headunits have some real downfalls and this is one of them What we need is to break this open and rewrite it. Without sources we can't do that. We could maybe dissasemble bits and replace them in code but the rom is factory odd and hacked to bits!
Click to expand...
Click to collapse
So this emulated effect is what causes my system get stuck "Turnning on bluetooth..." if I understand you correctly? There's no Android control over the BT hardware so the request is just lot in limbo?
I updated to CM 13 build 13.0-20161003 from previous version now my headphone jack is dead. Please help. Considering miui eu can idea should I move to it? I guess its more stable than CM13? I do love stock android feel
Maybe you should read in this thread http://forum.xda-developers.com/mi-5/development/rom-cyanogenmod-13-0-xiaomi-mi-5-t3457752 .
At moment CM13 was using official kernel . And dev still working to fix headphone audio routing . http://forum.xda-developers.com/showpost.php?p=68966268&postcount=456 .
Terribly sorry to bump this thread, but I am not (yet) allowed to post in the cm13 thread and I have just noticed on my 20161106-nightly that the audio jack won't work with a simple audio 3.5-to-3.5 jack (to connect to a hi-fi, or a car audio system for instance). Headphones with a built-in mic/remote do work perfectly however, those with 3 rings on the jack.
Now I do remember seeing this mentioned somewhere here, but can't find the post anymore after searching quite a bit..
Anyone else (still) having such issue with the latest cm3 builds? I haven't installed anything crazy other than regular Play Store apps and haven't tweaked the phone much. No Xposed or stuff like that.
Cheers!