yashsingh1/xdaforums huggingface dataset:
[Touch Diamond, MDA Compact IV General] Sleuth255:
yep, the HP only has A2DP: 0000110b- under services. AVRCP must be a subset of A2DP then and is handled differently in newer devices. Time for some digging in the BT profile docs...

edit: nope, not subset. In fact, v1.3 supports the exchange of title/now playing information. I bet that's how the BT stack knows how to route: by the version of AVRCP that the paired device supports.
[Touch Diamond, MDA Compact IV General] Sleuth255:
hmmm... as expected, shadowing wmplayer.exe stops it from popping up and suggests a workaround using a shim and the older avrcp_MPplugin.dll. Hopefully it has some obvious exports to try...

edit: nope. Not simple. At first glance, it appears to register a class that can receive the keycodes.
[Touch Diamond, MDA Compact IV General] Arktronic:
This just keeps getting stranger. Here are some of my findings.

Whenever TF3D starts playing anything, it always kills WMP. This may be the HTC Audio Manager's normal functionality, I don't know.

The current window - WMP or TF3D - always has priority in receiving AVRCP messages. When another window is selected, one that doesn't support AVRCP, behavior is erratic. Sometimes WMP will get it, and other times TF3D will.

At the moment, I'm not sure how TF3D gets the commands, but WMP appears to get them through the "HTC WMP Control Plug-in". Using dotFred's Task Manager, I monitored that plugin window's (0x7c09b540) messages, and they corresponded to what I was pressing.

TF3D starts AudioManager_eng.exe when the Music tab is selected - either by the user selecting it or by AVRCP. I don't know how useful that might be.
[Touch Diamond, MDA Compact IV General] Sleuth255:
Damn! I tried my HP headset and now its not working either! I've also not been able to reproduce the sequence that got it running yesterday. Very frustrating!!!

edit: I'm thinking this is a CorePlayer bug. The feature is marked "experimental" in this release.
[Touch Diamond, MDA Compact IV General] Arktronic:
Have you tried using Pocket Player? It hasn't worked for me, so this might not be a CorePlayer bug.
[Touch Diamond, MDA Compact IV General] Sleuth255:
I had mixed results with PP. When set up, it would show the keycode in the upper left side of my screen each time I pressed a button on my headset. However, PP itself wouldn't always respond. I chalked it up to a "gen 1 fix" situation.
[Touch Diamond, MDA Compact IV General] Sleuth255:
Yikes! Working again!

Hey Trancecoder: Try removing "htcstartup.lnk" from your windows\startup folder and re-boot. I just did this and (fttb) my HP headset is working with coreplayer again. :eek:

edit: looks like its the re-boot that's doing it because on the second time I try to pair, WM comes back up. Vs...

edit2: is there some sort of startup proc that's hooking the plugin to WMP? I'm gonna try waiting 5 minutes b/f pairing. If a startup proc is running then WMP should activate....

edit3: Well lookey here! WMP is being activated if I wait a few minutes b/f pairing! Now to see what gets executed....
[Touch Diamond, MDA Compact IV General] Upquark:
Keep up the hacking guys! This is exciting... hoping for a solution! :)
[Touch Diamond, MDA Compact IV General] Sleuth255:
Going through running services now..

So far, HTCAppService and HTCService have been eliminated as culprits...

I can't help but think that there's something that starts a resident portion of WMP which then hooks the plugins. I think I'll take a closer look at WMP components from the dumped ROM using IDA to see if anything leaps out...
[Touch Diamond, MDA Compact IV General] Arktronic:
I tried disabling everything in the BootLauncher (HKCU\Software\HTC\BootLauncher) but WMP is still taking over... I think I'll just hard-reset and try this again, with nothing installed in a clean ROM.

EDIT: That got me nowhere. I hope you have better luck disassembling WMP components, Sleuth.

