Clearing up the KMixer confusion
Jun 5, 2007 at 9:26 PM Post #61 of 105
It seems you are getting hung up on the DTS encoded nature of these files so just think about HDCD encoded files. Are these PCM files in your mind? Should you be able to get exactly the same bits that are on the disc out on a digital output so you can connect a DAC that decodes the embedded HDCD signature? This case is not any different from the DTS example and that is equally not possible. The key is that you never get to listen to what is really on your CDs.

DVDs with Dobly and DTS sound tracks are a completely different matter and you should not confuse these two cases.

Cheers

Thomas
 
Jun 5, 2007 at 9:36 PM Post #62 of 105
Quote:

... or is the information which above poster give, incorrect? If there are no correction then ... what's the point arguing 'bout bit-perfectness through USB?


jiitee


The reason is that this statement is obviously not correct. If it would be correct than no one should be able to enjoy HDCD/DTS playback from a USB connected digital output. I regularly do that and it seems to work just fine. USB audio uses isochronous streams without correction and while I don't know exactly what the bit error rate on a USB link is, it is apparently low since I can listen to complet albums without a hitch.

Cheers

Thomas
 
Jun 5, 2007 at 9:38 PM Post #63 of 105
disclaimer: my understanding of digital sound technology is limited at best. Crowbar, thomaspf,tszyn and many others are much more experienced in this field than i can ever be.
i keep bringing up this old argument about DTS test because
1 i could not find any convincing rebuttal of this argument
2. it seems to explain the possibility that KMixer may provide bit perfect playback for true PCM streams yet fail "DTS test"

note that back then no one claimed that it is possible to have bit-perfect output from KMixer no matter what format. so the whole argument was more about the validity of the dts test in principal.
 
Jun 5, 2007 at 9:41 PM Post #64 of 105
Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif
It seem you are getting hung up on the DTS encoded nature of these files so just think about HDCD encoded files. Are these PCM files in your mind? Should you be able to get exactly the same bits that are on the disc out on a digital output so you can connect a DAC that decodes the embedded HDCD signature? This case is not any different from the DTS example and that is equally not possible. The key is that you never get to listen to what is really on your CDs.

DVDs with Dobly and DTS sound tracks are a completely different matter and you should not confuse these two cases.

Cheers

Thomas



i must admit that i know of no good explanation why HDCD playback fails
 
Jun 5, 2007 at 9:45 PM Post #65 of 105
Quote:

Originally Posted by zheka /img/forum/go_quote.gif
could it be that x-meridian actually takes over kmixer tasks as decribed in http://www.head-fi.org/forums/showpo...5&postcount=33 ?


Not likely. According to the Microsoft quote below, hardware acceleration only makes a difference for DirectSound. I can get bit-perfect output on the X-Meridian with waveOut output as well (which goes through KMixer).


Quote:

Here's how acceleration works. A driver without H/W acceleration provides a single "pin" (output stream). Only KMixer gets to connect to this pin. The sound coming from all applications is mixed down to a single stream by KMixer and send to the pin. A driver with H/W acceleration provides multiple pins, e.g. 64. KMixer always grabs one of them, but the other 63 are available to dsound apps (they're what you get when you ask for DSBCAPS_LOCHARDWARE buffer).


http://forums.microsoft.com/MSDN/Sho...77121&SiteID=1

Tomasz
 
Jun 5, 2007 at 10:18 PM Post #66 of 105
Quote:

Originally Posted by Crowbar /img/forum/go_quote.gif
Sanity check:
When ASIO and kernel streaming is used, obviously correct S/PDIF and other output still occurs. If kmixer cannot reproduce identical output to these cases (ignoring the obviously increased latency) when there's no reason to do resampling and volume attenuation, then it is flawed, and very much at fault--simple as that.



okay, maybe it is a design flaw. This is not essential to this argument though.
in pure form the argument is that the effect of KMixer on DD/DTS streams is different from the one on true PCM data. hence DTS files masqueraded as PCM should not be used for bit transparency tests of kmixer since it fails for different reasons.
 
Jun 5, 2007 at 11:21 PM Post #67 of 105
Jun 5, 2007 at 11:24 PM Post #68 of 105
Quote:

Originally Posted by zheka /img/forum/go_quote.gif
the effect of KMixer on DD/DTS streams is different from the one on true PCM data.


