IPB

Welcome Guest ( Log In | Register )

3 Pages V   1 2 3 >  
Reply to this topicStart new topic
Windows 7's resampling sucks, How can it be improved?
googlebot
post Feb 9 2011, 20:30
Post #1





Group: Members
Posts: 698
Joined: 6-March 10
Member No.: 78779



Playback over WASAPI must match the sample rate of the output device. Thus applications must supply their own resampling if the playback rate does not match. Most applications don't do this but just employ MME or DirectSound, which provide transparent resampling for non-matching rates.

Since some of my content is 44.1 kHz and some 48 kHz I used to set the output rate to 192 kHz so that all audio had to be upsampled. With good software resampling and a cheap onboard codec this could, in theory, even improve the overall result. But the opposite was true. Today I couldn't longer ignore the impression that the resampled output sounded somewhat muffled and did some measurements.

You can view the result here. The upsampled output (44.1 -> 192 kHz) suffers from quite a HF roll-off in comparison to pure 44.1 kHz output.

In Windows XP the SRC quality could be adjusted. I can't find anything comparable in Windows 7. Does anyone know more?

This post has been edited by googlebot: Feb 9 2011, 20:33
Go to the top of the page
+Quote Post
[JAZ]
post Feb 9 2011, 20:41
Post #2





Group: Members
Posts: 1772
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



A) WASAPI doesn't force any player to resample. One has to resample only if it uses exclusive mode, and if it uses exclusive mode it's for a reason, not for the operating system to do the work for you.

B) The frequency that is set in the device configuration is precisely the samplerate at which it operates the final mix (if not in exclusive mode), and as such, the sampling rate at which other sources get resampled.

C) I have no idea what you've supposedly done, but let me be doubtful that simply upsampling causes the effect you show (which isn't as big as you try to suggest. It's 7dB! )

D) Please, consider using adequate words in this forum. "This sucks" or "This 0wns" are not adequate words.
Go to the top of the page
+Quote Post
googlebot
post Feb 9 2011, 21:14
Post #3





Group: Members
Posts: 698
Joined: 6-March 10
Member No.: 78779



QUOTE ([JAZ] @ Feb 9 2011, 20:41) *

A) WASAPI doesn't force any player to resample. One has to resample only if it uses exclusive mode, and if it uses exclusive mode it's for a reason, not for the operating system to do the work for you.


Please don't try to educate me when you're missing the facts. You couldn't have misrepresented them any worse. Shared mode WASAPI doesn't provide SRC, applications have to provide it themselves. A quick Google search delivers this, for example, a blog post by one of the developers of WASAPI, Larry Osterman. MSDN has more information, but you can search yourself. You also misunderstand exclusive mode. It does neither provide SRC, but it also isn't needed since in exclusive mode the application can directly set the endpoint device's sample rate.

QUOTE ([JAZ] @ Feb 9 2011, 20:41) *

B) The frequency that is set in the device configuration is precisely the samplerate at which it operates the final mix (if not in exclusive mode), and as such, the sampling rate at which other sources get resampled.


I haven't written anything to the contrary. I was just more precise, transparent resampling only happens via DirectSound and MME.

QUOTE ([JAZ] @ Feb 9 2011, 20:41) *

C) I have no idea what you've supposedly done, but let me be doubtful that simply upsampling causes the effect you show


RMAA output was captured two times by a Macbook Pro with a sample rate of 96 kHz. One time the output rate on the Windows 7 computer was set to 192 kHz, the second time to 44.1 kHz. The plot is from RMAA's 'analyze' function applied to the captured recording.

QUOTE ([JAZ] @ Feb 9 2011, 20:41) *

(which isn't as big as you try to suggest. It's 7dB! )


If 7dB, more than twice as loud, isn't much for you I can't help. I also read the plot differently. The difference is at most 2dB, where it matters, which admittedly isn't much. But at times when even free onboard codecs deliver exceptional performance, the OS shouldn't mess this up without a reason.

QUOTE ([JAZ] @ Feb 9 2011, 20:41) *

D) Please, consider using adequate words in this forum. "This sucks" or "This 0wns" are not adequate words.


Please consider using adequate facts in this forum. Posting completely opposite nonsense is not adequate information.

This post has been edited by googlebot: Feb 9 2011, 21:30
Go to the top of the page
+Quote Post
saratoga
post Feb 9 2011, 21:56
Post #4