One potential course of action would be finding the Lua script responsible for TF3D's Music tab, decompiling it, and seeing what it does. This, of course, assumes that (1) there is such a script, and (2) it actually does something non-trivial.
[Touch Diamond, MDA Compact IV General] defaria:
Are you running TouchFlo or not. If not then there's additional steps for Pocket Player on an HTC Touch. See the Pocket Player forum for details (or click here - crossposting forums - the new sin!)
[Touch Diamond, MDA Compact IV General] Sleuth255:
Yeah, I followed that including the step to check the "take over from WMP option" which wasn't included in the writeup.

Another wrinkle: With My HP headset I can get repeatable AVRCP control by using the following steps:

power up headset

reset TP

as soon as today screen is up, go to bluetooth settings, tap/hold the HP headset and choose "set as wireless stereo"

Unfortunately with my Nokia headset, this procedure doesn't work....

Fascinating pblm we have here...
[Touch Diamond, MDA Compact IV General] Sleuth255:
hmmm... it looks like none of the WMP UI plugins are responsible for this. When I removed both the HTC WMP Control plugin and the WMP Mobile A2DP plugin clsids from HKEY_LOCAL_MACHINE\Software\Microsoft\MediaPlayer\UIPlugins, there was no difference in functionality: AVRCP remained hardcoded to WMP. Coreplayer, however, couldn't see the UI Plugins any more (as expected).

Some other mechanism is in place it would seem that has outdated the UI plugins or the reg entries that refer to them...

edit: more info.

avrcp_mpplugin.dll and htcwmpplug.dll are being completely bypassed by the mechanism that hardcodes AVRCP to WMP. I just shadowed them both and WMP still intercepts AVRCP commands. HTC has bastardized Microsoft's own MP plugin architecture to accomplish this bit of stupidity....

edit 2: more info. Not completely. There's two processes in place: When the A2DP connection is made, WMP is launched regardless of the state of the UI plugins. However, the AVRCP controls are not working so it would appear that the UI plugins still handle the messages. Now to find out if its registry control, which registry key and which plugin...

edit 3: unshadowing htcwmpplug.dll allowed avrcp commands to control WMP. When I removed that clsid from HKEY_LOCAL_MACHINE\Software\Microsoft\MediaPlayer\UIPlugins AVRCP control to WMP was lost. Now to unshadow avrcp_mpplugin.dll, the other UIPlugin.

wouldn't it be nice if I could use this one to control coreplayer....

edit 4: truly diabolical. There are two issues:

Every time an AVRCP button is pressed, something activates the WMP window. This is one thing that needs to be overridden that has nothing to do with any AVRCP command processing.

Only the HTC WMP plugin is active. avrcp_mpplugin.dll isn't getting AVRCP messages it would appear. So HTC has a shim in the BT stack somewhere...
[Touch Diamond, MDA Compact IV General] Sleuth255:
Ok, I think I know how the mechanism is working. Key to this is the process that activates WMP when the A2DP connection is activated or any AVRCP button is pressed. I've got one more test to do with my HP headset to confirm my suspicions. What is happening is this:

WMP executes and loads the UIPlugins which register the classes needed to receive AVRCP keypress messages. As we know, Coreplayer can't detect audio stream changes so we Coreplayer users generally activate the A2DP connection then run coreplayer. Coreplayer also launches the dlls associated with the WMP plugins but the associated classes are already registered by the WMP versions so they can't receive messages. Ok, easy enough. Just stop WMP from executing by shadowing wmplayer.exe.

This brings us to the second issue: Coreplayer can't use the HTCWMPPlug.dll yet. Even though it appears to be loading it, Coreplayer still ignores button presses. However, tapping pause on Coreplayer now causes my headset to display "paused" so its sort of working in one direction.

Which brings me to the HP headset test. I believe that this headset uses an older version of AVRCP which cuases the BT stack to route AVRCP commands to the older AVRCP_WMPPlugin.dll that Coreplayer can use. If I'm correct, the HP headset will work perfectly all the time now because WMPlayer.exe has been shadowed and is no longer executing the plugin itself. I've got to drive to work to test this however since my HP headset is there...
[Touch Diamond, MDA Compact IV General] Sleuth255:
Classname notes:

