Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: DirectSound – S/PDIF null test issue Win 8.1 (Read 16217 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

DirectSound – S/PDIF null test issue Win 8.1

Ok, I know Windows audio driver quality has been done to death on this forum and others, but I haven’t seen any topics covering the particular behaviour I have found.

….Interested in the quality of the S/PDIF out on my HTPC and I ran a few simple loopback tests. The hypothesis being that if the recorded S/PDIF output nulls with the (phase inverted/time-aligned) original file I can be confident I am passing a bit perfect signal to my DAC (blah, blah, blah…).

Anyway, what I found led me on a wild goose chase, and I am none the wiser….

Basically, using direct sound the S/PDIF bitstream nulls perfectly with the original audio - some of the time - but there is a delta, seemingly random transient spikes!

See the summed wav here:
http://www.hydrogenaudio.org/forums/index....ost&id=7761
  (Peak amplitude is ~-44 dBFS so you may need to zoom in to see it).

Initially I was disappointed but not necessarily surprised – I thought it was simply down to timing issues/poor insulation etc. but I ran some more tests and found these artefacts are perfectly reproducible! By which I mean, if I re-record the same audio passage from the S/PDIF out multiple times I get exactly the same delta!
I tried it using different PCs, playing the audio through foobar (DS) and through wmp – it’s always the same.

I did a similar tests when I was still on Windows 8 and could swear I didn’t see this issue. I can’t make sense of it. I can only assume there is some other processing in the chain, but the nature of signal suggests it's not the usual suspects like resampling/dither.

DirectSound – S/PDIF null test issue Win 8.1

Reply #1
At about 53s you can hear fragments of the original audio. Can you try to nudge your recordings +/- one sample and see if the signal now nulls at exactly those positions where you previously had the spikes?

My current bet would be bad clock reconstruction, but I never thought it would be this bad.

DirectSound – S/PDIF null test issue Win 8.1

Reply #2
At about 53s you can hear fragments of the original audio. Can you try to nudge your recordings +/- one sample and see if the signal now nulls at exactly those positions where you previously had the spikes?

My current bet would be bad clock reconstruction, but I never thought it would be this bad.


Nudging the audio doesn't get rid of the artefacts in those portions.

My initial thoughts were the same re. the clock, but as above I tried re-recording the same segment from the s/pdif out several times and all captures were bit-for-bit identical (i.e. exactly the same spikes w.r.t the original audio) - I would expect clock slips to cause random artefacts.

DirectSound – S/PDIF null test issue Win 8.1

Reply #3
Proper SPDIF loop requires two soundcards. The transmitting one is switched to internal clock, the receiving one must be switched to the incoming recovered clock (external spdif clock).

If only one soundcard is used, there are two scenarios:

A) the card is switched to the internal clock, the recovered clock is synchronous with the card clock (as it comes from the same source), but a tick at the edge can be missed/skipped, resulting in the effect of shifted audio you describe.

B)  the card is switched to the external clock - no clock to generate spdif output in the first place, resulting in unpredictable outcome (some cards get stuck, some use a freewheeling oscillator).


DirectSound – S/PDIF null test issue Win 8.1

Reply #5
Thanks for the replies.

I am confident the setup is fine: two separate sound cards, receiver (0404 EMU) using external clock, 24 bit source files, Fs/Bitrate set correctly in Windows and DAW (24 bit / 44.1).  If there were issues here, in most cases I wouldn't expect any of the signal to null.

This could be significant... "The test signal should not be very close to 0dBFS because Windows will automatically limit the volume to prevent clipping, resulting a non bit-perfect stream"

The source, as with most CDs these days, certainly peaks close to 0 dBFS (~ -0.2 dBFS). I have noticed that some (though not all) artefacts align with 'peakier' sections of the music.  When I get a chance, I will try some lower level test tones and noise.

Is there any information about this limiter? Is there no way it can be disabled or avoided other than using a different API/driver? I have never seen it mentioned elsewhere online. Also,the post mentions MME? Presumably you're inferring this affects DirectSound as well?

DirectSound – S/PDIF null test issue Win 8.1

Reply #6
Is there any information about this limiter? Is there no way it can be disabled or avoided other than using a different API/driver? I have never seen it mentioned elsewhere online. Also,the post mentions MME? Presumably you're inferring this affects DirectSound as well?