Group: Members
Posts: 4907
Joined: 2-September 02
Member No.: 3264



QUOTE (googlebot @ Feb 9 2011, 14:30) *
Since some of my content is 44.1 kHz and some 48 kHz I used to set the output rate to 192 kHz so that all audio had to be upsampled. With good software resampling and a cheap onboard codec this could, in theory, even improve the overall result. But the opposite was true. Today I couldn't longer ignore the impression that the resampled output sounded somewhat muffled and did some measurements.

You can view the result here. The upsampled output (44.1 -> 192 kHz) suffers from quite a HF roll-off in comparison to pure 44.1 kHz output.



Were you able to ABX that? 1dB of rolloff at 17kHz seems like it would be difficult enough with test tones, let alone real music.
Go to the top of the page
+Quote Post
googlebot
post Feb 9 2011, 22:11
Post #5





Group: Members
Posts: 698
Joined: 6-March 10
Member No.: 78779



It's hard to ABX the different paths directly against each other and I didn't do that. I had an impression and did the measurement because of it. A lot of experimental electronic (noise) music fills my playlists, which is quite sensitive w.r.t. missing HF headroom. But 1-2 dB indeed isn't much, I'll try a formal ABX later this week. I think it should be doable.

I could also post the RMAA test recordings. But they are over 50 MB each, uncompressed.

PS Windows 7 (and Vista) has a fantastic audio sub system in every respect: mixing, latency, comfort, performance, and developer APIs. IMHO even better than Apple's Core Audio. I was just somewhat pissed to find such a regression behind XP at this end: choose a cheap default and even remove the option to improve it. But maybe it's still there and someone else can point me to it.

PS to my last post: The sample rate of RMAA was set to 44.1 kHz both times.

This post has been edited by googlebot: Feb 9 2011, 23:03
Go to the top of the page
+Quote Post
Roseval
post Feb 9 2011, 23:04
Post #6





Group: Members
Posts: 476
Joined: 26-March 08
Member No.: 52303



WASAPI in exclusive mode send the output straight to the audio driver.
It is up to the programmer to match the driver with sample rate, bit depth and channels of the source or to match the source with the capabilities of the driver

WASAPI in shared mode sends the output to the audio engine. The audio engine will match the source with the capabilities of the driver and will resample to the settings in the audio panel.
http://thewelltemperedcomputer.com/SW/Wind...7/Win7Audio.htm

According to dCs, the SRC in Vista is not perfect: http://thewelltemperedcomputer.com/Lib/Ope...SampleRates.pdf



--------------------
TheWellTemperedComputer.com
Go to the top of the page
+Quote Post
googlebot
post Feb 9 2011, 23:11
Post #7





Group: Members
Posts: 698
Joined: 6-March 10
Member No.: 78779



QUOTE (Roseval @ Feb 9 2011, 23:04) *
WASAPI in shared mode sends the output to the audio engine. The audio engine will match the source with the capabilities of the driver and will resample to the settings in the audio panel.


The audio engine is responsible for mixing. When a shared WASAPI source has a non matching sample rate, it cannot use the engine. Your references do not say otherwise.

User-Mode Audio Components (MSDN):

QUOTE
In exclusive mode, the client can choose to open the stream in any audio format that the endpoint device supports. In shared mode, the client must open the stream in the mix format that is currently in use by the audio engine (or a format that is similar to the mix format). The audio engine's input streams and the output mix from the engine are all in this format.


This post has been edited by googlebot: Feb 9 2011, 23:17
Go to the top of the page
+Quote Post
Cavaille
post Feb 9 2011, 23:43
Post #8





Group: Members
Posts: 391
Joined: 20-May 06
Member No.: 30963



QUOTE ([JAZ] @ Feb 9 2011, 20:41) *
D) Please, consider using adequate words in this forum. "This sucks" or "This 0wns" are not adequate words.

This is not to be meant in any way harmful but since when did this forum become snotty? Besides, he didn´t attack a person, he "insulted" a resampling engine. Which is another matter IMO. IF he would have attacked a person, then I´d write the sentence you wrote, JAZ. Now you can write "Oh, but he attacked the programmer of this resampling engine." Well, in that case... people from Microsoft got used to it over the years, won´t you say?

QUOTE (saratoga @ Feb 9 2011, 21:56) *
Were you able to ABX that? 1dB of rolloff at 17kHz seems like it would be difficult enough with test tones, let alone real music.

