SPDIF data capture... Bit (a lot) imperfect.... I need your brains...

Jan 19, 2011
25
0
0
UK
#1
Hi all, I have a decent media PC, win7 RME 9652 sound card, and after a lot of advice from folk I use j river media player. People advise using wasapi event driver, but on checking asio, kernel streaming and wasapi, I found asio a bit soft, wasapi a bit bright and ks is just right.

I wondered about if there were measurable differences in the spdif data. Initially tried to capture to a creative x-fi ti on same machine, but lot of audible glitches. Then went into a lexicon omega capturing at 44/16 ( as per the source file). Tried analysis using fourierrocks, but a lot software problems. Then used another program to write out the wav files as text files. Moved to excel, and lined up the files.

It is by no means bit identical! One of the samples (the 1st one using asio) has lots of visible differences, but the other three (asio(control), ks, wasapi) all visibly overlay, but at the bit level there are difference.

What are the differences... It looks like the data is time shifted slightly. I could understand this if the omega resampled the data, but I thought that the digital transfer your simple sample the bit as they are, so with the odd error here and there some noise, but not time shifted slightly (by the way, i'm talking about less than 1/44k sec shift).

Anyone got ideas... I can upload the data to dropbox so others can look...

Cheers,
 
Last edited:
Apr 3, 2010
16,022
0
0
Seattle, WA
#4
Some of that is easily explainable. In Windows Vista and 7, the operating system (Kernel) has a brand new audio pipeline. It converts all audio samples to floating point from integer values. It then performs mixing of sound from all applications trying to play something and optional sample rate conversions based on what you have set in the Sound control panel (plus a bunch of other signal processing such as bass management which is off by default). Once the final stream is available, it then needs to be converted to integer for the DAC to accept. Since we are going from a higher resolution floating point internal representation to fixed point PCM samples, dither must be used or we introduce distortion. So indeed, the kernel streaming pipeline will dither on the way out to the DAC. So if you captured the digital samples, you would indeed see that the low order bit has been changed for dither alone. If you didn't turn off resampling, you would see all the values changed. Ditto if you didn't set the volume control to 100%.
 
Jan 19, 2011
25
0
0
UK
#5
Amirm, thanks for helping. i) I know about setting the vol to unity, so this is done at all points. All system sounds are off, and default sound device is the HDMI except J River, which is going to the RME Hammerfall soundcard. The gains are 0dB on the RME Soundcard. The way it's set the up there should not be any devices trying to pump data in to the RME Soundard. ii) If you are right (and I am guessing you are), that even when the soundcard is used exclusively by J River, that still it's converted to floating point, and then converted to integer, with dithering, this is why the lsb is jumping around in the silence.

If there is no resampling (which there wasn't), and the soundcard is exclusive, bass management off etc, gain's at OdB will you still go to foating point in Kernel Streaming mode, and is this also true in ASIO and WASAPI... I'm trying to understand why I hear slight differences between these modes.
 
Apr 3, 2010
16,022
0
0
Seattle, WA
#6
All correct. The audio pipeline doesn't know in advance if you are or not going to have the sound mixed or processed so it always converts to float on the way in, and back to integer on the way out, causing the LSB to toggle randomly.
 
Jan 19, 2011
25
0
0
UK
#7
Dither Damage !

All correct. The audio pipeline doesn't know in advance if you are or not going to have the sound mixed or processed so it always converts to float on the way in, and back to integer on the way out, causing the LSB to toggle randomly.
Amir, Following of from my post above, and your comments/insight...I wonder if I could discuss a recent finding and see if it ties in with what you've indicated already. But before I go into this, I noticed I had deleted the files in dropbox, so I have recreated the original files (or close to), for those who are interested is the dither damage done.

https://dl.dropbox.com/u/2078309/Audio/Reformat1.ods
https://dl.dropbox.com/u/2078309/Audio/Summary.odp

To the Point:

Recently I decided to have another go at SACD/DVD-A due learning about HDMI audio de-embedders. So I got an Oppo DV-981HD, and selected the Aten VC880 de-embedder. The VC880 was my choice due to Toslink & SPDIF outputs. So now I can get SACD at 88KHz into my DAC (and probably up to full 192KHz material from the VC880, but this is not tested as yet).

The sound is good. Very, very good in fact. And I am confident all's ok with the data in transportation from CD to my DAC.

What I was quite surprised about was, when I played a standard CD through the Oppo --> Aten VC880 --> Chord QDB76 DAC. Compared to my Media PC... The sound from the CD was much smoother, clearer, and altogether nicer.

Having not listened to a hard format disc for some years and battling away with my media PC, getting it fanless, really good soundcard (RME9652), optimizing OS and driver choice (Win 7 64bit/ASIO) I has been figuring I was getting CD quality out... [After all this effort and money with my Media PC, I think we can discount the placebo effect :) Please bear with me, as I am coming to the point]

