• 1
  • 3
  • 4
  • 5
  • 6(current)
  • 7
Android Audio Passthrough gone after Shield Sleep.
#76
(2023-07-20, 03:37)b1ggles Wrote: It's not just the Shield, my Fire TV Cube suffers from it too so would guess any Android device that can use passthrough would suffer in the same way. In fact, my Windows version does a similar thing each time the OS decided to reboot in the middle of the night as part of an update. In this case it would lose the WASAPI settings and revert back to DIRECTSOUND losing all the HD-Audio settings.

im on a fire tv cube gen 3, running a master version from late june without issues

im in the middle of testing another android device now running android 11 with kodi master from july 16 so i'll pay attention if this issue arises but as yet it hasn't

maybe try a nightly master alpha for awhile and see how it goes, as long as you maintain your backups there's no loss
Reply
#77
(2023-07-18, 01:43)bonggo Wrote: Also, I installed cron addon. I set a 3am "quit" cron which overnight ensure that next day Kodi starts fresh and passthrough settings are there. As b1ggles pointed out, if I exit Kodi, all is good, its just that I forget sometimes to do that Smile

You could use keymap editor to set 'back' when on the home screen to quit Kodi, or do it directly in advancedsettings.xml, like I mentioned previously. Then add a press of 'back' to the exit activity commands on your Harmony.
Reply
#78
Still an issue with latest omega beta on (at least) nvidia shield. Could someone acknowledge this, please? Debug logs have been posted.

Thanks!
Reply
#79
(2023-09-27, 21:18)pannal Wrote: Still an issue with latest omega beta on (at least) nvidia shield. Could someone acknowledge this, please? Debug logs have been posted.

Thanks!

Will never be fixed, it's just how HDMI handshaking works. You need to quit Kodi each time you finish watching so next time it refreshes the audio capabilities. You get the same thing with Windows if the audio output device isn't on when the PC restarts.
Reply
#80
(2023-09-27, 21:18)pannal Wrote: Still an issue with latest omega beta on (at least) nvidia shield. Could someone acknowledge this, please? Debug logs have been posted.

Thanks!

I have the same issue. I was thinking tho, you can change the nvidia shield screen saver to 15 min instead of default 5(?) and maybe that will fix the issue?
Or will the Kodi screen saver also trigger the issue? You can just use the "dimm" feature in kodi maybe?
Reply
#81
(2023-09-29, 15:15)Ejziponken Wrote:
(2023-09-27, 21:18)pannal Wrote: Still an issue with latest omega beta on (at least) nvidia shield. Could someone acknowledge this, please? Debug logs have been posted.

Thanks!

I have the same issue. I was thinking tho, you can change the nvidia shield screen saver to 15 min instead of default 5(?) and maybe that will fix the issue?
Or will the Kodi screen saver also trigger the issue? You can just use the "dimm" feature in kodi maybe?

Screen saver and sleep are totally different things, if there's a don't sleep ever mode it should help but is it really that much effort to quit Kodi when done?
Reply
#82
Hmm. Shouldn't Kodi check audio capabilities every time playback is started? One might plug in headphones for example. Or switch audio between AVR and TV speakers.

I have this same issue. Indeed it is too difficult to exit Kodi after watching. We have six family members, some very young.. quite often I find Kodi already playing some Peppa Pig when turning TV on.

As a bonus, my Kodi seems to forget how to switch framerate if the audio settings are not correct.
Reply
#83
But Netflix is able to get back DD+ for example. Not sure how they do that.
Also the passthrough I remember in an older version of Kodi (maybe Kodi 18 or the very first 19) passthrough was working well (i.e. correctly detected) even after the device was put to sleep.