I waited for exactly that sentence upon first reading the original post. I mean, we ABX a lot - mp3 for example. Numerous tests around here have shown that people cannot percept missing frequencies above roughly 15 kHz. I´m afraid this thread will get sorted into the "mp3-bashing-audiophile-snake-oil" sort.

QUOTE (googlebot @ Feb 9 2011, 23:11) *
QUOTE
In exclusive mode, the client can choose to open the stream in any audio format that the endpoint device supports. In shared mode, the client must open the stream in the mix format that is currently in use by the audio engine (or a format that is similar to the mix format). The audio engine's input streams and the output mix from the engine are all in this format.

Exactly. Figuratively speaking, WASAPI is nothing more but a revamped XP Audio Kernel with a few added traits ASIO had established.

To get back to the original post, I find it disturbing that Windows 7 actually resamples that bad. I always was under the impression that the resampling improved from XP to 7. Guess I was wrong. Have you measured any other things beside frequency response? Thinks like distortions? I wouldn´t be surprised if something gets aliased back into the audible range.


--------------------
marlene-d.blogspot.com
Go to the top of the page
+Quote Post
[JAZ]
post Feb 9 2011, 23:49
Post #9





Group: Members
Posts: 1772
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



Are you telling me that when I have set 24bits 96Khz in Sounds, and use Wasapi output in foobar2000 to play a 44Khz file, the wasapi driver in foobar is doing its own resampling to 96Khz without me knowing it?

The post you gave is from 2005, and as it can be read in it, not even beta 2 of Windows Vista was released. Also, it is not explicit if he was talking about Wasapi in general, or specifically about exclusive mode. (Or even if exclusive mode was the only mode that was to be made available at that time)

Oh, and btw, i know what WASAPI exclusive mode is. I'm developing an output driver for my application which uses that.


I still don't understand how did you do that.


Win 192 -> analog(?) -> OSX 96Khz -> something -> RMAA 44Khz
Win 44 -> analog(?) -> OSX 96Khz -> something -> RMAA 44Khz

QUOTE
The difference is at most 2dB, where it matters,
So... where it matters is at 18Khz? If you say so...

This post has been edited by [JAZ]: Feb 9 2011, 23:55
Go to the top of the page
+Quote Post
C.R.Helmrich
post Feb 9 2011, 23:50
Post #10





Group: Developer
Posts: 686
Joined: 6-December 08
From: Erlangen Germany
Member No.: 64012



http://www.hydrogenaudio.org/forums/index....st&p=693667

Surprisingly related. And surprisingly, low-frequency artifacts are created, at least when when resampling from 44.1 to 48 kHz (the default setting on my Windows 7 installation). Can you confirm this for 192 kHz?

Edit: Hmmm, only "sucks" when using the "Microsoft Sound Mapper", or "Wave Mapper", or however it may be called, as output device.

Chris

This post has been edited by C.R.Helmrich: Feb 10 2011, 00:08


--------------------
If I don't reply to your reply, it means I agree with you.
Go to the top of the page
+Quote Post
SCOTU
post Feb 9 2011, 23:51
Post #11





Group: Members
Posts: 118
Joined: 9-July 10
Member No.: 82156



Is there any reason the OS' resampling even matters? If it's bothersome to hear, or even from a "I know _____ and it bothers me", then anything worth listening to w/o that "problem" can simply be played through a player that performs its own resampling. Virtually every player lets you do this, probably with something good enough that isn't complainable. Who cares if your windows sounds or some crappy youtube vid has been upsampled and has a high range falloff? If it only matters for music and videos, just resample in your player if you absolutely cannot stand something in the OS.

tl;dr: If you don't like one thing's way of doing something, use what you believe to be a better version of it.
Go to the top of the page
+Quote Post
soulsearchingsun
post Feb 9 2011, 23:56
Post #12





Group: Members
Posts: 145
Joined: 27-January 05
Member No.: 19370



Did you take the effects of different recontruction low pass filters into account?

A few months ago I went through some datasheets of audio codecs (just out of curiosity) and discovered some plots that showed this behavoir. This was the case with one or two low cost chips. As most of the filtering is done in the digital domain (hopefully FIR) they may not have used enough coefficients to make steep filters at those rates.
I may be totally wrong on this, though.

