Greetings. I’ve been digging around for an answer to this, but haven’t found anything definitive. I hope this won’t be considered too off-topic.
If I’m forced to run Windows audio in Shared mode, does the Windows mixer (or whatever they call it in Win7) mess with the audio IF my device’s Shared mode setting matches the decoded audio? e.g., Shared mode is set to 24-bit 96000 Hz, and the decoded audio at the app level is the same.
Specifically, TIDAL’s Windows desktop app says “No output devices found” in the Streaming settings. In this PC are numerous devices:
M-Audio Delta AP 192 soundcard (S/P-DIF is default Out, and there’s also 1/2 Line Out)
Onboard Relatek Digital and Speakers
AMD HDMI audio via the video card
Since I’m sending the digital audio signal to my Audio/Video Receiver (AVR) to let it do the Digital-to-Analog Conversion, I’m using the M-Audio’s S/P-DIF out as the default Playback device (I haven’t tried the Realtek; not sure it’s worth it). TIDAL shows System Default as the device, but it isn’t selectable or configurable. So if I want to stream the new MQA “Master” stuff TIDAL now offers, I set my M-Audio to 96000 Hz and make sure it’s set to 24-bit in the Windows Sound control panel entry. Since it’s Shared mode, of course the AVR detects that when I select the input fed by the M-Audio S/P-DIF (the 96 kHz light comes on; no audio need be sent).
Ideally, because the decoded TIDAL “Master” stream is 24/96, and the Shared mode is set to the same, Windows simply passes it on to the M-Audio without any upconverting, resampling, etc., and the M-Audio sends it to the AVR for the DAC operation. But it’s Windows, so I’m extremely suspicious that the Windows audio stack is messing with it at some point.
Any thoughts and clarification would be greatly appreciated.
Thanks for the quick reply. I’d read about the 32-bit float improvement over the old audio engine, but not that it always happened in Shared mode (e.g., in my scenario). Seems an odd thing/waste of resources when there’s only one “stream” playing and it matches the Shared mode setting. Perhaps it has to do with “being ready” for any additional streams thrown into the mix; i.e., “nothing gets into the mix that isn’t 32-bit, so we’ll upconvert everything before throwing it in there,” as opposed to having to adjust (for example) my already playing stream when a new, lower quality stream is added. That’s just a guess, obviously. Curious as to their logic is all.
Oops. Yep Audacity 2.1.2. Fantastic software, and a great resource both specific and general in the documentation.
My guess is that on modern processors, floating point calculations are more efficient than integer, and with 32 or 64 bit processing, the “extra” 8 bits is a non-issue, so it makes sense to handle the audio as 32-bit float regardless of the source format.
As to what the Win7, et al., audio engine is doing in WASAPI Shared mode, I found this:
“An application that uses WASAPI to manage shared-mode streams can rely on the audio engine to perform only limited format conversions. The audio engine can convert between a standard PCM sample size used by the application and the floating-point samples that the engine uses for its internal processing. However, the format for an application stream typically must have the same number of channels and the same sample rate as the stream format used by the device.”
(emphasis mine)
and again strongly hints at it in the “2 channel, 16 bit, 44100 Hz (CD Quality)” example.
While that’s not an explicit answer to my question, it does seem to suggest that WASAPI Shared mode does upconvert/resample the format(http://manual.audacityteam.org/man/glossary.html#resampling) as a matter of course, and probably for the reason Steve noted.