Thanks for the lesson, and yes I'm aware that there are implementations with different media players that I don't fully understand, and I'm mostly concluding from my own observations.
So a couple of questions, why does AHD app resample prior to streaming?
Well, you need to ask Amazon developers
AMHD app is made available on four major platforms (MS Windows, macOS, iOS, Android) and across several different versions. From what I can see, Amazon developers are using a unified codebase for all platforms, unlike TIDAL, Qobuz or Spotify, who have their own unique application developed for each supported platform. Obviously, it is way much easier to maintain unified codebase for a portable application but it also limits capabilities on each platform, because you are forced to use lowest common denominator, sort of. You cannot add advanced feature easily on one platform unless it is also supported on
all platforms. Now, media playback / audio stack on all those platforms is a mess -- buggy and limited functionality but also implemented differently on each platform. If I was developing portable audio playback code I would indeed try to stay away from OS-specific implementations as much as possible and code it in my own software instead. Considering bit-perfect playback was never a priority for Amazon (doubt their developers knew what it it) it is no surprise they tried the same approach.
Why analyse system capability (which is capable of streaming 24/192 in my pc). If this is the case, why not stream at the native resolution, and make use of WASAPI that MS wrote specifically to bypass it's own mixer for exactly this type of application?
Because they also need to be able to support streaming on macOS, iOS, Android (half a dozen different versions) and Fire OS (patched Android, also four or five versions in circulation).
If you are correct and the app is making a system capability assessment, then it's a pretty crap implementation, because it's not working. Every other media player I have tried on my system switches to native resolution using WASAPI event output settings.
Correction: every other
Windows media player. AMHD app actually works as designed, they simply care less about 0.001% of hardcore audiophiles who cringe when thinking about non-bitperfect streaming.
Also, when AHD is set to exclusive mode, I think I already stated I can still hear Windows notification sounds when streaming AHD, I can still play other media sounds simultaneously, that's not exclusive mode. Try the same in tidal or musicbee or J River and it won't work, so they are working in exclusive mode. I see on two different devices, one running W7 64, the other W10 64.
I don't know, I am not a Windows expert as I said. My Lenovo laptop with W10 64-bit installed on it would not play back any other sounds when Exclusive mode is checked in AMHD. Just checked and confirmed it after updating to the lates AMHD app version to be sure, no way. Even if I pause AMHD playback (in Exclusive mode) and then try playing some YouTube videos in Firefox they will just roll on in silence. Note, AMHD Exclusive mode setting does not stick, so you need to check it every time you restart playback. Pretty annoying, let's hope they will fix it soon.
I also noticed that every track was streaming to my dac (marantz HD DAC1) at 48k, (don't know bit depth, can't see that.), which just happens to be the Windows default shared output sample rate. When I changed the default shared output sample rate in the W10 sound settings, the rate shown on the dac was the same.
I assume you are referring to Settings->System->Sound->Device properties->Additional device properties->Advanced tab->Default format? This setting is effective in both exclusive and shared modes. It is just a default audio format, application can choose to use it or not. AMHD seems to query and use this setting under W10.
It seems reasonable to conclude that the actual sample rate used in the final conversion ie that I hear is that which is displayed on my DAC. Unless I manually changed the windows settings, every single track in AHD was streamed into the dac at the same rate, so wasn't actually hi res audio, and could not be bit perfect.
It is a Hi-Res audio (unless you have selected 16bit/44.1kHz as your Default Format) but it is not bit-perfect, the latter is correct.
For whatever reason, it wasn't behaving as I'd expected (on my two devices) so I wasn't prepared to continue the sub. It's not isolated, there is a whole thread somewhere dedicated to finding a way to stream the native resolution from the app, but I can't remember where it is, which prompted me to look at in more detail in the first place.
I cannot agree more, it is very frustrating, especially considering Amazon's own hardware does not support AMHD streaming in UHD and there is strong suspicion that even HD playback (which is supported on some Amazon devices) is not bit-perfect.