Concerning the original problem:
Resampling, done right, shouldnt hurt. If there is no content beyond 48kHz, use this as sampling rate. 44.1kHz content will be resampled, either by your player, or by windows. I'm pretty confident the results won't be that significant (for measuring, that is) as the ones you posted.
Go to the top of the page
+Quote Post
googlebot
post Feb 10 2011, 00:07
Post #13





Group: Members
Posts: 698
Joined: 6-March 10
Member No.: 78779



QUOTE ([JAZ] @ Feb 9 2011, 23:49) *

Are you telling me that when I have set 24bits 96Khz in Sounds, and use Wasapi output in foobar2000 to play a 44Khz file, the wasapi driver in foobar is doing its own resampling to 96Khz without me knowing it?

The post you gave is from 2005, and as it can be read in it, not even beta 2 of Windows Vista was released. Also, it is not explicit if he was talking about Wasapi in general, or specifically about exclusive mode. (Or even if exclusive mode was the only mode that was to be made available at that time)


I posted a link to the current MSDN documentation an it is telling you exactly that.

QUOTE ([JAZ] @ Feb 9 2011, 23:49) *

Oh, and btw, i know what WASAPI exclusive mode is. I'm developing an output driver for my application which uses that.


Then I wonder how you can write sentences like "One has to resample only if it uses exclusive mode", which is simply false according to the past and current developer documentation.

QUOTE ([JAZ] @ Feb 9 2011, 23:49) *

I still don't understand how did you do that.

Win 192 -> analog(?) -> OSX 96Khz -> something -> RMAA 44Khz
Win 44 -> analog(?) -> OSX 96Khz -> something -> RMAA 44Khz


It's really no black magic:

RMAA (44.1 kHz) -> DirectSound -> DA (44.1 kHz) -> Line Out (PC) -> Line In (Mac) -> AD (96 kHz) -> WAV -> RMAA Analyzer
RMAA (44.1 kHz) -> DirectSound -> DA ( 192 kHz) -> Line Out (PC) -> Line In (Mac) -> AD (96 kHz) -> WAV -> RMAA Analyzer


QUOTE (Cavaille @ Feb 9 2011, 23:43) *
Figuratively speaking, WASAPI is nothing more but a revamped XP Audio Kernel with a few added traits ASIO had established.


How do you base such claims. The audio system has undergone a huge rewrite. ASIO isn't faster than WaveRT and there is a nice, modular architecture for any additionally needed features.

This post has been edited by googlebot: Feb 10 2011, 00:28
Go to the top of the page
+Quote Post
db1989
post Feb 10 2011, 00:10
Post #14





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



QUOTE (Cavaille @ Feb 9 2011, 22:43) *
QUOTE (saratoga @ Feb 9 2011, 21:56) *
Were you able to ABX that? 1dB of rolloff at 17kHz seems like it would be difficult enough with test tones, let alone real music.
I waited for exactly that sentence upon first reading the original post. I mean, we ABX a lot - mp3 for example. Numerous tests around here have shown that people cannot percept missing frequencies above roughly 15 kHz. I´m afraid this thread will get sorted into the "mp3-bashing-audiophile-snake-oil" sort.
While it's preferable that audibility should be verified, in contrast to MP3 technologies such as resampling should not (for lack of a better phrase) mess around with the audio (the frequencies they preserve), so isn't there some merit to reporting deficiencies like these, regardless of audibility? Then it wouldn't be a case of saying "This sounds worse/awful", just "This has been subjected to sub-par processing".
Go to the top of the page
+Quote Post
googlebot
post Feb 10 2011, 00:25
Post #15





Group: Members
Posts: 698
Joined: 6-March 10
Member No.: 78779



I'll be away until tomorrow night. If you guys come to the conclusion that I just wrote a bunch of BS, so be it. If you need additional basis for claims in whatever direction, here you go:

These are links to the two RMAA recordings on Rapidshare. I enabled Trafficshare mode, so you don't need to register to download with full speed:

http://r apidshare.com/files/447079428/441192.wav
http://r apidshare.com/files/447078121/441.wav

Even compressed they wouldn't have fit into my upload contingent, so please excuse the system circumvention and feel free to move the files.

PS The RMAA analyzer will show insane IMD errors for both files. That's because it tries to deduce the tested sample rate from the file's sample rate. FR measurements aren't affected, though. When you resample to 44.1 kHz before scanning, IMD will look normal.