After listening back and forth to flac files I made from the original CD's vs. the CD's themselves via the Oppo route, (i.e. both digital sources are going into the same DAC and then onwards via same path to speakers), I was able to characterise real audible differences.. A graininess in the treble, a kind on noisy myst, and a grittiness around the edges of vocals... Well this is my best attempt to describe this. There may be a slight reduction of base depth, but this could be a perception effect caused by the apparent brightness increase around the upper frequencies.

I was reminded of the data I collected and shared in this post above, and re-checked what you said about Windows always dithering... So it's clear from my observations and your comments that we can never get bit perfect from the PC as the Win Audio system goes to floating point and then dithers back to integer.

Looking into the Dither subject, there is quite some art to ensure data is dithered away from the regions of hearing where the ear is most sensitive (http://www.digido.com/dither.html). Which also gets me wondering if Microsoflt have paid such attention to their dithering, or just simply randomized the LSB.

Anyway, I believe what's wrong with the audio from my PC is the dither applied, which necessarily means it's an impossibility to get bit perfect data from a CD rip. But more importantly at the 44KHz/16bit level, it's very audible effect (I think maybe 5dB noise?)

I then turned my thought process to upsampling/oversampling. I am using J River Media Player, which allow e.g. 88 & 96 KHz sampling. So trying this I find that 88kHz sounds better that 96kHz with original 44KHz material. My guess is that 88 is an interpolation whereas 96 would be an extrapolation. I expect unless the algorithms are really good, the interpolation is a safer bet.

Comparing CD's with the Media PC oversampling 44 --> 88kHz and playing flac's made from those very same CD's, I am now getting just about identical audio characteristics to the native CD.

My theory/expectation is: that the oversampling is taking place in the floating point domain (at 32bit I suppose), and then interpolated to give the intermediate data point (in the floating point), then reconverted to integer, and then dithered. This to my mind, and assuming dither is random, will result in an effective halving of the noise generated by the dither.

It is this which I would very much appreciate your thoughts on. Do you think this is right?
 
Apr 3, 2010
16,022
0
0
Seattle, WA
#8
Good to see you again. I have not looked at your download files. SO a few points:

1. Only the Windows standard audio pipeline performs the conversion to float and hence dither. If you use ASIO or WASAPI this is avoided altogether and you should get bit exact samples.

2. Conversion of 44.1 to 88.2 or 96 both involve the same exact process of interpolation. It just turns out that 88.2 can be done with higher accuracy since it is an even multiple of 44.1. Whether that matters is another debate :).

3. On your comparison to CD, unless I read it wrong, you didn't have the same path as the CD player. I suggest getting an async USB to S/PDIF converter and using that to drive the same DAC and compare. An internal sound card is a different animal and you may be hearing that difference.

4. If you are staying with Windows pipeline, did you check the sound control panel? By default it is set to 48 Khz so it is upsampling all of your CDs to that rate regardless of what JRiver is feeding it! In my experience setting that to 44.1 makes a good improvement.
 
Jan 19, 2011
25
0
0
UK
#9
Thanks for the quick response. I am using the same DAC for conversion. It's only digital sources which differ. So what I am hearing is not related to eg the internal CD player DAC.

Hmmm. I must admit that I interpreted that windows always went to FP. And this was the clear explanation for the LSB toggling you mentioned above in the files I shared... These were from WASAPI and ASIO outputs via an RME soundcard. So if it's not being dithered coming from FP, then there is still an open question about why the output differed so much in the files I shared previously.

I take the point about interpolation being the same. I suppose at 88kHz, the proportion of original data is greater (dither or whatever notwithstanding).

I will check the windows control panel, but I thought this was not such an issues as the audio path should be in exclusive mode? J River has a blue window and pop-up telling me that the output is bit perfect (44 kHz), even if the control panel has eg 48kHz/24bit. So that would imply that J River has exclusive control.

Take a look at what you concluded earlier in the post re ASIO/WASAPI path still having dither applied and going via FP.

Cheers,
Alan
 
Jan 19, 2011
25
0
0
UK
#10
Hi Amir, after much searching the only thing I can find which says that wasapi exclusive avoids the FP step is http://thewelltemperedcomputer.com/KB/WASAPI.htm and the group thread where this info is derived. But it does indeed look like a reliable source of info.... So I am still in the dark....

Maybe my original data collection was in error at the sampling end, rather than what was coming out of my pc spdif? But this was all driven by the fact I was hearing differences between wasapi and asio, and I still do, with asio sounding slightly better...

And my recent getting back in touch, because the oppo sacd/cd --> hdmi de-embedder --> Dac is certainly better than my media PC. How can this be is wasapi and asio are giving me bit perfect ?

