WinAmp ASIO- Soundstage varies inversely with Buffer?
Jun 2, 2008 at 4:39 PM Post #31 of 41
I agree, but true ASIO drivers in the consumer soundcard market are hard to find. You have to do the HDCD or DTS test to find out if they are working properly.

And if changing the ASIO buffer has an affect on SQ, then I would say they can't be working.
 
Jun 2, 2008 at 6:19 PM Post #32 of 41
Quote:

Originally Posted by upstateguy /img/forum/go_quote.gif
LOL

orig.jpg



USG - you are my hero
biggrin.gif


By the way, I tried out the Kernal Buffer change you mentioned in the ASIO4ALL config utility, but I wasn't able to observe any change in the trebles.

Ultimately, I think Dodeca has probably properly diagnosed the situation when he said:

Quote:

Originally Posted by Dodeca /img/forum/go_quote.gif
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.



Then again, Foobar doesn't seem to allow for a change in buffer on the fly, and the two audio-asylum posters who claim to observe the same effect were apparently using both Foobar and Winamp.

While I understand that buffer should have no impact on a "bit perfect" stream of digital data, my question is really whether the buffer might potentially impact clocking/rate of transmission of the data, such that it could possibly impact my perception of sound stage?

There seem to be wide degrees of variation in jitter and proper clocking in spdif signals based on the implementation (and I would assume the X-fi isn't particularly strong in this respect) - does "bit perfect" entail perfect clocking? Is there even such a thing?

I didn't have an opportunity to try the DTS test through my receiver this last weekend, but I'm hoping to give it a shot in the near future.
 
Jun 4, 2008 at 12:36 AM Post #33 of 41
Using ASIO and Foobar with an Auzentech Prelude, there is no change in sound quality by chainging the buffer.

DTS test passes at all settings of the buffer.

The most probable sounding explanation is that there is a software bug that is causing the stream to not be bitperfect as the buffer is changed. Unless people are capable, and willing to test for true bitperfect output then these discussions can become pointless as resampling is the most likely culptrit for sound degredation.
 
Jun 4, 2008 at 1:24 PM Post #34 of 41
Quote:

Originally Posted by Brewmaster /img/forum/go_quote.gif
Using ASIO and Foobar with an Auzentech Prelude, there is no change in sound quality by chainging the buffer.

DTS test passes at all settings of the buffer.

The most probable sounding explanation is that there is a software bug that is causing the stream to not be bitperfect as the buffer is changed. Unless people are capable, and willing to test for true bitperfect output then these discussions can become pointless as resampling is the most likely culptrit for sound degredation.




And that would mean ASIO not by-passing Kmixer. It does happen. There are lots of people with their heads in the clouds thinking ASIO=bitperfect. Its like buying a lemonade and thinking it always has real lemons in it. There is no FDA preventing a soundcard manufacturer from selling a crappy ASIO driver.
 
Jun 4, 2008 at 2:43 PM Post #35 of 41
I've only ever heard of ASIO4All going through kmixer, and I don't consider it a true ASIO driver. But ok, let's say that the OP (and others who report the soundstage issue) are all using ASIO4All, and are all going through kmixer. Even then, why would increasing the buffer size make the slightest bit of difference (literally) ?

IMO, if this effect is real, it's a software bug. Kmixer doesn't even resample unless there are multiple streams playing AFAIK.
 
Jun 4, 2008 at 9:02 PM Post #36 of 41
I dunno why everyone has their panties in a bunch over ASIO. It's primarily a driver designed for media production, to get latency levels down. It's not going to have a huge difference on sound quality, compared to say, getting a kickass audio interface.
 
Jun 5, 2008 at 12:18 AM Post #38 of 41
Quote:

Originally Posted by Dodeca /img/forum/go_quote.gif
I dunno why everyone has their panties in a bunch over ASIO. It's primarily a driver designed for media production, to get latency levels down. It's not going to have a huge difference on sound quality, compared to say, getting a kickass audio interface.


It can have a huge difference in sound quality if it allows you to bypass the nasty resampling of audio performed by Windows.

This is actually related to how I started down the slippery slope of headphones. I had an original Audigy at the time and bought a pair of HD 565's. That quickly evolved into why does my digital out from my PC sound so bad, and my Toshiba DVD player sound so good. If it's digital it must sound perfect right?
smily_headphones1.gif
 
Jun 5, 2008 at 1:38 AM Post #39 of 41
Are any of you able to address my clocking question:

Quote:

Originally Posted by skeptic /img/forum/go_quote.gif
While I understand that buffer should have no impact on a "bit perfect" stream of digital data, my question is really whether the buffer might potentially impact clocking/rate of transmission of the data, such that it could possibly impact my perception of sound stage?

There seem to be wide degrees of variation in jitter and proper clocking in spdif signals based on the implementation (and I would assume the X-fi isn't particularly strong in this respect) - does "bit perfect" entail perfect clocking? Is there even such a thing?



Maybe I'm entirely misguided here, but my understanding is that a "bit perfect" signal can exist, with all data present and accounted for, but that timing/clocking issues in the transfer of that data still make a difference in ultimate sq - particularly when processed by an entry level DAC. Isn't this the concept behind jitter filters/reclocking technology?

Is it so hard to believe that buffering (and this may be largely dependent on the individual computer, front side bus, ram speed, cache, pci vs pci-e speed etc...) and other data rates internal to the computer could impact the transfer rates of bit perfect data, so as to create variations which might impact sq?
 
Jun 5, 2008 at 1:39 PM Post #40 of 41
Quote:

Originally Posted by Brewmaster /img/forum/go_quote.gif
It can have a huge difference in sound quality if it allows you to bypass the nasty resampling of audio performed by Windows.

This is actually related to how I started down the slippery slope of headphones. I had an original Audigy at the time and bought a pair of HD 565's. That quickly evolved into why does my digital out from my PC sound so bad, and my Toshiba DVD player sound so good. If it's digital it must sound perfect right?
smily_headphones1.gif




Properly implemented ASIO makes a huge difference in SQ, problem is I estimate half of those on these forums aren't bit-perfect with their ASIO config. So you will have people saying it doesn't make a difference. It does when it is working right.
 
Jun 5, 2008 at 8:18 PM Post #41 of 41
Quote:

Originally Posted by regal /img/forum/go_quote.gif
Properly implemented ASIO makes a huge difference in SQ, problem is I estimate half of those on these forums aren't bit-perfect with their ASIO config. So you will have people saying it doesn't make a difference. It does when it is working right.


It's very easy with the way some of these drivers and software are configured to end up with bitperfect not working. As an example, in the Prelude drivers if the digital input is not muted I lose bitperfect playback.
 

Users who are viewing this thread

Back
Top