This post has been edited by googlebot: Feb 10 2011, 00:44
Go to the top of the page
+Quote Post
GeSomeone
post Feb 10 2011, 00:42
Post #16





Group: Members
Posts: 921
Joined: 22-October 01
From: the Netherlands
Member No.: 335



@googlebot , I do not fully understand why you're so sure it is a Windows 7 thing, couldn't it be the hardware (@192kHz)? Unless you meant to say you tested the same hardware with Windows XP. Also the device driver will be different, of course.

I think you should really try 44.1 -> 96kHz and check if that is OK.
Go to the top of the page
+Quote Post
Cavaille
post Feb 10 2011, 00:47
Post #17





Group: Members
Posts: 391
Joined: 20-May 06
Member No.: 30963



QUOTE (googlebot @ Feb 10 2011, 00:07) *
How do you base such claims. The audio system has undergone a huge rewrite. ASIO isn't faster than WaveRT and there is a nice, modular architecture for any additionally needed features.
I wrote "figuratively speaking". This wasn´t in any way meant as criticism. Compared to XP it has improved very much. But it cannot be ignored that they included "Exclusive Mode" for people who need it (e.g. people who need low latency). The people who formerly used ASIO for that reason (or may still be using it). IMO, Microsoft wanted a piece of the "audio-production-cookie". Granted, that´s guessing.


QUOTE (dv1989 @ Feb 10 2011, 00:10) *
While it's preferable that audibility should be verified, in contrast to MP3 technologies such as resampling should not (for lack of a better phrase) mess around with the audio (the frequencies they preserve), so isn't there some merit to reporting deficiencies like these, regardless of audibility? Then it wouldn't be a case of saying "This sounds worse/awful", just "This has been subjected to sub-par processing".
Yes, I meant exactly that. I´m all for making something like this known so that it can be avoided. I only fear that this - in my eyes - important thread will vanish because of the usual "you can´t hear it anyway if frequencies beyond 15 kHz are missing". I wanted to write that googlebot was fighting windmills but I thought it to be insulting to the others so I didn´t. Well, now I did and so I should have clarified my point.


--------------------
marlene-d.blogspot.com
Go to the top of the page
+Quote Post
googlebot
post Feb 10 2011, 00:50
Post #18





Group: Members
Posts: 698
Joined: 6-March 10
Member No.: 78779



@GeSomeone That's possible. It didn't test this since the 192 kHz -> 192 kHz loop-back test was nice and flat (better than -0.5 dB at 50 kHz). I'm going to give it a try tomorrow. But you are right, maybe all this is just about my hardware.

I gotta go now, don't wanna upset the sandman. wink.gif

This post has been edited by googlebot: Feb 10 2011, 00:56
Go to the top of the page
+Quote Post
SebastianG
post Feb 10 2011, 11:28
Post #19





Group: Developer
Posts: 1317
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



I also don't think -1 dB at 17 kHz and -3 dB at 18.25 kHz makes a difference in real listening situations. The early and slow rolloff has also advantages in theory (possibly lower delay, computationally cheaper).
Go to the top of the page
+Quote Post
soulsearchingsun
post Feb 10 2011, 11:45
Post #20





Group: Members
Posts: 145
Joined: 27-January 05
Member No.: 19370



QUOTE (soulsearchingsun @ Feb 9 2011, 23:56) *
Did you take the effects of different recontruction low pass filters into account?

QUOTE (googlebot @ Feb 10 2011, 00:50) *
[...] the 192 kHz -> 192 kHz loop-back test was nice and flat (better than -0.5 dB at 50 kHz).

My point is invalid then.
Go to the top of the page
+Quote Post
Notat
post Feb 10 2011, 16:43
Post #21





Group: Members
Posts: 581
Joined: 17-August 09
Member No.: 72373



QUOTE (SebastianG @ Feb 10 2011, 03:28) *
I also don't think -1 dB at 17 kHz and -3 dB at 18.25 kHz makes a difference in real listening situations. The early and slow rolloff has also advantages in theory (possibly lower delay, computationally cheaper).