Ps I have double checked the exclusive mod setting, and also for good measure made sure the shared mode rate is 44/16. Plus the default audio device is another sound card (the motherboard's hdmi actually).

Your thoughts appreciated. Thanks, Alan
 
Jan 19, 2011
25
0
0
UK
#12
Very interesting reading Vincent. It's reinvigorated me to try and objectively measure the differences i hear between asio and wasapi on my system. I could have done with the Diffmaker tool when I was doing the analysis before, espesh the time alignment feature...the files are too big to mess around in excel, for sure.

As an asid, most posts say wasapi is preferable, but Cambridge Audio take a different view: http://www.cambridgeaudio.com/assets/documents/AudiophileguidetobitperfectUSBAudio_ENG.pdf
...but I have not found and hardcore information as yet.

Thanks for your help.

Alan
 

Vincent Kars

WBF Technical Expert: Computer Audio
Jul 1, 2010
860
0
0
#13
I’m afraid the Cambridge information is a bit inaccurate.

They say that WASAPI output is limited to 24/96.
This is not a limitation of WASAPI but because Win only supports USB Audio class 1 and not UAC2. UAC1 is limited to 24/96 because it is tied to USB full speed.
http://thewelltemperedcomputer.com/KB/USB.html

They also claim that ASIO is superior to WASAPI because ASIO bypasses the Kernel Mixer.
First the Kernel Mixer is XP and XP doesn’t support WASAPI, you need Vista/Win7 for WASAPI.
Like ASIO WASAPI in exclusive mode bypasses the Win mixer.
Both are bit transparent protocols.

The core of the problem is simple.
PCM audio is sample + time step.
If you want to have a perfect reconstruction of the original signal you need both bit perfect and time step perfect conversion.

Bit perfect is easy, tons of guides on how to configure your PC for bit perfect output.
Perfect time step doesn’t exist, no clock is perfect, no clock delivers cycles of exactly the same length.
Obvious bit perfect is a matter of software, if it doesn’t alter the bits and nothing horrid is going on electrically the right bits will be delivered to the DAC.

Timing is a matter of hardware, the right quality clock with the right stable PSU, etc.

Then it becomes dark. Is it possible that software interferes with hardware?
Suppose you have 2 drivers e.g. ASIO and WASAPI.
They are both programmed different, use different buffer sizes, have different requirements on system resources, etc.
Everything a PC does is by design something electrical. Anything electrical might produce EMI, RFI, ripples on the power rail, etc.
If there are differences in electrical “patterns” using this 2 drivers,
If these differences somehow translate in different amount of sample rate jitter
If this amount of jitter is high enough to be audible
Then we can say that there is some kind of software induced jitter.

But it is if,if, if and the present nobody has been able to backup this hypothesis with proper measurements.

I’m inclined to say:
If your system in bit perfect then using ASIO or WASAPI must yield identical result when recording the digital out. If not, either your null test has been done wrong or your configuration is not right.

When recording the analog out with an AD you have a real problem.
As it is probably totally impossible to have each recording to start at exactly the same moment, as there will be always be some clock drift, etc. even when you change nothing at all, the recordings will be different bitwise.

So if you make 10 recordings without changing anything they all will be different bitwise.
Maybe AudioDiffmaker could compensate a bit but I’m afraid anybody going this way (and this is the way if you also want to measure the impact of jitter) will be in deep sheet.

http://www.vertexaq.com/component/docman/doc_download/21-ka-paper-feb-11?Itemid
 
Jan 19, 2011
25
0
0
UK
#14
1) Thanks for clarification of the Cambridge Audio document. It looked like an outlier to me.

2) I am/was measuring only the digital signal, using asio and wasapi in exclusive. I observed lsb movement, as well as time alignment. I was able to time align quite well in excel.

3) I understand what you are saying about clock performance and jitter in the sources, but my DAC is supposed to eliminate these variations, as it has a large buffer, strips out the incoming spdif clock and applies it's own high quality clock http://www.chordelectronics.co.uk/specs/QDB76.pdf

4) I am using win7. 64bit. Clean system. Rme 9652 hammerfall pro soundcard. I was measuring with a lexicon omega breakout box into my laptop. I assume but I don't know, that the lexicon does not dither the digital input ??

I am going to take another look at the wav files i made earlier using audio Diffmaker, then re-do the experiments. I will make sure. I sync the clocks on the soundcard writing with the card reading , so there should not be any time drift.

Thanks for your help and links
 

Vincent Kars

WBF Technical Expert: Computer Audio
Jul 1, 2010
860
0
0
#15
If you are recording digital out from the RME into digital Lexicon, jitter is a non-issue.
This is pretty much equal to transferring a file from one HD to another.
Only and only if the bits are converted to analog, jitter is an issue.

