[zheka]

Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif Kmixer does not know that the bits flowing through the audio stack are DTS encoded. To the system these bits look like PCM bits, ...

exactly, so kmixer is trying to deal with DTS encoded stream as if it is PCM which of course does not work. Here is what happens:


Quote:

A Dolby Digital stream is sent in units called frames. These frame contains 1536 PCM samples per channel. Since the Dolby Digital stream is compress, the same amount of music data (in time) takes less time than real-time PCM streams. The KMixer (depending on one type of connection), thinking that this is a PCM stream, as specified in the header, can run out of data to feed into the SPDIF stream. It fills the missing time with zeros and thus you get a destroyed stream. Additionally, since the WAV file was not defined as an AC3 file, the SPDIF frame header was not specified correctly. So your receiver does not know to that this is a Dolby Digital Stream (just like Windows didn't know).

http://archive.avsforum.com/avs-vb/s...19#post2498819

cheers

gd

 

[Crowbar]

Quote:

Originally Posted by zheka /img/forum/go_quote.gif kmixer is not designed to work w/ dts streams, hence "dts test" is meaningless for determining of bit-perfect playback capabilities

Absolutely false. You fail to understand what the DTS test is. The only way kmixer knows what it is being sent is by telling it what one is sending; it is not intelligent and cannot look at a stream of bits and by its content figure out whether it is PCM or DTS! The DTS sends DTS data that's presented as being PCM data. If kmixer doesn't modify PCM, then it won't modify this DTS data dressed as PCM. If it modifies it, unlike a slightly modified PCM which will sound almost the same, the DTS will simply not work due to the different way sound is encoded, and thus this is the perfect way to test bit perfect output. I realize you're eager to post, but please, do some research first so there is less misinformation spread around here.

 

[Crowbar]

Quote:

Originally Posted by zheka /img/forum/go_quote.gif exactly, so kmixer is trying to deal with DTS encoded stream as if it is PCM which of course does not work. Here is what happens: http://archive.avsforum.com/avs-vb/s...19#post2498819 cheers gd

What you posted is about Dolby Digital, not DTS. Again, DTS can be presented as a PCM stream and kmixer has no way of knowing the data is DTS and not just some random noise. The proof is in the fact that the DTS test works on bit-perfect configurations.

 

[Crowbar]

Quote:

Originally Posted by tszyn /img/forum/go_quote.gif Here is a quote from MSDN which seems to confirm that at 100% wave volume KMixer leaves the original stream intact:

As a software developer, I wish Microsoft documentation was 100% reliable.

 

[Crowbar]

Quote:

Originally Posted by jiiteepee /img/forum/go_quote.gif KMixer System Driver ...

That whole section doesn't have anything to do with the comment by thomaspf that you're quoting. Again, kmixer doesn't determine what data is being sent to it by content. When a DTS stream is presented to it as PCM, it has no way of distinguish it from a PCM holding random noise.

 

[zheka]

Quote:

What you posted is about Dolby Digital, not DTS. Again, DTS can be presented as a PCM stream and kmixer has no way of knowing the data is DTS and not just some random noise.

oic. so it is possible to have DTS encoded stream that is not "compressed", meaning that buffer starvation would not be an issue?

 

[Crowbar]

Technically, kmixer shouldn't have PCM buffer underruns unless the application actually stops playing. The application doesn't time itself, it just plays into a buffer limiting writing speed as to not overflow it, so timing is controlled by the hardware, not the application. It makes no sense to me that buffer underruns could occur without extreme system load. It seems to me whoever posted that has admitted to yet another Microsoft problem.
DTS doesn't have the framing format of Dolby Digital, which may make it more resilient to this issue.
The best way to determine whether there is bit-perfect output with only zero-filling offsets being the problem is to build hardware that will receive a digital stream and loop it back to the PC, then the two streams compared with zeroed spans removed from the latter. I can do something like this in a couple of months.

 

[zheka]

Quote:

Originally Posted by Crowbar /img/forum/go_quote.gif What you posted is about Dolby Digital, not DTS. Again, DTS can be presented as a PCM stream and kmixer has no way of knowing the data is DTS and not just some random noise. The proof is in the fact that the DTS test works on bit-perfect configurations.

if by bit-perfect configs you mean kernel streaming and such then it hardly proves your point - AFAIK KS would pass along to the client whatever data comes its way, untouched.
the role of KMixer on the other hand requires much more action. at the very least it has to parse the header, buffer the stream, mix/attenuate if necessary and then "reassemble" the stream as real-time PCM. And , at least in theory, if no mixing and/or attenuation was preformed, the "re-assembled" PCM stream should be bit-perfect (if the original was true PCM).
according to the posts i quoted, it is this reassembling part that breaks compressed streams masqueraded as PCM.


respectfully

gd

 

[Crowbar]

Quote:

Originally Posted by zheka /img/forum/go_quote.gif at the very least it has to parse the header, buffer the stream, mix/attenuate if necessary and then "reassemble" the stream as real-time PCM.

Parsing the header doesn't modify the stream, buffering doesn't modify the stream, mixing and attenuating wouldn't if volume is at 100% and there is only stereo PCM playing as is the configuration clearly being discussed here, and given all of these, reassembling should result in a stream identical to the one that was input. If reassembling under these conditions creates a stream different from the original, then the sound subsystem is flawed. But we already knew that.

 

[jiiteepee]

Quote:

Originally Posted by Crowbar /img/forum/go_quote.gif That whole section doesn't have anything to do with the comment by thomaspf that you're quoting. Again, kmixer doesn't determine what data is being sent to it by content. When a DTS stream is presented to it as PCM, it has no way of distinguish it from a PCM holding random noise.

So, "Kmixer is only active for PCM streams" is true even there is a mention 'bout support for IEEE floating-point data? Or does that line just mean PCM as IEEE fp data?

jiitee

P.S. If that's the case then, why he doesn't want to add that information into his sig?

 

[Crowbar]

Because he doesn't want his views here to be considered as representing those of Microsoft; this is standard procedure. That is why I PMed you, and posting it here was a pretty dumb thing to do: it doesn't hurt me, it can create problems for him at his job. But I'm sure you already understand all this and are simply mean-spirited and don't care that if in your attack on me you create potential issues for others. Cheers on showing your true colors. You must be a very sad human being.

 

[jiiteepee]

Quote:

Originally Posted by Crowbar /img/forum/go_quote.gif Because he doesn't want his views here to be considered as representing those of Microsoft; this is standard procedure. That is why I PMed you, and posting it here was a pretty dumb thing to do: it doesn't hurt me, it can create problems for him at his job. But I'm sure you already understand all this and are simply mean-spirited and don't care that if in your attack on me you create potential issues for others. Cheers on showing your true colors. You must be a very sad human being.

Without your meaningless PM that would have never been happened so don't blame me!

BTW, now he can uncover how this kmixer works and stop this (in that case useless) thread.

What 'bout the "missing error correction" in USB Audio standard ...?

(Source: http://www.driverheaven.net/general-...g-drivers.html)

... 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

 

[Crowbar]

Quote:

Originally Posted by jiiteepee /img/forum/go_quote.gif Without your meaningless PM that would have never been happened so don't blame me!

Wow, you're really out of it. That's like saying, without you giving me a gun I wouldn't have killed that person. You're the one that posted it publicly, and you deserve a ban for this; at the very least the moderators should edit that post.

Quote:

BTW, now he can uncover how this kmixer works and stop this (in that case useless) thread.

He doesn't work on the sound team.

By the way, if you're going to be posting text as images, use PNG instead of JPEG because the latter creates annoying artifacts around text, and PNG deals with large areas of flat color well. Indeed, the second image you posted shouldn't have been an image at all, but a copy and paste of the text. Why waste everyone's bandwidth by representing something with hundred times the data size needed?

Quote:

If there are no correction then ... what's the point arguing 'bout bit-perfectness through USB?

There's no relation between error correction and bit-perfect output. Your logical thinking is failing, badly. If there was error correction on a modified-by-kmixer stream, it would just ensure that this non-bit-perfect (with respect to the original stream put out by the player application) stream would be error free. Error correction in USB modes that support it (bulk/burst transfer) functions to guarantee the data that the USB driver is being fed for output will not have errors. It doesn't have any knowledge of the type of data and whether it was modified by levels above it. This is pretty basic stuff, and if you don't understand it, you have no business posting here.

 

[zheka]

Quote:

Originally Posted by Crowbar /img/forum/go_quote.gif Parsing the header doesn't modify the stream, buffering doesn't modify the stream, mixing and attenuating wouldn't if volume is at 100% and there is only stereo PCM playing as is the configuration clearly being discussed here, and given all of these, reassembling should result in a stream identical to the one that was input. If reassembling under these conditions creates a stream different from the original, then the sound subsystem is flawed. But we already knew that.

Crowbar,

Please take a look at this article
http://www.microsoft.com/whdc/device/audio/Non-PCM.mspx

and specifically AC-3 Data related part
http://www.microsoft.com/whdc/device...PCM.mspx#E2BAC

in case of KMixer:
1. frames are not padded hence possible data starvation
2. proper S/PDIF header frame is not set to indicate that this is non-PCM data

either of the above would render dd/dts streams unusable. this however cannot be blamed on KMixer since wave header claimed that this is PCM stream. if proper wave header was specified then KMixer would not have touched the file.

what am i missing here?

respectfully

gd

 

[Crowbar]

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.