Closed myhades closed 5 months ago
Hi. If headphones supports Ear Detection feature, it must work. When you connect headphones with ear detection is turned on. The MagicPods wait while you put in headphones to the ears and after it switch the audio output to headphones and play the music.
if headphones does not support Ear Detection feature, the MagicPods just send play command, because I can't detect what state do you have. For example some users like to switch between external speakers and headphones, so when user connect headphones I can't know must or not to switch audio output to headphones.
There is also another problem, some user also disable Headset or Headphones services, so the MagicPods will wait activation for audio service that was disabled by user. It may took to 10 seconds.
I wrote your issue, but I am not sure what to do and when I could start, because I make a lot of work under the hood of MagicPods.
For now you can disable headset
service if you do not use it. It will improve connection speed. In my tests the connection with headset
and headphones
services took about 2 seconds, when I disable headset
it took less than 1 sec.
Thanks for such a quick reply. In my specific case, where I'm using AirPods Pro gen2 with ear detection supported and any other system settings default, delay sending play command until the following conditions are met seems reasonable:
1) Current playback device is set to the headphone. (Whether manually or automatically) 2) Headphones are in ear (if ear detection is available, otherwise treats like they are) 3) Audio service is ready.
And sorry if I didn't quite understand, but I didn't find any windows service whose name involves "headset". Also, appreciate the amazing job. Definitely notice the astonishing work under the MagicPods by simply compare the overall perfomance of the UI to other UWP apps and faster-than-idevices detection speed
This is fixed in new versions of MagicPods
Hi! The problem is, there is like 2-3 seconds of delay before the "audio and voice is connected" after the device appears to be "connected", during which the audio is still coming from the speakers. But auto resuming kicks in too early, which results in early playback on speakers and lots of awardness when using in a library. I don't know whether windows bluetooth stack reports status like this or not, but there is a shift in current playback device, which can be used to detect "actual" audio connection. Can you look into this problem, please?