For reference : I have the same issue on my MiBox 3 (Android TV 9), Kodi 20.2.
Reply
#84
Same issue on Fire TV Stick 4K 2nd gen. The Stick is connected to Denon AVC-X4800H, which is connected to LG C1. The problem is very easy to reproduce:
  • Start Kodi (latest Omega nightly)
  • Configure Audio passthrough in Kodi settings using Kodi IEC packer.
  • Playback a video, check on AVR that the incoming signal is correct
  • Stop video playback
  • On Fire TV remote control click the gear-button and choose "Sleep" in the menu 
  • Wait a few seconds for sleep mode to activate
  • Wake up Fire TV by clicking select-button on the remote
  • Kodi should be active
  • Try to playback the same video
  • Check incoming signal on AVR. It's showing "PCM Stereo"
  • Go to Audio settings in Kodi. The previously selected "Kodi IEC packer" isn't there. It was replaced by "Android IEC packer"
  • Exit Kodi and start Kodi again
  • Go to Audio settings in Kodi. "Kodi IEC packer" is available again
  • Try video playback. It's working correctly again.
I've checked Kodi logs. When Kodi starts it lists two AUDIOTRACK devices: Kodi IEC packer and Android IEC packer. After sleep/wake-up the list of AUDIOTRACK contains only Android IEC packer.

I can compile Kodi. As a test I tried to comment out the code which is run on sleep/wake-up to avoid reinitializing of audio devices but it didn't work as I hoped. The devices are still initialised and printed to the log. I've obviously changed wrong code lines. Maybe someone from Kodi team could give me some pointers on which parts of code to change to make Kodi stop reinit of audio devices on sleep/wakeup. Just for a test, of course. I understand that this wouldn’t be the end solution. I just want to see if that would help or not.
Reply
#85
I did more testing with Fire TV Stick 4K 2nd gen connected to Denon AVC-X4800H.

I believe I found the cause, at least with my device combination. On Sleep event Kodi shuts down the audio engine. Then, during processing of Wake-Up event Kodi reinitializes audio engine. However Kodi receives the Wake-Up event before the handshake between Fire TV and AVR is completed. As a result Kodi doesn't see capabilities of AVR. That's probably also the reason why Kodi IEC packer doesn't appear in audio device list.

If audio engine would be initialised not directly on Wake-Up event but a few seconds later, that would fix the issue.

There is a simple way to test this and you don't even need a special build. The test uses Kodi's support of external players. When Kodi launches an external player it shuts down the audio engine and reinitializes it when the external playback is completed. In our test we use this feature to reinitialize audio engine at any time  - we want to do that a few seconds after wake-up.

External players are configured in Kodi using a special configuration file, as described in Kodi WiKi. I've prepared an example file - save it as playercorefactory.xml in Kodi userdata directory and restart Kodi. Now you should have a context menu item "Play using…", where you can select "Fake player". Kodi will show a message (Note: the config file refers to a non-existing app, nothing will be really started). When you click on OK Kodi will reinitialize audio engine. Passthrough should work again after that.

After knowing that we need a delay before initialising audio engine on wake-up I added a delay to the source code, just before this line.

In my tests I needed a 3 seconds delay if I put the Fire TV into sleep using Gear-button on remote (AVR and TV remained on). However I needed a much longer delay when all devices were switched off using On/Off-button on remote (as I usually do). When all devices are awaken I can navigate through Kodi menus, then, a few seconds later, the screen goes black for a fraction of second. Only after that the audio engine must be initialised. I don't know why my device combination is doing this but I have to accept this. This requires a delay of whole 10 seconds in my case.

Instead of using such long delay in the wake-up routine I tried a different approach. I just completely disabled deactivating/reactivating of audio engine on sleep/wake-up events. To do this I commented out these two lines of code: one and two. I did not encounter any issues with this approach. This has completely fixed the issue for me.

I suggest to implement a setting in Kodi to disable audio engine reinitialization after wake-up (this would also disable audio engine shutdown on sleep).

I understand the intention of the code but not all devices in real world behave as expected. If for some reason I need to reinitialize the audio engine I can restart Kodi. That's much better when having to restart Kodi every single time after sleep/wake-up as I needed before the fix.
Reply
#86
This is great news. Now we just need someone to integrate the fix into Kodi..

