2012-08-28, 05:46
Hey no prob bossanova808. Yep, consensus was a return to Eden-style release of the audio device. That's good and bad.
Good because:
- ppl running XBMC in the background can hear other sounds when XBMC idle
- reduces CPU usage for Android, Raspberry PI, embedded platforms
Bad because:
- there'll be Eden-style missing audio at the start of tracks
- there'll be more receiver switching and/or drop-outs
I think I gave the best of both worlds: to handle external players or shell launches like ROMs with WASAPI we use the new Suspend()/Resume() functions, and if you use the new <streamsilence>1</streamsilence> tag you'll still get the current AE-style continuous stream with minimal gaps between songs or on starting a song.
If you really need XBMC to drop the audio device when nothing's playing that will be the new default behaviour, albeit with the issues noted.
Glad the Catalyst update fixed that - less for me tbh that one puzzled me!
Good because:
- ppl running XBMC in the background can hear other sounds when XBMC idle
- reduces CPU usage for Android, Raspberry PI, embedded platforms
Bad because:
- there'll be Eden-style missing audio at the start of tracks
- there'll be more receiver switching and/or drop-outs
I think I gave the best of both worlds: to handle external players or shell launches like ROMs with WASAPI we use the new Suspend()/Resume() functions, and if you use the new <streamsilence>1</streamsilence> tag you'll still get the current AE-style continuous stream with minimal gaps between songs or on starting a song.
If you really need XBMC to drop the audio device when nothing's playing that will be the new default behaviour, albeit with the issues noted.
Glad the Catalyst update fixed that - less for me tbh that one puzzled me!