Bit Perfect, KMIXER, Data and such
Aug 3, 2007 at 2:43 PM Thread Starter Post #1 of 30

Wavelength

Member of the Trade: Wavelength Audio
Joined
Jul 1, 2005
Posts
137
Likes
25
Gang,

There seems to be some confusion about somethings so let's just get something straight here.

All of these devices are bit perfect unless they have a DSP, Upsampler or some declared bit manipulation device imbedded in them. To say a device is bit perfect or not is silly. All these interface are meant to be robust bit perfect. This statement is predicated that the KMIXER and other Filter/Upsamplers on the computer are BYPASSED!

Bypassing the KMIXER via Kernel Streaming, ASIO or custom driver will in it self make the data to the dac bit perfect. The KMIXER will not be magically bypassed simply by plugging in a dac is silly or as an engineer at Microsoft said yesterday:

Quote:

There is a huge thread around the Benchmark DAC1-USB on head-fi that claimed it had some magic USB implementation that bypassed kmixer without resorting to kernel streaming.

I was not sure whether it was lack of understanding or over-aggressive marketing but I am afraid any device using the standard USB audio driver will have to live with kmixer.


There has also been some talk if there is a HARDWARE mixer declared in the USB Enumeration that this would bypass the KMIXER. I tried this and did not see any difference in the data coming out and therefore would declare this also untrue.

~~~~~~~

There is always the problem with USB, Firewire, SPDIF and other streaming devices of getting errors in communications. I had a dealer who got one of my products and had a Shuttle PC that he had built and all the USB ports sounded like crap. Then he put in a USB 2.0 card and wallaa it sounded great.

Looking and seeing your USB chain can have an effect on how well your sound is. The guys designing these PC's have accountants tied to their desk so believe me some of the ports on your computer will not output USB data as well as others. Also making sure you have the most current USB driver for your host controller can make a big difference.

On my HUSH Pc it says it has 6 usb 2.0 ports. I have a 100MHZ 12bit oscilloscope that is USB 2.0 and only one of those ports works. Also funny that is the best sounding port.

Any USB port on the front panel of a computer probably is wired via a cable and is not a good choice for USB type dacs.

~~~~~~

So why do some programs sound different? On a PC I think it consistency of code. The encoding and decoding of sound handled by source code in differing compilers and stuff happens before the data goes to the DAC it self. I think this is the biggest place were bit perfect statement could be killed, but not at the hardware layer.

I think we should be looking more at the Application Layer to see what's going on there and evaluate what's bit perfect or not.

Any device driver programers listening? Write a fake audio output device driver that would spool out the data to a file for comparison.

Any takers?

Thanks,
Gordon
 
Aug 3, 2007 at 3:00 PM Post #2 of 30
There is no difference between your USB ports... Ever tried to copy some files to an USB stick? Plug the stick in another port, and voila, the data is still the same.... It's digital, it can't sound any different
wink.gif

Plus there are error correction algorithms built in.
 
Aug 3, 2007 at 3:14 PM Post #3 of 30
Sorry to ask that intime, but... did ya smoke some bad weed?

Digital is digital. If you send data via USB, the arriving data is exactly the same as the sending data, except you use very cheapo usb cables which are not in the usb 1.1/2.0 specification an the error correction fails. Even when, I think the "sound" will not be affected. Clicks an pops, yeah, that _could_ happen. But the "sound" will stay the same.

Also, I really don't understand what you're blah-ing about that Software thingies? Yeah, as long as you're not using some DSPs on the signal, it WILL stay the same. Do you really think the producer is going to waste some CPU/SPU time just to make the data less original?

If you say, the KMIXER would mess up the sound, it would do some calculating on it. That would cost CPU time, and not even microsoft would be dumb enough to make this happen.

Also I can't agree with the statement that different code/compilers can affect the way programs do "sound". Digital data goes in, is sent to the sound card and will be converted from digital to analog.

Fact: The only place where sound could lose its quality is the DAC itself, or some DSPs that are attached to the data.
 
Aug 3, 2007 at 4:59 PM Post #4 of 30
This forum has a strayed a long way from what is was a few years ago.

USB ports can of course be different. Different chips have different characteristic and you might end up with a much higher error rate one port vs. the other. While that might work fine on a USB key where you retransmit on errors the situation is very different on an isochronous audio endpoint. There are no retransmits here.

Quote:

If you say, the KMIXER would mess up the sound, it would do some calculating on it. That would cost CPU time, and not even microsoft would be dumb enough to make this happen.


This is probably not even worth responding to but from your answer it is clear you have never looked at this at all.

Cheers

Thomas
 
Aug 3, 2007 at 8:21 PM Post #5 of 30
If you are using DirectSound output, you are requesting Windows (XP, Vista, or whatever) to MIX your sounds with those made by other applications. This is great if you are playing music using some audio program while playing a game that makes sounds also, for example.

If you are using KernelStreaming or ASIO output, you are requesting that the audio data should be sent directly to the audio driver, without mixing.

It really is that simple. Let's move on.
 
Aug 3, 2007 at 8:44 PM Post #6 of 30
I would like to understand why using DirectSound or any other Kmixer related output method degrades the sound quality. If there are no other applications playing audio at the same time, there should happen no mixing and the audio stream should just be passed on to the device driver by Kmixer - or did I miss something?
 
Aug 3, 2007 at 9:00 PM Post #7 of 30
In theory, it seems like kmixer should not do anything to the incoming audio data if there is nothing else playing. Apparently, under Windows XP, this is not always the case. I highly doubt anyone can actually hear a difference between bit-perfect and some low-order bit being munged in kmixer, but if by some miracle of nature you can, there's always KernelStreaming and ASIO.
smily_headphones1.gif
 
Aug 3, 2007 at 9:04 PM Post #8 of 30
Guys,

Do you know that when you write to a drive it does check to see if it is written correctly and if it is not then it does re-write it till it happens. This is part of the way the os handles writing files. It does the same thing for hard drives and other devices.

But on audio there is no error correction or retransmission. Errors will sound like crap and there is no such thing as all USB ports being the same. Heck look use USB View or on the MAC USB Prober and see what the USB connections scheme is on your computer.

Most use internal hubs and only present some directly from the controller the rest are via an internal hub. You tell me which one might be better.

Finnally before I go have a beer... digital is never digital. If this was the case we would all own the same thing.

Thanks
Gordon
 
Aug 3, 2007 at 9:29 PM Post #9 of 30
Quote:

Originally Posted by Scrith /img/forum/go_quote.gif
I highly doubt anyone can actually hear a difference between bit-perfect and some low-order bit being munged in kmixer, but if by some miracle of nature you can, there's always KernelStreaming and ASIO.
smily_headphones1.gif



There is a subtle, but consistent, difference on my main computer between kmixer and "direct" KernelStreaming/ASIO...

There only seemed to be a difference in the bass area... The words, "muddy", "muddled", "muffled", "blurred" come to mind for the kmixer sound, and "distinct", "punchy", "animated", "clear" for the "direct" alternatives.

Admittedly, it is only a slight difference, but it was enough to convince me to use ASIO output for music playback on my main computer
 
Aug 4, 2007 at 12:42 AM Post #10 of 30
Quote:

Originally Posted by CTY /img/forum/go_quote.gif
I would like to understand why using DirectSound or any other Kmixer related output method degrades the sound quality. If there are no other applications playing audio at the same time, there should happen no mixing and the audio stream should just be passed on to the device driver by Kmixer - or did I miss something?


Kmixer resamples to 48 KHz IIRC, hence the "bit-perfectness" goes out of the window. Also, it may do volume adjustment. Digital volume adjustment = loss of precision. Whether any of the 2, or even both combined, will produce an audible effect is up to you to decide.
 
Aug 4, 2007 at 3:30 AM Post #11 of 30
kmixer does not resample your data to 48 Khz if your sound card supports 44.1 Khz.

It does however still modifies the bits for 16/44.1 audio data even if there is only one stream playing and your hardware supports 44.1Khz. This is also true for any USB audio devices that uses the system provided USB driver. You get the benefit of mixing the sound from multiple applications at the cost of a slight degradation in sound quality for a single stream. There are a few cards like the RME sound cards that get around this problem on XP.

These changes are subtle and only affect the two lowest significant bits. There is a special clip called udial that makes these modification quite audible.

As Scrith said, if you need bit transparent playback you should look into Kernel streaming, ASIO, or into the exclusive mode APIs on Vista.

Cheers

Thomas
 
Aug 4, 2007 at 9:51 PM Post #12 of 30
Hmm, I don't know the technical details, so I'm just speculating I guess (so this post is worthless!), but I'm wondering what the driver has to do with the kmixer service...maybe it is asking the driver to do some optional pre-processing before it does the "mixing" (perhaps the resampling, but I'm pretty sure it can do that on its own). Oh well.