I have to restart Kodi several times per day. This started with my new AVR that has 4K HDMI ports so I have everything connected through it. With my previous AVR I had Shield connected directly to the TV, and this issue never happened.

I use the Shield remote to control the system. So Shield is powered first, then it wakes AVR and TV through HDMI CEC. This probably creates the situation where Kodi is already running while AVR and TV are still booting.
Reply
#87
Please fix it properly. Now that you have proven, that this is a handshake issue, e.g. device is NOT available when kodi enumerates the sink. Plug into the HDMI_PLUGGED intent and kindly ask kodi rescan the devices. That way no such setting is needed.

As you see here: https://developer.android.com/reference/...dioManager

there are several interfaces available, most promissing is the https://developer.android.com/reference/...AUDIO_PLUG here an EXTRA_STATE is issued. Hopefully this is also coming when ENCODINGS (also a part of the intent) is coming in.

That way you can compare what you already have and ask AudioEngine to rescan.

Removing the AE Suspend code is a bad idea - imagine your AVR will be off or you intend to use the TV only. Don't only think about your use-case but about the general use-case by "the entire world" ;-) ...

Also triggering a rescan could be done inside kodi with a simple python addon. AE python bindings expose suspend / resume / etc.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#88
(2023-12-03, 15:45)Zuikkis Wrote: Hmm. Shouldn't Kodi check audio capabilities every time playback is started? One might plug in headphones for example. Or switch audio between AVR and TV speakers.

I have this same issue. Indeed it is too difficult to exit Kodi after watching. We have six family members, some very young.. quite often I find Kodi already playing some Peppa Pig when turning TV on.

As a bonus, my Kodi seems to forget how to switch framerate if the audio settings are not correct.

Kodi is doing this. But it works a bit different:
- We have the enumerated capabilities
- Based on these we try to open the sink
- If that fails, we fall back to PCM only.

So - no, we don't reenumerate the sinks all the time in a polling fashion. Real-Fix as shown in my post above. We need to get the "Capability Change" from the Android OS, when this happens we rescan. In Android it's a bit more complicated cause the JNI intents need to go through the main app. In Linux World (pulseaudio, pipewire, ALSA) this is handled inside the Sink itself, example here: https://github.com/xbmc/xbmc/blob/master...E.cpp#L259

For Android: https://github.com/xbmc/xbmc/blob/master...p.cpp#L245
which has several flaws, e.g. it is currently not used on TVs, but what about TVs using their E-ARC to output sound. This m_hdmiSource dependency needs therefore changing.

^^ Here is the place I would start:
- Check that you get the intent
- Check that you get it additionally when device capabilities change
- Compare new capabilities with old capabilities that you cached
- Ask AE to rescan when something "relevant changes".

As you know we are short of Android devs and this is a lot of fiddeling.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#89
(2023-12-30, 11:09)fritsch Wrote: Removing the AE Suspend code is a bad idea - imagine your AVR will be off or you intend to use the TV only. Don't only think about your use-case but about the general use-case by "the entire world" ;-) ...

I do switch off AVR and TV. I usually press on/off button on Fire TV remote and it switches off TV and AVR and put the stick in sleep mode. Then I use the same remote button to switch on all these devices. The "fix" works perfectly. I sure didn't think about my case only; that's why I suggested a setting and not the total removal of existing code Wink

Thanks for looking into this and your suggestions.

I've tried ACTION_HDMI_AUDIO_PLUG event. It is fired only once after wake-up and immediately after ACTION_SCREEN_ON. However the handshake seems to be completed at this point already!

I've added audio engine reinitialisation on receiving ACTION_HDMI_AUDIO_PLUG. That fixed the issue! I've created a pull request.

Edit: for test APKs please see posts below in this thread.
Reply
#90
You're a hero. Thank you for actively looking into this issue.
Reply
  • 1
  • 3
  • 4
  • 5
  • 6(current)
  • 7

Logout Mark Read Team Forum Stats Members Help
Audio Passthrough gone after Shield Sleep.0