[zareliman]

Hello

I recently discovered that WASAPI supposedly can playback bitperfect streams of PCM and DSD. I preferred to stick to ASIO but it's buggy on every DAC/Soundcard I've ever tried, producing noise when putting load on the CPU and having problems at certain sampling rates so I decided to use WASAPI whenever it was possible.
 
I already was aware that on WASAPI exclusive (event or push) PCM streams:
 
1.- Foobar still has full volume control and RG even on WASAPI that's supposed to be Bitperfect (it is not bitperfect unless you set everything at 0db AFAIK).
 
2.- Windows 10 has partial volume control, the mixer-per-app stops working but the main stream still has volume control (just like foobar it's -X db to 0db).
 
That doesn't surprise me or concern me much since both programs are performing fp-higher-than-bit-depth gain algorithms so they *shouldn't* compromise quality, still out of OCD I prefer to send bitperfect stuff to my dac so I was just assuming bitperfect stream was achieved with foobar and windows at full gain (0db).

Now this is the real puzzler for me:
 
Windows 10 can still control volume (reduce gain) when either Jriver or foobar are streaming DoP and it works properly.
 
DSD support doesn't exist in vanilla foobar or windows 10. Foobar can decode dsd through a foo_input_sacd and produce bitperfect DoP (DSD Native/Raw was dropped in 0.9.7). DoP is DSD over PCM which is NOT a wave conversion, it's just a different way to pack DSD so that drivers/controllers that usually handle PCM packets can send/receive DSD through the same channels. This is why DoP produces noise in DAC's that only support PCM, because they try to read it as a PCM wave when it's still DSD.
 
When DSD playback over DoP is enabled on foobar, the volume control is obviously bypassed (and RG) because the internal foobar's algorithm for PCM, it's incompatible with DSD (DSD is inherently incompatible with any PCM processing and vice versa). It makes absolutely no sense that windows can take that DoP stream and apply it's regular PCM algorithm.
Please help me understand what's going on here.
 
TLR DSD over PCM WASAPI playback volume control should not work in Windows (explained), it is working properly (no noise or artifacts).

EDIT: Confirmed, Native DSD (1bit raw stream) through ASIO is still being affected by the global windows volume control. This is absolutely bizarre. The DAC's internal digital volume control is being unaffected by the windows setting, both are totally independent.

 

[Roseval]

I don’t think WASAP or ASIO are “bit perfect”.
All they do is passing the output of a media player unaltered straight to an audio device.
This is in essence about low latency.
This is obtained by bypassing the Win audio stack.
Using this protocols doesn’t say anything about what happens DSP wise upstream or downstream.
 
Might it be that you are using a USB DAC?
In that case the audio is still unaltered (DoP) but Win send USB control commands to the DAC like volume control.

 

[zareliman]

They are bitperfect, there's even tests for that.

Sent from my LG-D802 using Tapatalk

 

[zareliman]

Sorry, they can achieve bitperfect, it's been tested. It's not only about latency but about bypassing the windows filters.

The USB DAC has its own internal volume, I already checked and the windows setting is not messing with the DAC volume.

Sent from my LG-D802 using Tapatalk

 

[Roseval]

Bit perfect is in general defined as no changes; number of channels, samples and sample rate are not changed.
This is not a property of the protocol.
 
If your media player applies volume control, re-sampling, etc the output of the media player will be send to the audio device using protocols like ASIO / WASAPI unaltered.
These protocols don’t change anything but at the same time are by definition unable to influence anything up or down stream.
Hence these protocols are not “bit perfect” as they are not in control samples or sample rate.
They are transparent as nothing is altered by them, not to be mistaken for “bit perfect”

 

[zareliman]

Bitperfect AFAIK just means the information sent is bit by bit identical to the source. Maybe we differ in our definitions but this is what I meant by bit perfect stream (the data is sent raw as is to the DAC for it to decode). Transparency to my understanding is used when you have processed the digital information in some way and the resulting waveform cannot be told from the original. For example 256kbps AAC may be transparent to the WAV source for most people, even though the 256kbps AAC does not produce the same PCM stream produced by the original WAV (it's not transparent by your definition). In this analogy a FLAC file is absolutely bitperfect and transparent, even though is not the SAME file as the WAV, it decodes as the exact same PCM data bit by bit.

Sent from my LG-D802 using Tapatalk

 

[sbgk]

https://blogs.msdn.microsoft.com/matthew_van_eerde/2014/11/20/walking-the-idevicetopology-tree-to-see-audio-driver-settings/

 

[zareliman]

  https://blogs.msdn.microsoft.com/matthew_van_eerde/2014/11/20/walking-the-idevicetopology-tree-to-see-audio-driver-settings/

I got this output, not completely sure about this but should it mean the Driver/DAC has another internal digital volume control entirely for windows to control it ?
And since this digital control is actually inside the DAC it also can process the DSD streams ?
 
The knob Gain control in the dac goes from -49db to 0db in 1db steps.
The windows Gain control output says -63 to 0 in steps of 0.5db.

eRender endpoint
Name: Speakers (MUSILAND Monitor 02 US mark2 Audio Device)
Endpoint ID: {0.0.0.00000000}.{55afa541-560c-4e47-8e2a-2b102fd723b1}
  0x10000:
  {2}.\\?\muaudio#vid_1fc9&pid_6235#8&8e7630e&0#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\topology
    0x10001: Speakers
      0x20001: Master Mute
      Mute node: NOT MUTED
        0x20000: Speakers
        Channel 0 volume, -63 dB to 0 dB in steps of 0.5 dB: 0 dB
        Channel 1 volume, -63 dB to 0 dB in steps of 0.5 dB: 0 dB
          0x10000:
          {2}.\\?\muaudio#vid_1fc9&pid_6235#8&8e7630e&0#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wave
            0x10001:
              0x20000: DAC
                0x10000:

 

[sbgk]

Don't know enough to say for definite, but could be the dacs usb convertor has a digital volume control, have seen this with xmos devices. Would explain the asio issue as well, perhaps.

 

[zareliman]

  Don't know enough to say for definite, but could be the dacs usb convertor has a digital volume control, have seen this with xmos devices. Would explain the asio issue as well, perhaps.

I recently solved it.
Through another tool I discovered (made by Matthew) windows is controlling the endpoint volume that is actually a hardware volume in the DAC.
 

There is a hardware volume control
There is a hardware mute
ERROR: IMMDeviceEnumerator::GetDefaultAudioEndpoint failed: hr = 0x80070490

 
It seems that the DAC has a dual hardware volume/gain implementation to comply with some drivers standards probably.

 

[sbgk]

don't think it's to comply with driver standard, think it's just something the chips offer so manufacturers use that functionality.

 

[Roseval]

  don't think it's to comply with driver standard, think it's just something the chips offer so manufacturers use that functionality.

No, control commands like Volume control and Mute are part of the USB UAC1/2 standard
https://developer.apple.com/library/content/technotes/tn2274/_index.html#//apple_ref/doc/uid/DTS40010116-CH1-TNTAG5