|Originally posted by Cliff Watson
You say that you want to help but forgot to say whom you?re helping. I had a gut feeling about you from the beginning and you have posted nothing to make me change my mind that you have been assigned to ?plug this hole? by convincing us dumb Windows users that we are the ones confused.
Until last Monday, I knew nothing of the KMixer, streams or WDM. The constant posts about possible KMixer bugs sparked my interest. Since I am a HTPC enthusiast, I wanted to investigate this quality loss. I have not been assigned any tasks. I am researching this for the HTPC community on my own time. I have not called any one dumb, but I've toned down my technical responses so that non-developers can understand. You are putting words in my mouth.
|That gut feeling was the primary reason that I refused to supply you the names of Microsoft employees that have tried to help with audio bugs. Hell will freeze over before I rat out a MS employee that actually understands the problems and tries to do something about it.
That is fine. You don't need to name your sources, but understand, that I can't accept your claims without proof (data).
Is there any reason why you have been attacking me for the past couple of pages? I feel that I have provided enough proof to back up what I'm saying. Is it possible to work constructively on this issue?
Here's a summary:
The KMixer is for PCM streams (uncompressed data). When streams are passed through it, the KMixer handles it as an uncompressed stream. Since the PC is a dynamic environment (multiple things can happen at any given time), the KMixer buffers streams. Also, since it is a multi-purpose component it handles multiple streams, mixing and volume control. When uncompressed streams pass through the KMixer there appears to be a negligible "dithering" of the stream (KikeG). It is not resampling streams if the input and the output match and there is one stream (KikeG). When sent to the SPDIF it is sent with an Audio frame header (I got this from you).
When presented with a non-PCM stream, the KMixer is bypassed. It is sent through SPDIF with a Data frame header (also from you).
The issue that you are running into is that the streams (that were provided on the first page) are incorrectly marked as PCM. So they are sent to the KMixer and treated as uncompressed streams. If the Dolby Digital stream header is corrected (as per my instructions), it will be compliant and the OS will see it as and non-PCM stream. It will then bypass the KMixer and send it to SPDIF with a Data frame header (can you verify this with hooking up a scope to the SPDIF to see what is actually being sent?).
I haven't dug into the DTS streams too much, but they should probably not be set to PCM data format as they are not PCM. I haven't been able to find any technical information on the DTS spec. Can anyone help me with this, or get me in touch with someone at DTS to work on this together?
I went out to buy a DTS CD, but found the selection to be sub par. Is someone willing to help me try to debug this?
All I've been able to do is look at a regular CD and see the the format is defined as CDDA. I am unable to find any standard specification for DTS-CD.
The most probable reason why your STB (set top box) works on these streams is because it ignores this header field. It doesn't care that the stream can have many different formats and it only cares about 3 (PCM, Dolby Digital, and DTS). The OS on the other hand has to be able to handle multiple formats for a WAV file. It does this by adhering to a standardize specification.
Here's a good graphical break down of the WAV format:http://ccrma-www.stanford.edu/course...cts/WaveFormat
Here's an RFC on the WAV formats:ftp://ftp.rfc-editor.org/in-notes/rfc2361.txt
Is anyone else still confused about what is going on with the KMixer?