WinAmp ASIO- Soundstage varies inversely with Buffer?
May 30, 2008 at 3:48 AM Post #16 of 41
Actually, it is possible to get right down to sample perfect audio. Requires a little more software know-how than winamp, however.

Regardless.

Changing the ASIO buffer will have zero effect on the sonic quality of music (although, of course, setting the buffer too low can have some nasty effects, but nothing subtle).

What you might be experiencing is some artefacts being introduced due to changing the buffer ON THE FLY. Changing the buffer on the fly would mean some quick calcuations and adjustments by the computer, which could conceivably affect the audio.

There are times while working within my DAW that I'll need to change buffer sizes, and if audio is playing, there is a varying degree of effect depending on my processor load.

This could potentially explain it.

But this begs the question: why would you need to change ASIO buffer size on a stereo stream of audio while its playing? Doesn't make too much sense.
 
May 30, 2008 at 4:05 AM Post #17 of 41
Quote:

Originally Posted by d-cee /img/forum/go_quote.gif
if you're changing the SPDIF signal to HDCD format then it's automatically not bit perfect

if you're trying to claim that a DAC knows whether it's being fed a bit perfect FLAC file as opposed to a 128kbps lossy mp3 and stops working on the latter I think you're the one that needs brushing up on digital theory



HDCD runs on the LSB of a standard 16bit audio stream, so it can still pass through SPDIF to a HDCD decoder. However, the HDCD control bit is only 1bit of the sample, and you can't guarantee bit perfectness of the entire stream with it. All it guarantees is that the LSB is bit perfect.
 
May 30, 2008 at 4:33 AM Post #18 of 41
Quote:

Originally Posted by b0dhi /img/forum/go_quote.gif
...and you can't guarantee bit perfectness of the entire stream with it. All it guarantees is that the LSB is bit perfect.


precisely

unless i'm reading it wrong (probably) it appears regal is implying that because it works means that the entire chain is bit perfect
 
May 30, 2008 at 1:03 PM Post #19 of 41
HDCD is sent encoded in the SPDIF stream. The conversion takes place in the DAC's PMD100 filter. If a bitperfect signal is present (playing HDCD encoded material) the PMD100 sends a signal and lights the LED.

A computer is not going to change only the LSB. If an SPDIF stream passes the DTS or HDCD test it is bit perfect unless someone is intentionally manipulating the output.
 
May 30, 2008 at 4:36 PM Post #20 of 41
I've seen far too many occasions where bitperfect was not working even when all the settings appeared to be correct.

It needs to be tested to verify bitperfect as there is no logical explanation (that I have heard) for why the buffer would change the sound unless the stream is not bitperfect.

The DTS test is the easiest.
Download DTS wave file. Just Google.
Hook up digital output to the input of a device that can decode DTS (reciever etc.).
Play file, and listen for the sound. If you have a static like sound then you are not bitperfect.
 
May 30, 2008 at 6:43 PM Post #21 of 41
Quote:

Originally Posted by regal /img/forum/go_quote.gif
A computer is not going to change only the LSB. If an SPDIF stream passes the DTS or HDCD test it is bit perfect unless someone is intentionally manipulating the output.


Since we don't know what could be causing the change to the sound (assuming it's real), we don't know if it's caused by a software bug (which would mean it could affect only certain bits while leaving the LSB intact).
 
May 31, 2008 at 4:17 AM Post #22 of 41
Quote:

Originally Posted by b0dhi /img/forum/go_quote.gif
Since we don't know what could be causing the change to the sound (assuming it's real), we don't know if it's caused by a software bug (which would mean it could affect only certain bits while leaving the LSB intact).


Actually we do, its the Kmizer or SC resampling to 48khz not being a multiple of 44.1k it affects al the bits. Or a volume change (digital.)

If you pass the HDCD or DTS test you have bitperfect. I can lower the volume (from the computer) even one slight notch down and the ouput fails the test.
 
May 31, 2008 at 5:20 AM Post #23 of 41
Quote:

Originally Posted by regal /img/forum/go_quote.gif
Actually we do, its the Kmizer or SC resampling to 48khz not being a multiple of 44.1k it affects al the bits. Or a volume change (digital.)


I'm not sure if you've been reading any of the previous posts, but we've been talking about how adjusting the ASIO buffer size seems to affect the soundstage for some people. Kmixer has nothing to do with it.
 
May 31, 2008 at 5:47 AM Post #24 of 41
It has everything to do with it. If your ASIO is bit perfect and truly bypassing KMixer then increasing buffer size cannot impact the sound quality in anyway as long as you aren't skipping.
 
May 31, 2008 at 6:00 AM Post #25 of 41
ASIO always bypasses kmixer. Changing the buffer size shouldn't have any effect even if kmixer is involved. Kmixer has nothing to do with this discussion.
 
May 31, 2008 at 6:05 AM Post #26 of 41
ASIO doesn't always bypass Kmixer, you are incorrect.

Resampling (Kmixer)would affect the sound quality.

The only way that changing buffer size would affect SQ is if the SPDIF was not bitfperfect.
 
Jun 1, 2008 at 12:22 PM Post #27 of 41
Quote:

Originally Posted by regal /img/forum/go_quote.gif
ASIO doesn't always bypass Kmixer, you are incorrect.


Please stop talking from your ass. From Audio Stream Input/Output:
Quote:

ASIO bypasses the normal audio path from the user application through layers of intermediary Windows operating system software, so that the application connects directly to the soundcard hardware.

...

Its main strength lies in its method of bypassing the inherently high latency of operating system audio mixing kernels (KMixer), allowing direct, high speed communication with audio hardware.


 
Jun 2, 2008 at 4:57 AM Post #28 of 41
Quote:

Originally Posted by b0dhi /img/forum/go_quote.gif

Please stop talking from your ass. From



LOL

orig.jpg
 
Jun 2, 2008 at 12:55 PM Post #29 of 41
There are many reported instances of ASIO not by-passing Kmixer, especially ASIO4All. You have a lot of faith in drivers workings as intented in a MS environment. There is a big gap between WIkipedia quotes and practice, you obviously have little experience in this area.

But I am just trying to help you guys understand, why the attacks?
 
Jun 2, 2008 at 4:30 PM Post #30 of 41
What ASIO4All does to achieve its ASIO emulation is up to it. If it wants to call itself an ASIO driver while not always correctly implementing the ASIO specifications, so be it. But using a true ASIO driver, on the other hand, will always bypass kmixer. That is the purpose of ASIO, and it is always implemented that way in a proper driver.
 

Users who are viewing this thread

Back
Top