AVRCP_MPPlugin.dll registers:

MPPlugin_AVRCP_CW_ClassName

HTCWMPPlug.dll registers:

HTC WMP Control Plug-in

and

HTC_WMP_PLUGIN_WORK

It might be possible to register the correct HTC plugin classname, recieve the messages posted to the class messagequeue, translate AVRCP keycodes to the older format, then post the translated messages back to the AVRCP messagequeue. This would allow backwards compatibility with CorePlayer or any player that loads the avrcp plugin.

I'll have to play with this a bit...
[Touch Diamond, MDA Compact IV General] Sleuth255:
CorePlayer users: this makes things a bit easier

copy player.exe from program files\CorePlayer to windows\WMPlayer.exe

Now connecting up your headset will execute CorePlayer instead of WMP. Also, pressing any AVRCP button will activate CP the window. It'll even wake up your device if its sleeping.

Now you're prepared for the AVRCP shim (hopefully I can figure out how to make it work...) ;)
[Touch Diamond, MDA Compact IV General] Sleuth255:
Well, lookey here!

Now that I have CorePlayer being launched, I've been able to follow TranceCoder's lead and do some investigating with dotFred's taskmanager. It appears that v3.1 of the Taskmanager has the window function working on my TP (something I wasn't aware of)

Here's what I did:

I changed CP to only load the WMP AVRCP plugin and sure enough, it launches it. When the plugin is loaded it registers the following:

windowname: MPPlugin_AVRCP_CW_WindowName

Classname: MPPlugin_AVRCP_CW_ClassName (as I previously discovered with IDA)

Here's what's truly wierd: Not only am I seeing messages through the AVRCP plugin every time I press a button on my headset now, but CP still isn't responding :eek:

My guess is that the keypress messages themselves have changed due to the improved BT stack that now handles the more current AVRCP profile that my Nokia headset uses. Since my HP headset works, it should be easy to see how the messages have changed too.

I should have many more answers on Monday when I return to work.
[Touch Diamond, MDA Compact IV General] Arktronic:
That's some nice sleuthing!

Do you think the AVRCP DLL calls anything in order to start receiving messages or does the external message sender just rely on the window/class names? If it's the latter, we could easily emulate such a window and create our own "message distributor" app, possibly even replacing avrcp_MPplugin.dll with a custom version that gets messages from this app and converts them to the old format that third-party apps are expecting.

I've been trying to create a custom window like that in managed code, but I'm getting stuck on P/Invoking RegisterClass(). This is probably a lot more painless if done in unmanaged code; I just don't feel like dealing with that ;)

So anyway, if all that's required to process AVRCP messages is the proper class and/or window name, then this issue is pretty much solved... not counting TF3D, that is.

If you, Sleuth, or someone else, could whip up a quick test app that creates a window with the proper class and title and monitors messages arriving to that window, that'd be a great next step :D
[Touch Diamond, MDA Compact IV General] Sleuth255:
Ok, here's what I've uncovered:

In all cases, the message type is 8001 and the keycode itself is in WParam. Here's a map:

