EarTrumpet fails to switch iTunes to another device

[DanteDT]

Summary

As 4th screenshot illustrates, this issue is only for iTunes. If headphones are plugged in after iTunes starts, EarTrumpet cannot switch audio to the new device (headphones) but seems to think that it has. Works fine for other players, ex. Firefox:

Steps to reproduce

Start iTunes and another audio player like Firefox without headphones plugged in, so audio plays out system speakers. Plug in headphones. Use EarTrumpet as shown above to switch iTunes audio to headphones. Use EarTrumpet as shown above to switch Firefox audio to headphones.

It works for Firefox, not for iTunes

EarTrumpet version

2.2.0.0.

Windows version

21H2 build 22000.675

Additional information

No response

[riverar]

Hey @DanteDT thanks for the report.

I added windows-bug as this is broken in Windows too. (Figure 1 above.) I also added third-party-bug as iTunes is frankly a bad app (likely purposeful).

Don't think you'll see a fix for this, I'm afraid. But two things:

• I strongly recommend you file an issue in Feedback Hub under Devices and Drivers > Audio and sound
• I will start an incompatible-app list and link in the README

[DanteDT]

* I will start an incompatible-app list and link in the README

Indeed, a bad app, and without a doubt purposeful! So turns the world with internecine tech subversions : )

I've reported the windows bug as you suggested - Feedback Hub.

[dobesv]

I've noticed that if an app has the ability to change the output device in its own settings, EarTrumpet might not be able to control that. EarTrumpet only redirects apps that are trying to use the default output device.

[neube3]

I've noticed that if an app has the ability to change the output device in its own settings, EarTrumpet might not be able to control that. EarTrumpet only redirects apps that are trying to use the default output device.

Thank you @dobesv, you ended my week-long quest for a fix!

For future reference for others: MS Teams has two audio outputs and only one of them would truly switch in EarTrumpet (the general sounds; the actual calls would claim they've switched, but were under the wrong device anyway).

After a windows update, MS Teams decided it will silently (pun kind of intended) reset sound output settings.

I would then be able to switch one of MS Teams audio outputs to another device, both outputs would claim to be switched/moved, but the "call/conference" one (in an iron grip of MS Teams internal control) would stay right where it was.

As you see on the fragment of a screenshot below (modified for unblurring the names of output devices), the second MS Teams output is in the headphones device's section (as it reverted to this setting in MS Teams itself without a notice), but after a right-click on it, it has a tick/check mark next to "CABLE Input (VB-Audio Virtual Cable)", suggesting it has switched.

I think the fact that EarTrumpet - and Windows itself, since both MS Teams outputs in the Windows' settings page for changing output devices had shown CABLE Input! - shows different device could be considered a bug, since it tries to switch, fail to do so (because of external reasons, like the program controlling the outputs itself with an iron hand) and reports back wrong information about the switch. I understand there might not be a method to check for it (maybe the program itself returns a "successfully switched output device" message), but if there is such a method and it's not implemented, it would be a nice-to-have. An error message ("Could not switch XYZ app's audio output device; have you checked if the application itself controls it?") would be preferable to wrong info.

[dobesv]

Another approach might be to update the messaging / docs /UI for EarTrumpet to just specify that it allows you to customize the outputs for apps that don't support this themselves

[riverar]

Hi there. I'm cleaning up the issues list. There's no work to be completed here so am closing this issue for now. (Will visit adding a FAQ or similar about this issue though as you suggested.) Feel free to keep the discussion going. Thanks!

Edit: I'm going to tie this to master issue #1307.