By the way, there's something more to KernelStreaming / ASIO under Vista that I've noticed. Not only is it exclusive (as I mentioned in a previous post, when I am playing music in Foobar2000 using KernelStreaming output, I can't make sounds with any other applications, or Windows itself), but it seems that the audiodg.exe ("Windows Audio Device Graph Isolation") task has a low priority (assuming this is what is doing the mixing in Vista...I'm not sure though), so if I'm doing CPU-intensive stuff (like encoding into FLAC in the background while playing music in Foobar2000) and using DirectSound output in Foobar2000 I get clicks and pops in the audio, whereas when I'm using KernelStreaming output it is never interrupted by tasks like FLAC encoding in the background.
 
Aug 5, 2007 at 5:29 AM Post #13 of 30
Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif
kmixer does resample your data to 48 Khz if your sound card supports 44.1 Khz.

It does however still modifies the bits for 16/44.1 audio data even if there is only one stream playing and your hardware supports 44.1Khz. This is also true for any USB audio devices that uses the system provided USB driver. You get the benefit of mixing the sound from multiple applications at the cost of a slight degradation in sound quality for a single stream. There are a few cards like the RME sound cards that get around this problem on XP.

These changes are subtle and only affect the two lowest significant bits. There is a special clip called udial that makes these modification quite audible.

As Scrith said, if you need bit transparent playback you should look into Kernel streaming, ASIO, or into the exclusive mode APIs on Vista.

Cheers

Thomas



Thomas - I have licensed the same firmware that Benchmark licensed for their DAC-1 USB. This definitely sounds better IMO than any ASIO, KS or even unmapping that I have done with my USB devices. It is very similar to the unmapped USB device sound quality, but maybe less jitter. It uses the native Windows drivers, and can enumerate automatically when you change sample rates. The company that developed this firmware claims that they are doing some software trickery to get this done, and I believe them. I know some things for sure, that:

1) It got rid of any pops and ticks
2) sound quality is the best I have heard from USB - bit perfect
3) enumerates automatically - supports 24/96

I dont understand it, but I believe they have a breakthrough, as does Benchmark.

I was tired of trying to "tune-out" the windows junk and pops and ticks etc.. I wanted to make it plug-and-play and this does the trick. Before this, I was faced with sending these systems to reviewers and spending time on the phone to tune it and get rid of the pops and ticks. It's a disaster.

Steve N.
 
Aug 5, 2007 at 5:52 PM Post #14 of 30
Hi Steve,

I have been trying to get any reasonable explanation out of Benchmark of why this could be. As far as I know the usbaudio.sys driver will always connect to kmixer in the audio graph.

Unfortunately you can not actually look at the bits with a DAC1 so this is hard to test. If you have this firmware on one of your devices with digital output and you would feel comfortable to send it to me for a week or so I'd be happy to look at what is actually happening.

Getting rid of some of the pops is probbaly best achieved by not relying on reconstructing the incoming rate from the isochronous USB audio mode but to use async mode with a local crystal and a flow-control channel back to the PC (like the Audigy 2NX). This issue is of course orthogonal to bit modifications introduced by the audio stack.

Cheers

Thomas
 
Aug 5, 2007 at 6:31 PM Post #15 of 30
Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif
Hi Steve,

I have been trying to get any reasonable explanation out of Benchmark of why this could be. As far as I know the usbaudio.sys driver will always connect to kmixer in the audio graph.

Unfortunately you can not actually look at the bits with a DAC1 so this is hard to test. If you have this firmware on one of your devices with digital output and you would feel comfortable to send it to me for a week or so I'd be happy to look at what is actually happening.

Getting rid of some of the pops is probbaly best achieved by not relying on reconstructing the incoming rate from the isochronous USB audio mode but to use async mode with a local crystal and a flow-control channel back to the PC (like the Audigy 2NX). This issue is of course orthogonal to bit modifications introduced by the audio stack.

Cheers

Thomas



Thomas - that's very kind of you. I probably could ship you an Off-Ramp I2S, which has I2S digital output from the USB interface, or an Off-Ramp Turbo 2, which has S/PDIF coax output. The Turbo 2 is my only demo unit here, so I need it back quickly. The I2S unit I can live without for a longer period.

Steve N.
 

Users who are viewing this thread

Back
Top