This limiter should affect DS as well. The first time I notice this was when I played a MIDI file in foobar2000 using foobar2000's MIDI plugin. Since MIDI files are synthesized, they have no fixed volume level, they often exceed 0dBFS in playback. Depends on the SoundFonts being used and the volume/velocity setting of the MIDI files themselves, some files can peak at +5dBFS or higher, this can be observed by converting the MIDI files to float 32 wave files. If I use DS output in foobar2000 in Win7, the only way I can prevent volume limiting is changing foobar2000's replaygain preamp value to keep the volume level below 0dBFS before the audio signal reaches foobar2000's volume control (which is manipulated by Windows when using DS output). However it is too inconvenient because I need to switch the preamp value to normal again when I play other files. A workaround is using ASIO because when using ASIO, foobar2000's volume control can deal with volume level above 0dBFS without limiting or clipping therefore I can simply use foobar2000's own volume control to adjust the volume level of all kinds of audio files.

DirectSound – S/PDIF null test issue Win 8.1

Reply #7
Interesting stuff.

I spotted this has been discussed in the jplay thread - someone referenced: http://blogs.msdn.com/b/matthew_van_eerde/...le-signals.aspx

So any signal using WASAPI, whether directly, or encapsulated DS/MME will be processed though the limiter(?), which kicks in at -0.2 dBFS - that's an awful lot of modern popular music.

I will definitely look to try some lower level test signals to verify the theory. At the risk of confusing the discussion - one thing I don't understand is that when I tried the foobar WASAPI driver on the same audio material, it did not behave the same. Whilst there were no spikes compared with the original file, there was constant noise around -114 dBFS (suggesting some low level dither perhaps). Admittedly, I only looked at this briefly as I turned my focus to the DS issues, but this would be another non-bit perfect situation (albeit one of no subjective consequence).

Anyway, assuming it is the limiter affecting the DS situation, I think what these tests show is that any affected signal is subjected to non-negligible processing. Not wanting to conflict with forum rules, but it was suspecting something didn't sound right to prompt me to look into this, so I am not convinced it's subjectively unimportant. Further work needed, but this would contradict the recent shift in consensus (at least from what I gather) that DS is fine for bit perfect playback when SRC is avoided and a bit depth of 24 used...