HP headset with AVRCP working (doesn't activate WMPlayer window either):

stop/start = 46

<< = 4B

>> = 4C

HP headset after I wait a bit (activates WMPlayer window)

all messages = 4A :eek:

Now here's what's interesting:

Nokia Headset (always activates WMPlayer window)

every keypress sends two messages:

stop/start = 4A followed by C4

>> = 4A followed by CB

<< = 4A followed by CC

So, how to fix? I could go with your idea TranceCoder which would be to replace AVRCP_MPPlugin.dll with our own design. While I can easily register the class and begin receiving avrcp messages, I don't know the plugin API (the interface between a plugin and WMP). The plugin API is public I believe so I just need to scrounge up some documentation.

Another way to do it would be to hook AVRCP_MPPlugin.dll's MQ in the same way that DotFred's Taskmanager does. Then, for example, when I see a C4 come in, I simply post a 46 out to the MQ and let the plugin deal with it as it normally would. The problem with this is timing. I need to know when to hook the plugin's MQ (ie when the dll is loaded) as well as when to unhook it (can use WM_DESTROY for this so not difficult).

The best technique would be to actually create a dummy WMPlayer.exe and leverage the "auto WMP execute" feature in these ROMs to not only envoke the hook but also to launch the real player of your choice.

First off however, I'm going to write a quick ditty to register the MPPlugin_AVRCP_CW_ClassName class and display received messages just to verify as you have also suggested.
[Touch Diamond, MDA Compact IV General] Sleuth255:
What the messages mean

Current hypothesis:

I'm guessing that since AVRCP v1.3 expands the profile to handle displays as well as keypresses that the first message is now some sort of preamble identifier (although why they didn't just use LParam for this remains a mystery). Therefore I'm guessing that the "4A" message means "keypress data to follow" and that there's a different message for "Display updates" to follow. Why AVRCP changed the button messages themselves from 46,4B and 4C to C4, CB and CC is also a mystery.

What I need to do is find technical documentation on the various AVRCP profile revisions.
[Touch Diamond, MDA Compact IV General] Arktronic:
Shouldn't display update messages be coming TO the headset, not from it? What would be the purpose of changing the calls then? Newer AVRCP revisions have got to support something new to send to the host. Display characteristics, perhaps?
[Touch Diamond, MDA Compact IV General] Sleuth255:
I'm sure its something like that.
[Touch Diamond, MDA Compact IV General] Sleuth255:
Getting AVRCP messages is not as simple as registering the class/window. Looks like an IDA session with AVRCP_MPPlugin.dll is next....
[Touch Diamond, MDA Compact IV General] Upquark:
Any news? :)
[Touch Diamond, MDA Compact IV General] Sleuth255:
I'm currently looking for a way to hook the avrcp_mpplugin.dll messagequeue. I know it is possible because dotFred's taskmanager does it. I've also been in discussions with CP on this to see if they can come up with a fix on their end.
[Touch Diamond, MDA Compact IV General] Arktronic:
I tried to hook the AVRCP window by calling SetWindowLong() changing its WndProc to my own proc and monitoring window messages there, but every time I'd do that, it would hose the app that was originally hosting it, be it WMP or CorePlayer. I'm guessing it's because my thread doesn't own that window.

Do you know how WMP/CorePlayer host WMP UI DLLs? Is there any good documentation on it - what publicly accessible methods have to be called, etc?
[Touch Diamond, MDA Compact IV General] Sleuth255:
I'm sure that doc must be publicly available. All the major players use the plugin UI.
[Touch Diamond, MDA Compact IV General] havoc479:
Any updates? :)
[Touch Diamond, MDA Compact IV General] Upquark:
Just wanted to let you know that there's a special version of Pocket Player 4.0 that did the trick for me. :)

It's available on request (just send a mail to Conduits support).
[Touch Diamond, MDA Compact IV General] Owl:
Unfortunately no good news from Pocketmind (Pocketmusic 5.0):

"The problem is known to us. It exists on both HTC Touch Diamond and HTC Touch Pro because HTC did tight integration between AVRCP bluetooth driver and their Touch Flo3D music player. The driver forcefully starts the TF3D player each time any command is received from bluetooth headset. And the control events are sent directly to their player.

We have invested a lot of effort trying to develop some workaround for that issue, but did not find any really usable solution yet. We will continue our tries, but due to the closed nature of HTC's software we can't be sure if it is possible at all."

Any pocketmusic-users out there who found a GOOD alternative?
[Touch Diamond, MDA Compact IV General] Upquark:
Well, perhaps you could point out that it IS possible (i.e. Pocket Player).