The point is that there is an effect on both. If there was no effect at all on PCM files, then there would be none on DTS presented as PCM either. Even if the effect is just silence insertions, that is still an effect, and my understanding is that though that breaks Dolby Digital, it won't necessarily break DTS decoding and thus the implication is that there is more than that happening here.
 
Jun 5, 2007 at 11:32 PM Post #69 of 105
Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif
The reason is that this statement is obviously not correct. If it would be correct than no one should be able to enjoy HDCD/DTS playback from a USB connected digital output.


You're wrong. If there's resampling or attenuation done by kmixer, that affects every single data word. Error rates causing changes an order of magnitude lower wouldn't necessarily interfere with decoding of DTS, but can still compromise audio quality.

Gordon Rankin from Wavelength Audio told me that measurements with a USB analyzer showed a high error rate on the Windows systems, especially with longer cables, and I'm certain he's quite capable of performing such a measurement correctly. It could be a problem with specific hardware and software configurations, but to say it's not an issue at all is unwarranted.
 
Jun 5, 2007 at 11:35 PM Post #70 of 105
When you prepare yourself a custom wave file with known samples and record it from a digital output you can look at what these changes are.

What I found is that there are mostly changes to the lowest significant bit with regular but rarer occasions where the second bit is also changed versus the original. So far I have found no way to bypass this with the standard USB audio driver and the device that Elias recommended for bit perfect playback does not seem to be bit perfect after all.

btw. Microsoft has a tool called ksstudio in the DDK that allows you to inspect the kernel graph that is used for audio rendering.

Cheers

Thomas
 
Jun 5, 2007 at 11:37 PM Post #71 of 105
DACs aren't linear to 24 bits, so I don't see why it would matter then.
 
Jun 6, 2007 at 2:17 AM Post #73 of 105
Quote:

Originally Posted by Crowbar
You're wrong. If there's resampling or attenuation done by kmixer, that affects every single data word. Error rates causing changes an order of magnitude lower wouldn't necessarily interfere with decoding of DTS, but can still compromise audio quality.

Gordon Rankin from Wavelength Audio told me that measurements with a USB analyzer showed a high error rate on the Windows systems, especially with longer cables, and I'm certain he's quite capable of performing such a measurement correctly. It could be a problem with specific hardware and software configurations, but to say it's not an issue at all is unwarranted.




I am not a great expert on this but as far as I know DTS is pretty sensitive to even single bit errors, which you can try ouy by introducing a few in a DTS track. It depends on your decoder whether they make up for the gaps much like a CD player invents music for scratched regions or give you an audible click.

I scoped this pretty much to my experience in my last posting and I have been doing these test over many years on many systems. In my experience this has not been a big issue but I am sure you can find a system were it will. You will also be able to find other S/PDIF sources that do not work well.

All of this is of course a bit besides the main topic of this thread.

Cheers

Thomas
 
Jun 6, 2007 at 2:38 AM Post #74 of 105
Quote:

Originally Posted by Crowbar /img/forum/go_quote.gif
The point is that there is an effect on both. If there was no effect at all on PCM files, then there would be none on DTS presented as PCM either. Even if the effect is just silence insertions, that is still an effect, and my understanding is that though that breaks Dolby Digital, it won't necessarily break DTS decoding and thus the implication is that there is more than that happening here.



what would happen if IEC61937 data stream (DTS, DD, whatever) is being passed via S/PDIF but S/PDIF frame headers indicate that enclosed data is regular audio?
 
Jun 6, 2007 at 2:50 AM Post #75 of 105
Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif
When you prepare yourself a custom wave file with known samples and record it from a digital output you can look at what these changes are.



this is exactly what i am planning to do.

Quote:

What I found is that there are mostly changes to the lowest significant bit with regular but rarer occasions where the second bit is also changed versus the original. So far I have found no way to bypass this with the standard USB audio driver and the device that Elias recommended for bit perfect playback does not seem to be bit perfect after all.


I should have asked this before - have you tried only DTS test w/ Edirol device or you have tested with known file samples and HDCD playback test?

also, have you tried to record output of DTS file? if so are the differences from the original similar in nature to what you observed w/ regular PCM files?

i truly appreciate you taking time to answer these questions

respectfully,

gd
 

Users who are viewing this thread

Back
Top