EDIT: Looks as though this has been discussed before (http://www.hydrogenaudio.org/forums/index.php?showtopic=89281&st=25) although my previous searches did not uncover it, so apologies if this is going over old ground.

DirectSound – S/PDIF null test issue Win 8.1

Reply #8
So any signal using WASAPI, whether directly, or encapsulated DS/MME will be processed though the limiter(?), which kicks in at -0.2 dBFS - that's an awful lot of modern popular music.


I think that MS probably had valid technical reasons for doing something like this (and it's something that needed to be explicitly programed into the mixer, instead of the limiting being a bug or other kind of limitation). In any case, while the limiter interferes with such kinds of signal testing at ? -0,1313 dB FS it's not audible.

DirectSound – S/PDIF null test issue Win 8.1

Reply #9
I guess only ms know the answer to that. Perhaps it's to avoid clipping when mixing more than one signal or to avoid ever sending 0 dBFS to the dac. From my point of view i wish they would just leave it alone.

My understanding is that ds is converted to 32 bit float. Presumably the limiter operates on the fp signal? I guess at least that minimises quantisation noise from processing.

However, i not convinced the affect is negligible. Although i accept it's not conclusive evidence, the residual signal is fairly pronounced. Furthermore, the material in this case has a reasonable dynamic range, but has been (quite rightly) mastered so that it peaks close to full scale. Other music could be far worse resulting in frequent hard limiting adding plenty of odd order harmonic distortion (as if we need more than that already caused by mastering limiters!)

DirectSound – S/PDIF null test issue Win 8.1

Reply #10
I guess only ms know the answer to that. Perhaps it's to avoid clipping when mixing more than one signal or to avoid ever sending 0 dBFS to the dac. From my point of view i wish they would just leave it alone.

My understanding is that ds is converted to 32 bit float. Presumably the limiter operates on the fp signal? I guess at least that minimises quantisation noise from processing.

However, i not convinced the affect is negligible. Although i accept it's not conclusive evidence, the residual signal is fairly pronounced. Furthermore, the material in this case has a reasonable dynamic range, but has been (quite rightly) mastered so that it peaks close to full scale. Other music could be far worse resulting in frequent hard limiting adding plenty of odd order harmonic distortion (as if we need more than that already caused by mastering limiters!)



Well, if the limiter remains the same as Vista, the limiter is going to pull down the level when it gets near max, and keep the level down as long as there are occasional hits within a range of the current presumed maximum.

The limiter used to work on the floating point signal.

Unless something has changed or gone wrong, you should see no harmonic distortion, it is not a clip, rather it is a fast limiter with a very long (infinite as long as sound keeps coming in near the previous absolute value maximum). So the gain is reduced and held down for a long time, or so I believe from older experience.
-----
J. D. (jj) Johnston

DirectSound – S/PDIF null test issue Win 8.1

Reply #11
Strictly speaking, i'd say thats AGC rather than limiting.

Will do some more analysis when i get the chance.



DirectSound – S/PDIF null test issue Win 8.1

Reply #14
I uploaded an MIDI example here
http://www.hydrogenaudio.org/forums/index....ost&id=7762

original: directly converted by foobar2000's file converter, 32-bit float
DS-9dB: played with DS at -9dB using foobar2000's volume control then re-recorded, 24-bit int
ASIO-9dB: played with ASIO at -9dB using foobar2000's volume control then re-recorded 24-bit int

Applications require real time mixing/DSP (games, interactive web contents etc) can be heavily affected by this limiter issue, especially if such applications have no dedicated internal volume controls.


DirectSound – S/PDIF null test issue Win 8.1

Reply #16
Just hope some MS experts can provide a workaround or a hotfix just like the resampler issue in win7 (KB2653312)
for directshow compatible media players like MPC-HC, ffdshow has an internal preamp to tweak the volume before sending to the outputs.
Really missed foobar2000 0.8.3 because its volume control is simply a DSP component which cannot be hijacked by Windows mixer.

DirectSound – S/PDIF null test issue Win 8.1

Reply #17
MS probably considers this a feature rather than a bug, though presenting the user with a choice would be an even better feature.

EDIT: I imagine it's been tested a thousand times already (EDIT #2: maybe not, I was thinking Windows 7, not 8.1), but has anyone participating in this discussion tried WASAPI in exclusive mode?

DirectSound – S/PDIF null test issue Win 8.1

Reply #18
I'm no expert in this by any means, and this is a little vague, but I think since both the event and push modes of the WASAPI foobar2000 component are exclusive, then the WASAPI component should avoid MS's limiting features.

DirectSound – S/PDIF null test issue Win 8.1

Reply #19
I am extremely unwilling to use WASAPI exclusive mode as it will mute other audio sources. My soundcard is multiclient ASIO compatible therefore I can listen to other sources when running ASIO applications. However, not all applications support special modes/APIs therefore a global solution can only be applied at OS level, sigh.

DirectSound – S/PDIF null test issue Win 8.1

Reply #20
I will definitely look to try some lower level test signals to verify the theory.
A quick and easy test would be to align the original and difference signal in a daw and check if the difference signal corresponds to the peaks in the original.

DirectSound – S/PDIF null test issue Win 8.1

Reply #21
I am extremely unwilling to use WASAPI exclusive mode as it will mute other audio sources. My soundcard is multiclient ASIO compatible therefore I can listen to other sources when running ASIO applications.


Haha. I have precisely the opposite reason for choosing ASIO over WASAPI: with WASAPI it does much more often happen that I get system sounds into my audio. Don't know why.

DirectSound – S/PDIF null test issue Win 8.1

Reply #22
I will definitely look to try some lower level test signals to verify the theory.
A quick and easy test would be to align the original and difference signal in a daw and check if the difference signal corresponds to the peaks in the original.


Indeed. This was the whole premise of starting this thread.   


DirectSound – S/PDIF null test issue Win 8.1

Reply #24
Are the spikes something that is associated particularly with  the the SPDIF interface is or  are there artefacts on the HTPC analogue audio out, if it has one.