I must say, PocketMusic used to be my favourite player, but I've found AVRCP to be so cool and handy... there's really no alternative to PP right now.
[Touch Diamond, MDA Compact IV General] Arktronic:
AHA! Da_G posted about WM6.5 build 21602 that has updated drivers, one of which finally breaks the dependency on WMP. Problem solved?

See http://xdaforums.com/showpost.php?p=3806118&postcount=5048
[Touch Diamond, MDA Compact IV General] thx1200:
Dude that would be so awesome! I mean PP has had a workaround in place for a while now, but to be able to use the native support instead of using the stupid WMP plugin would freaking MAKE MY DAY!

Please, please update this thread if you discover anything new. I, for one, would like to get a cab of that driver and see if it even loads on my old WM 6.1 OS. If it loaded and worked, I would be so happy!
[Touch Diamond, MDA Compact IV General] Captain_Throwback:
I was excited to see that news as well. I'll gladly cab up the DLL once Da_G makes it available.

EDIT: As promised, here is the HTC BT driver from the 216XX 6.5 ROM that Da_G provided, in cab form. I haven't tried it yet (though I have installed it), so I don't know how/if it works.

If this will allow me to use AVRCP with HTC Music Player while using TFDetacher, this would make my day!
[Touch Diamond, MDA Compact IV General] pinkoswitch:
May I ask if this cab is meant to play with HTC Music Player or any player pls as I'm using pocketmusic...

thx u lots...
[Touch Diamond, MDA Compact IV General] Captain_Throwback:
Its just an updated DLL. It shouldn't matter what player as long as it supports AVRCP. Read the original post from Da_G quoted by Trancecoder only a few posts ago.

I haven't tried it, so I don't know.
[Touch Diamond, MDA Compact IV General] Arktronic:
I tried it on my drive home.

IT'S ALIIIIIIIIIIVE!
[Touch Diamond, MDA Compact IV General] Jiggs1337:
Will this work on WinMo 6.1? And will it work on TouchPro?

I would LOVE to finally fully sort this problem.
[Touch Diamond, MDA Compact IV General] thx1200:
I wonder if this will work in WM 6.1. I need to make a good backup before I try. :-)
[Touch Diamond, MDA Compact IV General] Mr_Q:
Confirmed to work with Windows Mobile v6.1.

There is no need to backup in my opinion as you can always remove the file/cab using 'Remove Programs'.

BTW, tested it at HTC Topaz (Diamond2)

[EDiT]

Some additional information

PocketMusic aswell as PocketPlayer seem to work fine without any modifications, however..

I am using S2U2 (v1.62) and when my (manually) screen is turned off I got the following result:

- PocketMusic only responds once or doesn't respond at all.

- PocketPlayer keeps responding to the key, even with S2U2 active and also with the screen turned off.

My next question will be, is PocketPlayer consuming more battery then PocketMusic?
[Touch Diamond, MDA Compact IV General] jeutaw:
Works with PocketMusic on my AT&T Fuze with Stock/AT&T ROM.

Thanks to All for all there hard work!
[Touch Diamond, MDA Compact IV General] thx1200:
I'm sorry, I must comment that making a backup is always a good idea!

Sure, if you can boot your phone, you can always remove. But if it freezes on boot (like the official "audio skip hotfix" does on CDMA phones), you're screwed and need a backup.

But thanks for testing it out!
[Touch Diamond, MDA Compact IV General] Murz:
Thanks! Works good on WM 6.5 on HTC Touch HD with MortPlayer: I can control play/pause and prev/next via AVRCP on mortplayer.

But when mortplayer is unloaded, it isn't start when I press "play/pause" like a windows media player. Maybe I need to change the url of exe someone in registry?
[Touch Diamond, MDA Compact IV General] lbhocky19:
anybody tried it with core player?
[Touch Diamond, MDA Compact IV General] Captain_Throwback:
Yup. It works :).
[Touch Diamond, MDA Compact IV General] izzyzc:
Hi!