Your best bet is probably
A file, call it WAV1
Play and record it digital, call it WAV2

If your system is bit perfect ,after a time align WAV1 and WAV2 must be bit identical.

ASIO/WASAPI (exclusive mode) are bit transparent protocols, they don’t alter the bits so what the media player is sending is exactly the same what is received by the audio device.
This obvious doesn’t rule out that either the audio device or the recorder does some DSP in hardware or if applicable its own software.
 

jkeny

Member Sponsor
Feb 10, 2012
3,427
0
0
Ireland
#16
Don't assume anything in the real world especially about jitter " DAC is supposed to eliminate these variations, as it has a large buffer, strips out the incoming spdif clock and applies it's own high quality clock http://www.chordelectronics.co.uk/specs/QDB76.pdf "

I suspect that there are other issues which can give rise to the same effects as jitter but are not arising directly from a jittery signal. Here's my conjecture: noise modulation on the ground connection resulting from the different PS usage profiles that arise between the different audio streams Wasapi, ASIO. I would anticipate modulating ground noise. This is communicated via the ground connection of your cable to the DAC & there it results in jitter at the analogue stage. This can only be picked up on the analogue output.
 
Jan 19, 2011
25
0
0
UK
#17
If you are recording digital out from the RME into digital Lexicon, jitter is a non-issue.
This is pretty much equal to transferring a file from one HD to another.
Only and only if the bits are converted to analog, jitter is an issue.

Your best bet is probably
A file, call it WAV1
Play and record it digital, call it WAV2

If your system is bit perfect ,after a time align WAV1 and WAV2 must be bit identical.

ASIO/WASAPI (exclusive mode) are bit transparent protocols, they don’t alter the bits so what the media player is sending is exactly the same what is received by the audio device.
This obvious doesn’t rule out that either the audio device or the recorder does some DSP in hardware or if applicable its own software.
Yes, that is what I would expect to see. I have followed your advice and taken a look at Audio DiffMaker to compare the files I already made (and analyzed using excel earlier in this thread).

Here are the results so far:

https://dl.dropbox.com/u/2078309/Audio/Analysis of bit-perfect data via Audio DiffMaker.odp

What's clear is i) that the software is working ok when set right, ii) that the files are not bit perfect. What is puzzeling, is that the system 'on paper' is set up like say above, and should be bit perfect.

I do need to do more work on this, but this is data and it don't look good :confused:
 
Jan 19, 2011
25
0
0
UK
#18
Thanks jkeny. I take the points your making. Though in the file which I have just submitted the bit-imperfect data I am supplying is obtained before the DAC is reached. Take a look at the powerpoint in the link, and I would very interested in any suggestions and comments people might have (so long as they are polite :)
 
Apr 3, 2010
16,022
0
0
Seattle, WA
#19
Capturing audio without loss can be tricky. It is possible that you are simply losing samples on the receive end. I don't know if you output allows loopback capture. If so, see if you can capture and play on the same PC by looping its digital output to input.
 
Jan 19, 2011
25
0
0
UK
#20
Capturing audio without loss can be tricky. It is possible that you are simply losing samples on the receive end. I don't know if you output allows loopback capture. If so, see if you can capture and play on the same PC by looping its digital output to input.
Hi Amir, this was something I am concerned about. I would say the capture end of my system is the weaker part. Lexicon Omega is not as high spec as the RME Hammerfall soundcard on my media PC. And the laptop is not as high spec as my Media PC.

Last year I did try outputting the RME to an Audigy card which are both on my Media PC, but there were clicks, which I why I deployed the laptop before.

What I am doing at present is re-installing an fresh install OS on my laptop. It's been crappy lately and it now has some issues with latency checker when I ran it today. I also have the option of using my son's new Alienware i7 machine, which is definitely spec'd enough for the job.

I plan to 1st off, sample the digital output from my Oppo DVD player, and then the Aten VC880 SPDIF, which will have the audio as de-embedded from the HDMI. I would expect these to be bit identical or at the very least reproducible in themselves. In this way, I can check if the capture end is working ok.

I will update when I have more info.... I would be interested if anyone reading has done a similar exercise and shown it to be 100% bit perfect... Have you done this?

Cheers,

Alan
 

About us

  • Founded in 2010 What's Best Forum invites intelligent and courteous people of all interests and backgrounds to describe and discuss the best of everything. From beginners to life-long hobbyists to industry professionals we enjoy learning about new things and meeting new people and participating in spirited debates.

Quick Navigation

User Menu

Steve Williams
Site Founder | Site Owner | Administrator
Ron Resnick
Site Co-Owner | Administrator
Julian (The Fixer)
Website Build | Marketing Managersing