Such anti-aliasing filtering is necessary in a sample-rate and digital-to-analog conversion. As Sebastian indicates, there are trade offs in filter design. You are comparing Microsoft's software filter to the hardware filter in the DAC. They are implemented differently and it is not surprising that you can measure and hear a difference. Have you done any measurements on XP to confirm that there's a regression in Win 7. I would not assume that removal of user settings implies reduced performance. It could alternatively mean that overall performance was improved to the extent that user settings are no longer necessary.
Go to the top of the page
+Quote Post
googlebot
post Feb 10 2011, 20:46
Post #22





Group: Members
Posts: 698
Joined: 6-March 10
Member No.: 78779



I am well familiar with the technical details of resampling. There recently was an interesting discussion about reconstruction filters, where I participated, for example.

QUOTE (Notat @ Feb 10 2011, 16:43) *
Have you done any measurements on XP to confirm that there's a regression in Win 7. I would not assume that removal of user settings implies reduced performance. It could alternatively mean that overall performance was improved to the extent that user settings are no longer necessary.


I remembered that Microsoft had claimed for the "best" setting to use a high-end polyphase filter in XP. It took me a while to dig up some reference. And after reading that what Microsoft used to call the "good" setting was simple linear interpolation, I think you have a point and they might just have removed the ultra-low-level options. From the measurements it is pretty clear that Windows 7 does not use linear interpolation anymore and they might have just kept the former "better" or "best" option.*

Still, anti-aliasing is not just a trade-off between pass-band quality and filter steepness. Both can be maximized at the cost of a third variable: CPU cycles. Compared to the vast power of even 5 year old commodity CPUs, Windows 7's frequency roll-off really is a little lame (it's not a phone OS). Music playback doesn't need a lot of resources on modern CPU's. Most of the time can be spent in the lower C states and the long pipelines must regularly flush without ever truly filling. In such a low usage scenario a little higher software utilization can often free-ride just by higher pipeline utilization. I certainly wouldn't mind having the option of not 99,9% but 100% transparency, without a limitation to what the majority would call normal music. Not because the difference would be so huge, but because of missing necessity. If a difference with whatever signal, even if can't be considered normal music, can be perceived, and CPU cycles are superabundant, then why be apologetic about it?

* I'm not planning to re-install XP just to get confirmation.

One more comment shared WASAPI: even shared WASAPI can switch the output sample rate to a rate different from the user-chosen, preferred output sample rate, when there are no conflicting streams. In such a scenario a shared WASAPI implementation can output audio without an application level resampler (you end up with no resampling at all). But such an implementation would be incomplete and throw an error, when you try to playback while a conflicting stream or system sound would occupy the engine with another sample rate. Even if the occupying source would also use shared mode.

This post has been edited by googlebot: Feb 10 2011, 20:58
Go to the top of the page
+Quote Post
lvqcl
post Feb 10 2011, 22:17
Post #23





Group: Developer
Posts: 3358
Joined: 2-December 07
Member No.: 49183



http://blogs.msdn.com/b/matthew_van_eerde/...-pull-mode.aspx
http://blogs.msdn.com/b/matthew_van_eerde/...t-you-hear.aspx

Is it possible to test Vista/Win7 SRC quality with this small app? If yes, then 192->44.1kHz or 44.1->192kHz SRC isn't that bad...


Go to the top of the page
+Quote Post
googlebot
post Feb 10 2011, 23:32
Post #24





Group: Members
Posts: 698
Joined: 6-March 10
Member No.: 78779



Interesting. Looks like it should, just not like what I get.

This post has been edited by googlebot: Feb 10 2011, 23:32
Go to the top of the page
+Quote Post
googlebot
post Feb 11 2011, 00:00
Post #25





Group: Members
Posts: 698
Joined: 6-March 10
Member No.: 78779



QUOTE (GeSomeone @ Feb 10 2011, 00:42) *
I think you should really try 44.1 -> 96kHz and check if that is OK.


You nailed it, thank you very much! I just tested exactly that and probably would not have tried without your suggestion. At 96 kHz the output is flat to -0.3 dB at 20 kHz! ohmy.gif

But I'm totally clueless right now why this is happening. As said, the 192 kHz loop-back test is flat up to over 50 kHz. If I playback 44.1 kHz with the same setting the roll-off is there. Same 44.1 kHz playback over a 96 kHz output sample rate: perfect.

The codec is an ALC889, driver version 6.0.1.6201.

This post has been edited by googlebot: Feb 11 2011, 00:06
Go to the top of the page
+Quote Post

3 Pages V   1 2 3 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd August 2014 - 17:44