Should this new bthci.dll work on other devices running WM6.1?

Coz I tried installing the cab in my Jade and it didn't work... My bluetooth actually stopped working... It can't see any bluetooth devices nor can it be seen by others...

TIA!
[Touch Diamond, MDA Compact IV General] Arktronic:
No, this file is highly device-dependent. Sorry!
[Touch Diamond, MDA Compact IV General] Northernmost:
Working brilliantly controlling the lastest version of Kinoma Play (at last!) on my HD (Dutty 6.1 Extreme ROM V3.4) paired with an HTC S100 headset. Big thanks! :cool:
[Touch Diamond, MDA Compact IV General] izzyzc:
Oh that's bad.... Hope a similar update comes out for the Jade..

Thanks for the info! :)
[Touch Diamond, MDA Compact IV General] volwrath:
Thanks. Works great with Kinoma and my CDMA Touch Pro
[Touch Diamond, MDA Compact IV General] beachbumAAAA:
Bricked my phone

I installed T-Back's cab file but it bricked my phone. Kept getting stuck on the green WM 6.1 screen during soft reset. Had to hard reset :( Good thing I had a backup.

I have a Verizon Touch Pro with stock 6.1 ROM. Any ideas why that happened?
[Touch Diamond, MDA Compact IV General] Captain_Throwback:
First off, by definition, if you could hard reset your device, then you didn't brick your phone. I'm not sure why that would've happened. There has been confirmation of the driver working on both GSM & CDMA devices.
[Touch Diamond, MDA Compact IV General] beachbumAAAA:
OK, sorry if I used the wrong term. I know that it's worked for others on their Touch Pros. I wouldn't have tried it until I had seen that - I don't like being the guinea pig. I even tried installing it immediately after the hard reset, before any other apps had been installed, and it did the same thing. Had to hard reset it again. So there must be some incompatibility. I have the Verizon WM 6.1 phone, and I don't know if the others were on Verizon or Sprint. Could be one of the VZ customizations is the problem.
[Touch Diamond, MDA Compact IV General] Arktronic:
Generally a device will do that when an improperly signed driver is loaded onto a ROM that hasn't been patched to accept all DLLs (such as your stock ROM). If the Cap'n didn't use Chainfire's DriverWiz to create the CAB, then that's the problem.
[Touch Diamond, MDA Compact IV General] Captain_Throwback:
You know that I, of course, DID use DriverWiz, right? (it's not my first time, lol)
[Touch Diamond, MDA Compact IV General] Arktronic:
Hey, no insult intended. That was just the first thing that came to mind.
[Touch Diamond, MDA Compact IV General] Captain_Throwback:
Understood. No worries. As a practice, for single DLL files, I exclusively use DriverWiz, as it's the easiest and most effective way of signing the files. It is, however, not foolproof (i.e. it doesn't work for everyone all the time). I guess this is one of those times.
[Touch Diamond, MDA Compact IV General] beachbumAAAA:
So how do I get it to work?
[Touch Diamond, MDA Compact IV General] momo80:
unfortunately, it does not work on my touchpro2. :( Believe it's because HTC shifted to use the Widcomm stack this time round.
[Touch Diamond, MDA Compact IV General] Arktronic:
Just install the CAB, soft-reset, and use your AVRCP-compatible programs normally.

Seriously, Widcomm? I didn't think HTC would ever come back to that stack. What an odd move. Are you sure about this?
[Touch Diamond, MDA Compact IV General] beachbumAAAA:
As I already said, it wouldn't come back from the soft reset and I had to do a hard reset. I was hoping for a different answer.
[Touch Diamond, MDA Compact IV General] Arktronic:
Durr, sorry, lack of caffeine. If the CAB doesn't work for you, then there's probably nothing you can do to get it to work short of flashing a new ROM.