Artifacts on Windows 7 due to sample rate conversion. (slightly OT) RRS feed

  • General discussion

  • I am not developing anything, so I apologise for this off topic post. Nevertheless, I think/hope that the problem I am experiencing is relevant to this forum. 

    On Windows 7, if the sample rate of the audio interface is set to a different rate to that of the audio in the YouTube clip, artifacts may be audible.

    For example, if the audio interface is set to a sample rate of 48kHz, and the following test tone clip is played, I hear aliasing:  http://www.youtube.com/watch?v=KGlCdZ0j2FQ

    If I change my audio interface to 44.1kHz, the aliasing goes away (and the sound is very pure)

    I have tried this test with both the internal audio interface, and a high quality USB audio interface, with the same result.
    For the internal audio interface, I change the sample rate (and format) via the Advanced properties of the Playback device.
    For the external interface, which has it's own control panel, I set the sample rate in that control panel, and then in the Windows playback properties I can only change the format. (i.e, Windows only allows the bit depth & channels to be changed - not the sample rate)

    System details:
    Toshiba NB300 netbook, Windows 7 Starter.

    There is some prior discussion of this issue at this blog:

    According to a user there, the problem occurs if the application uses the WaveOut API. Directsound works fine.

    If YouTube (via the Adobe FLASH player, yes?) is using WaveOut, is it possible to configure it to use Directsound instead?

    I am unable to make Windows XP produce any noticable aliasing. I am testing this on XP by opening TWO applications simultaneously, so that XP locks the sample rate of the hardware to the rate that the first application requested. Otherwise, XP seems to change the sample rate according to the content. So, on XP, if I open an application that requests 48kHz, and then open an application that requests 44.1kHz, and play a test tone from the second one using WaveOut, I do not hear any aliasing, even when XP's "sample rate conversion quality" is set to the LOWEST quality setting.  I am quite sure the sample rate of the hardware remains steady on 48kHz for the duration of the test, because I am using the same USB audio interface that has it's own control panel, and displays the sample rate that is set at any moment in time. (the application that I used for playing the test tone was Winamp, which allows DirectSound or WaveOut to be chosen. On Windows 7, it produces aliasing in the same way that YouTube does, when WaveOut is chosen)


    • Edited by piriton Monday, January 3, 2011 10:26 PM Bad YouTube link
    Monday, January 3, 2011 10:23 PM

All replies

  • The (beta) HTML5 plugin produces the same artifact. (only tested in Chrome so far - I.E doesn't invoke the HTML5 plugin for the clips I am viewing)


    Tuesday, January 4, 2011 8:54 AM
  • Aside from the apps already mentioned in the aforementioned blog, I have encountered the same problem with some more apps:






    Wednesday, January 5, 2011 12:02 PM
  • I may have been wrong about the Inmatrix Zoom Player producing the artifact after a fresh install. Inmatrix say the default is DirectSound. I have attempted to reproduce the problem (by de-installing and re-installing Zoom Player), however the problem did NOT occur until I went in and forced it to use WaveOut.  


    Friday, January 7, 2011 11:37 AM
  • I've done a wipe & reload of Windows 7 Starter Edition (using the Recovery Media), and then inspected the sample rate of the integrated Realtek HD audio interface. It is 48kHz.  This is what I suspected, because I didn't think I had changed the settings before I heard the problem in YouTube.  (I get the impression most YouTube content is encoded at 44.1kHz. Certainly, when I attempted to upload a 48kHz clip, it was converted to 44.1kHz)   

    Note that I can reproduce the problem with the standalone "projector" Adobe FLASH player as well. I have not tested any non-YouTube sites that use FLASH but I assume they'll behave the same.


    Friday, January 7, 2011 4:19 PM
  • Here's some people trying to assess the quality of a software piano product:


    On Windows 7, with the DEFAULT sample rate of 48kHz, it sounds distorted. At 44.1kHz, it sounds great.

    This problem needs URGENT attention IMHO.


    p.s I realise that product is actually for the Mac platform, so it's not the best example, but you know what I mean.

    Saturday, January 8, 2011 12:14 AM
  • Curious... my understanding is that Windows 7 defaults to 44.1 if both 44.1 and 48 kHz are supported by the audio driver.
    Matthew van Eerde
    Saturday, January 8, 2011 1:37 AM
  • Are you using the Realtek audio driver? As an experiment, can you try installing the Microsoft HD Audio class driver and see if that changes anything? http://blogs.msdn.com/b/matthew_van_eerde/archive/2010/08/23/troubleshooting-how-to-install-the-microsoft-hd-audio-class-driver.aspx
    Matthew van Eerde
    Saturday, January 8, 2011 1:46 AM
  • Yes, I am using the Realtek driver.

    The problem occurs on a COMPLETELY seperate audio interface as well, though, being the M-Audio Fast Track Ultra (USB interface). 
    However, I suspect that the default rate using the Fast Track will indeed be 44.1kHz, because, as I said earlier, Windows seems to refuse to allow any sample rate OTHER than what is set in the M-Audio control panel for this device, and I believe that the default sample rate that M-Audio uses is 44.1kHz. (will confirm later)

    Will install that Audio Class driver and report back - thanks.

    Note that the Inmatrix Zoom Player support personnel have reproduced the problem as well. They can hear the artifact, if they select WaveOut for the output renderer. Refer to this post by them: http://forum.inmatrix.com/index.php?showtopic=11609&view=findpost&p=43349


    Saturday, January 8, 2011 2:38 AM
  • The same problem occurs with the HD Audio Class driver. I.e, if the sample rate of the hardware is set to 48kHz, artifacts are audible in  44.1kHz content. (I tested with YouTube).

    However, the class driver defaults to 44.1kHz 16-bit, I think. (I forget what I had it set to before the install, but whatever it was it wasn't 16-bit, so I assume that the class driver install did change the settings. I'm doing a system restore and will report back)

    Given that Windows 7 does not change the hardware config on the fly (like XP used to), I would have thought that a default rate of 48kHz (and 24-bit) would make a LOT more sense, because otherwise 48kHz material will be downsampled to 44.1kHz. (yes?) So, as far as I can see, the default settings that the Realtek driver used (48kHz, 24-bit) made sense. (but what happens if even higher grade material is played? Will I get a warning if Windows is not going to increase the hardware rate above 48kHz, or will it silently downsample to 48kHz? Anyway, a different topic I guess)

    EDIT: the audio interface was set to 44.1kHz 24-bit. So, after the HD Audio Class driver install, the only change that I observed was the bit depth. (24-bit to 16-bit). However, I've repeated the audio class driver install, with the Realtek settings being on 48kHz, 24-bit (the default for my system), and as expected, it was changed to 44.1kHz, 16-bit.


    Saturday, January 8, 2011 3:10 AM
  • Here's another site, selling professional quality audio/music software - Native Instruments. I can hear the problem on their demo tracks.

    For example, go to the Scarbee MM-Bass: http://www.nativeinstruments.com/#/en/products/producer/powered-by-kontakt/scarbee-mm-bass/

    and click on "demo tracks", and then nav forward one track to "Alright Solo". It sounds noticably cleaner when I set my audio interface to 44.kHz than it does on 48kHz.  

    Is there a registry setting for the WaveOut sample rate conversion quality? (if there isn't a setting available in the Windows UI - there doesn't seem to be)


    Saturday, January 8, 2011 6:58 AM
  • I've posted in the Passmark "SoundCheck" forum:  http://www.passmark.com/forum/showthread.php?t=2908

    That utility also fails (on my system, at least) in the same way, if the sample rates do not match. 

    They thought I was half mad for suggesting that the sample rates could possibly not match.  

    Even once this apparent problem with sample rate conversion is addressed, I think I'd still prefer the old Windows XP behaviour, where it automatically reconfigured the interface to match the content, IF POSSIBLE.  Is your sample rate conversion really THAT good? Will it retain every last Hz of bandwidth, and every last bit of detail, of HD content? 


    Saturday, January 8, 2011 10:03 PM
  • I couldn't immediately see how to use the Passmark SoundCheck to actually perform analysis of the soundcard, so I downloaded "Sound Card Analyzer 1.0" from: http://download.cnet.com/Sound-Card-Analyzer/3000-2169_4-10060675.html?tag=contentMain;overviewHead

    As expected, this too doesn't work properly on my Windows 7 system, unless I make sure that the sample rate that is configured in the application matches that set in the Windows properties.  If they don't match, the results are non representative of the hardware capabilities.   For example, I'm able to put in a sample rate of 96000 into the program,  and 44100 into Windows, and the frequency response will be restricted to circa 20kHz (but with a strange spike right up near 48kHz due to resampling artifacts or whatever) I've tried this on both the internal Realtek and the external M-Audio Fast Track Ultra with similar results. Using the Realtek, I could not get the right channel to work, and I could not force the application to only test one channel, however the results appeared as if it may have been ignoring one channel. (I did configure the interface for line-in, rather than mic, but I just couldn't get stereo to work).   Other test results are of course affected by sample rate discrepancies, such as THD. 

    Note that the sound level check pre-test did not work properly when the sample rates did not match. For example, the -6dB test would produce a 0dB input level, which is a huge error.  So, any user of this utility would most likely be alerted to a serious problem before doing the tests proper, which is good. (I did the tests despite this issue)

    The point I'm trying to make is that on XP and earlier, we didn't have to do this crosschecking, and the uninitiated may get into strife because of this change in behaviour.  Was this the INTENDED behaviour, or was the intended behaviour for older apps (that use WaveOut, yes?) to be allowed to open the device in exlusive mode, and automatically change the hardware settings according to the properties that the application requested?


    Monday, January 10, 2011 12:38 AM
  • (have your volume WAY down to begin with, because the tone can be extremely piercing!)

    Interestingly, with the audio interface on 48kHz, the 44.1kHz test actually sounds like it produces a better result than the 48kHz one! :) 

    On XP, I notice that for EITHER tone, the audio interface gets switched to 44.1kHz. So, this might explain why on Windows 7, that the 44.1kHz tone sounds better - it's probably getting downsampled to what appears to be a web (or ActiveX?) standard of 44.1kHz first, and then back up to 48kHz in Windows to match the hardware rate. ;^)  Can anyone confirm this?

    Note that the 44.1kHz result (streaming from the page, with hardware on 48kHz) is better than I would have expected, given how noticable the aliasing is for low frequencies. (such as the test tone in my very first post)

    With the hardware on 44.1kHz, and listening to the 48kHz tone, I think Win7 sounds about the same as XP, but I haven't analysed it very closely.

    When I download the files and test them in Media Player, I haven't really heard any aliasing yet I don't think, which is encouraging. 

    Playing the files locally on XP in Media Player, I am able to hear aliasing, especially when I reduce the sample rate conversion quality setting. It's good to see this control actually working!  Of course, I had to first of all open an application to lock the hardware at a different sample rate to the file being played, because otherwise XP simply changes the hardware rate to match the file.  I haven't closely compared XP's highest setting with Windows 7 yet.

    Monday, January 10, 2011 8:23 AM
  • That Passmark "SoundCheck" program actually does NOT seem to change the sample rate of the hardware on XP either. So I was wrong. I really expected XP to reconfigure the hardware. 

    The RightMark Audio Analyzer does change it though, at least on XP, using MME. I haven't tried other APIs yet  (and I haven't been able to install it on Windows 7 yet - the install barfs)

    Sound Card Analyzer is crashing on XP at the moment, so I don't know whether it changes the hardware sample rate or not on XP yet.


    Monday, January 10, 2011 2:02 PM
  • You're correct that Windows 7's choice of 44.1 as the default (when both 44.1 and 48 are available) results in 48 kHz content being downsampled to 44.1. I believe we actually used 48 kHz as the default during the Windows Vista Beta. We moved to 44.1 under the theory that more content "in the wild" was sampled at 44.1 (e.g., Redbook CDs) than was sampled at 48 (e.g., DVDs) and that using 44.1 as the default would therefore result in fewer SRCs, net. Of course, even better would be to stream in whatever format the content was, and only do an SRC if media of two different sample rates are being played at the same time.
    Matthew van Eerde
    Monday, January 10, 2011 6:06 PM
  • Ok. Thanks for the info Matthew.  In any case, that's not the main issue at the moment. The main reason I came here is to report what I feel is inadequate fidelity in YouTube, and, it seems, other streaming media. (if the sample rates do not match).   I didn't go looking for this problem - I noticed it straight away, when I viewed my first YouTube clip which was normal music.

    I've double checked that my default sample rate is 48kHz on this particular machine, by doing a fresh install using the supplied Recovery Media. (Windows Starter). 

    I apologise if I've mentioned too many issues in this thread. I thought the sample rate setting issue would be very clear cut, but it's not. 

    Maybe I'm making too much of it. Maybe most folks realise that internet audio is often lossily compressed, and not to expect too much. It's bugging me a lot though. ;) The artifacts sound quite unpleasant to me.  It's bad enough for me to feel the need to add a note to anything I would upload, cautioning my listeners to check their sample rate, if they are running Windows 7 (or Vista, I assume). This is silly.


    Monday, January 10, 2011 9:54 PM
  • I've re-tested the Passmark SoundCheck utility.  Thankfully, it is in fact behaving much closer to how I always expected it would behave, on Windows XP.  If the user enters a sample rate into SoundCheck, this sample rate WILL be applied to the hardware, but ONLY if it is a supported rate. If it is not a supported rate, the hardware rate remains unchanged. (it would be nice if Passmark alerted the user whenever an unsupported rate was entered, but that's by the by)

    I also re-tested it on Windows 7. The result is the same - the hardware rate is NEVER changed by SoundCheck. The hardware will remain on the sample rate set in the Windows advanced properties for the audio interface.  I have "Allow applications to take exclusive control of this device", and "Give exclusive mode applications priority" both checked.


    Tuesday, January 11, 2011 2:23 PM
  • First, let me say I appreciate all the hard work you've put into this issue so far.

    Can you play your test tone in the following two configurations, capturing the output of the audio engine both times (this is what we send to the sound card) and then mail me the resulting .wav files to (mateer at microsoft dot com)?

    1. Default audio format on the device is 48 kHz
    2. Default audio format on the device is 44.1 kHz

    To capture the output of the audio engine, you can use this app:


    Play the tone first; then start the capture app; then press Enter to stop the app; finally stop the tone.

    Re: SoundCheck: in Windows 7 you can use "exclusive mode" playback to play to a non-default sample rate (supported rates only, of course.)  I gather that SoundCheck is not doing this.  There's a sample "exclusive mode" player here:


    Matthew van Eerde
    Tuesday, January 11, 2011 5:26 PM
  • Thanks - I'll do that ASAP.  (work is intervening a bit today, but I should be able to get to it within the next 24 hours).

    Note that I would have recorded the output at the outset, if you had said that you could not reproduce the problem. The problem is so obvious to me when playing a low frequency sine wave, that I simply didn't feel it necessary. I would have even given you an analysis of the recording to prove that the signal was being distorted. 

    That's right - SoundCheck does NOT appear to be exploiting exclusive mode, and I will try that example player.


    Tuesday, January 11, 2011 8:51 PM
  • Just in case it helps anyone else, I had to run that loopback capture utility as Administrator, and it only allows a few seconds worth of audio to be captured. So, you have to press <enter> after a few seconds, before the utility terminates automatically, and if it does, it doesn't create any recording file. 

    The recording is created in the same folder that the program resides.


    Wednesday, January 12, 2011 9:20 AM
  • I got RightMark Audio Analyzer installed - the install has to be run as Administrator, that's all.

    It correctly restricts the available sample rates to that which the hardware supports (great!), however it doesn't actually change the sample rate of the hardware. Again, I was able to run the tests with the sample rate discrepancy, with no errors whatsoever, but with the expected adverse results. (e.g, bandwidth of only 20kHz, despite a sample rate of 96kHz being entered into the program)


    Wednesday, January 12, 2011 4:19 PM
  • re: the RightMark testing of the M-Audio Fast Track Ultra, it's interesting that RightMark is able to at least correctly list the available sample rates of the interface, yet Windows (advanced properties) ONLY displays the sample rate that is set in the M-Audio Control Panel.  I have posted a question in the M-Audio forums, asking whether the Windows behaviour is correct/expected. 

    I'm trying to devise a test that proves that RightMark is ALSO not changing the sample rate of the internal RealTek.  I thought this would be easy, by checking the frequency response results, however I'm having trouble getting it to work. 
    EDIT: I realise I reported that I tested with the Sound Card Analyzer program earlier here, but what I did not do was to verify that the frequency response widened if I used a higher sample rate in both SCA and Windows. I'll do that extra test. 

    If anyone knows of a utility that can query the RealTek (HD) and determine it's current sample rate, please advise - thanks.


    Thursday, January 13, 2011 8:35 PM
  • I've made a bit of progress. 

    I have now verified that it is HIGHLY unlikely that the RightMark Audio Analyzer is changing the hardware sample rate of either the M-Audio Fast Track Ultra, or the internal Realtek interface.  Note that I am using the MME interface in RMAA.

    Without being able to monitor the hardware rate of the Realtek, I had to rely on frequency response to verify a discrepancy in sample rates. I wasn't able to get meaningful results from this initially, but I've sorted out the problem and now it's working. (I was not aware that the sample rates for playback and recording were independent, and I was not setting the record sample rate!)

    With ALL sample rates set to 96000 (RMAA, Playback and Recording rates in Windows), a 30kHz test signal can be looped back strongly. 

    If I leave RMAA on 96000, and drop the Playback and Recording rates in Windows to 44100, I do not see any evidence of the 30kHz test tone in the signal level pre-test.  (I always exit out of RMAA inbetween changing sample rates in Windows) 

    There's one remaining bit of doubt, however: does the RMAA actually support devices that have independently controlled output & input channels? It only has one setting for sample rate.

    In any case, it appears that this behaviour appears to be LIKELY due to Windows 7, and not due to a driver problem. It appears that this behaviour may be completely normal & expected in Windows 7.

    EDIT: p.s  I haven't got the exclusive mode sample app to work at all yet. If anyone has a WAV file that is playing using this app, please advise and make available if possible - thanks.

    Thursday, January 13, 2011 11:32 PM
  • Greg, I haven't had time to look into this carefully, but you do need to be very careful when using the Realtek and m-audio devices together under Windows 7.

    Using an asio application, I set up my m-audio Fast Track usb (ie the bottom of range device) to be the record/playback device. If I then open the Windows 7 audio Control Panel and select the "Recording" tab, the m-audio asio driver gives a "sample rate unavailable for this device" error from the supposedly independent of Windows asio high level application. When this occurs depends on the particular audio app - I've been using mainly Wavosaur and Adobe Audition 3.

    Disabling the MME part of the m-audio driver in the Windows Recording tab removes the error. I have been assuming that the metering part of the Win7 recording tab is driven by a small recording application inside Windows 7 and that this is in some way hooking together the MME and asio  drivers. As you can tell, I really don't understand much of this.

    I believe that m-audio are aware of the issue.

    I have posted before here and elsewhere about the fact that I have other problems caused by the Windows 7 Control Panel on some machines and with external audio devices from several manufacturers. I haven't had many replies.


    Friday, January 14, 2011 7:26 AM
  • Thanks Billaboard. 

    I have been testing the onboard Realtek seperately to the M-Audio, and both seem to behave much the same.  That's why I have been testing with two devices, to try and ascertain whether the behaviours I have been observing may be due to characteristics and/or problems with a particular driver, rather than Windows 7. So far, I haven't noticed anything that suggests that the OTHER device is interacting in some way, although I suppose anything is possible. I'll try what you are doing, though, just out of curiousity. I.e, I'll fire up an ASIO app, and see what Windows reports in the Playback and Record advanced properties.  I do know that on XP, I was able to use an ASIO app, whilst at the same time play a tune from iTunes, with both audio sources being mixed - it worked well. I haven't tried that on Windows 7 yet.



    Friday, January 14, 2011 8:00 AM
  • Greg, I may have confused things a bit here. The effect that I refer to above is probably unrelated to whether the Realtek device is in use or disabled.

    Where the two devices appear to affect each other is when I use an AMD-based laptop and a usb1.1 audio interface. There I can trigger horrendous audio glitching on the asio usb audio by disabling the Realtek device or by selecting any except the "Recording" tab in the Win 7 Control Panel. This is, of course the opposite of the other effect. One requires the "Recording" tab selected, the other not. My workaround for this is to insert a usb2 hub before the usb1.1 interface.

    I really would like to know definitively why selecting tabs on the Win 7 Control Panel affects asio audio.

    Friday, January 14, 2011 9:25 AM
  • Ok. I'm not at all convinced that your issues are relevant to mine, so I'm not going to spend any time looking at it just at the moment - at least, not in this thread, unless others disagree with me and think that they ARE related. If you can point me to any existing discussions I might take a look, time permitting, and FWIW. :)

    A reminder of my issues:

    1. (the main one!) Audio artifacts, when the sample rate of the audio interface is set to 48kHz and the content is 44.1kHz. (may affect other sample rate mismatches as well).  Affects streaming media such as YouTube etc. Can also affects applications, apparently when the WaveOut API is used. (no evidence yet of artifacts in mainstream applications such as Media Player and iTunes - I have tested Media Player myself but am relying on a blogger for iTunes result)

    2. The new Vista/Windows 7 audio architecture seems to have affected legacy applications for which the hardware sample rate is important, e.g sound card test programs. In the past, it was typical for these applications to change the hardware rate without any other user intervention. Now, it seems that the user has to ensure that the sample rate is changed in the Windows advanced properties, such that it matches that set in the applications.

    3. Noted the POSSIBILITY of 48kHz audio playing from an ActiveX control on a web page being downsampled to 44.1kHz somewhere along the line. 

    4. Trying to test exclusive mode, to determine whether this mode actually does change the hardware sample rate or not. (I fully expect it to!)


    Friday, January 14, 2011 10:23 AM
  • Greg, You are probably right when you say that your issues are unrelated to mine (only the one that produces sample rate error messages would be relevant anyway), but I would still maintain that you need to be wary with these tests.


    I have just tried loading a 44.1kHz and a 48kHz file into Adobe Audition 3, which is a totally asio application and playing them via the "M-Audio USB" device. The m-audio control panel follows the sample rate of whichever file is being played. This seems as it should be.

    If I play the first YouTube file referenced in your original post, it plays correctly with the m-audio control panel set to 44.1. It sometimes  sounds correct with the panel set to  48, but usually there is what sounds like a machine-gun interruption of the audio.

    Pulling that file down and loading it into  VLC Media Player, I see that it is indeed a 44.1kHz file. Setting the M-Audio to 48kHz makes VLC play it with the same machine-gun effect, set to 44.1 it seems OK. In this case, the M-Audio device seems not to pick up the sample rate and match the file.

    I am a little dubious about the YouTube source file as it never seems to reach the stated  10kHz audio frequency. I'm also not sure that what I'm hearing is aliasing, which, on a sliding audio tone, I would have expected to sound like other tones swooping and diving in the background, rather that this which sounds more like a clocking mismatch.

    Next, I loaded the two files into Adobe Audition 1.5, which is a WDM application. This does not reset the sample rate in the M-Audio Control panel to match the file being played, but the files play at the correct speed, so I assume some sample rate conversion is occurring. I think DirectSound drivers are in use here.

    Then I generated a sliding tone in Audition at a sample rate of 48kHz and played it via Audition 1.5.  With the M-Audio set to 48kHz, it played cleanly, set to 44.1 and I hear the expected swooping sounds of aliasing.

    Not sure if this helps.




    Friday, January 14, 2011 4:38 PM
  • Now you're talking! :) 

    Firstly, I would like to introduce a new, simpler test tone - one that I have created:


    Please do the following:

    1. Close down all audio applications
    2. Ensure that your M-Audio device is your default Playback device, in Windows
    3. In your M-Audio Control Panel, set your sample rate to be 44.1kHz
    4. Go to the Windows advanced properties for your Playback device, and BEFORE you change anything, CAREFULLY note down the format that is currently selected, and report this format to me, whatever it is. 
    5. No matter what format was selected in the Windows properties, change it to 24-bit, 44.1kHz
    6. Go back to your M-Audio C.P, and verify that the sample rate is still on 44.1kHz (if it is NOT 44.1kHz, STOP - that would be extremely strange, and indicates a problem)
    7. Open the test tone link above in a web browser (again: http://www.youtube.com/watch?v=mejO0hV_w80 )
    8. Listen CLOSELY to the tone with the best quality headphones you have, or if you don't have headphones, use the best loudspeakers you have.  Try to remember how it sounds. While it is playing, verify that the sample rate stays on 44.1kHz, in the M-Audio C.P.
    9. Close down the YouTube web page. (no need to close the whole browser)
    10. In the M-Audio C.P, change the sample rate to 48kHz
    11. Go to the Windows advanced properties for your Playback device, and BEFORE you change anything, CAREFULLY note down the format that is currently selected, and report this format to me, whatever it is. 
    12. No matter what format was selected in the Windows properties, change it to 24-bit, 48kHz
    13. Go back to your M-Audio Control Panel, and verify that the sample rate is still on 48kHz (if it is NOT 48kHz, STOP - that would be extremely strange, and indicates a problem)
    14. Open the test tone link above in a web browser (again: http://www.youtube.com/watch?v=mejO0hV_w80 ) and play it again, listening very carefully. Describe any difference, no matter how small, as best you can. Monitor the sample rate in the M-Audio C.P again.

    I'm glad you have mentioned the VLC Player. I have eliminated the VLC Player from all testing for the time being, because it is producing a strange artifact, REGARDLESS of the sample rate settings. Please refer to this thread for details:  http://forum.videolan.org/viewtopic.php?f=14&t=85921  To save you a bit of time, it seems that the Videolan folks have reproduced the problem I reported, and they think it's something to do with sample rate conversion, but this could be the sample rate conversion in the VLC Player - not Windows. I am waiting for them to get back to me. 



    Friday, January 14, 2011 8:47 PM
  • Now you're talking! :) 

    Firstly, I would like to introduce a new, simpler test tone - one that I have created:


    Please do the following:

    1. Close down all audio applications
    2. Ensure that your M-Audio device is your default Playback device, in Windows
    3. In your M-Audio Control Panel, set your sample rate to be 44.1kHz
    4. Go to the Windows advanced properties for your Playback device, and BEFORE you change anything, CAREFULLY note down the format that is currently selected, and report this format to me, whatever it is. 
    5. No matter what format was selected in the Windows properties, change it to 24-bit, 44.1kHz
    6. Go back to your M-Audio C.P, and verify that the sample rate is still on 44.1kHz (if it is NOT 44.1kHz, STOP - that would be extremely strange, and indicates a problem)
    7. Open the test tone link above in a web browser (again: http://www.youtube.com/watch?v=mejO0hV_w80  )
    8. Listen CLOSELY to the tone with the best quality headphones you have, or if you don't have headphones, use the best loudspeakers you have.  Try to remember how it sounds. While it is playing, verify that the sample rate stays on 44.1kHz, in the M-Audio C.P.
    9. Close down the YouTube web page. (no need to close the whole browser)
    10. In the M-Audio C.P, change the sample rate to 48kHz
    11. Go to the Windows advanced properties for your Playback device, and BEFORE you change anything, CAREFULLY note down the format that is currently selected, and report this format to me, whatever it is. 
    12. No matter what format was selected in the Windows properties, change it to 24-bit, 48kHz
    13. Go back to your M-Audio Control Panel, and verify that the sample rate is still on 48kHz (if it is NOT 48kHz, STOP - that would be extremely strange, and indicates a problem)
    14. Open the test tone link above in a web browser (again: http://www.youtube.com/watch?v=mejO0hV_w80  ) and play it again, listening very carefully. Describe any difference, no matter how small, as best you can. Monitor the sample rate in the M-Audio C.P again.

    I'm glad you have mentioned the VLC Player. I have eliminated the VLC Player from all testing for the time being, because it is producing a strange artifact, REGARDLESS of the sample rate settings. Please refer to this thread for details:  http://forum.videolan.org/viewtopic.php?f=14&t=85921   To save you a bit of time, it seems that the Videolan folks have reproduced the problem I reported, and they think it's something to do with sample rate conversion, but this could be the sample rate conversion in the VLC Player - not Windows. I am waiting for them to get back to me. 




    1. all audio apps closed.

    2. M-Audio device is the default, and is a usb 1.1 device connected via a usb2 hub. Machine AMD-based dual core laptop. The browser is Firefox. Realtek analog audio enabled but not default, Realtek Digital O/P disabled.

    3. M-Audio sample rate set to 44.1

    4. 44.1, 24-bit stereo. both exclusive mode boxes ticked

    5. No change needed

    6. Sample rate still 44.1

    7. File opened in second tab of browser.

    8. Sound is clean LF tone with very occasional clicks. These are almost certainly due to the usb/wifi on same interrupt problem that is the bane of cheap bios-limited laptops on Windows 7 and urgently needs to be addressed (not sure who by, but Microsoft would be a start). Sample rate remains on 44.1 everywhere.

    9. Web page closed by closing tab.

    10. M-Audio C.P. sample rate set to 48kHz

    11. Format is 48kHz 24-bit.

    12. No change needed.

    13. M-Audio sample rate still 48

    14. Test file opened and allowed to load. Sample rate remains at 48kHz

    Play test tone, still sounds as above. On starting the play the M-Audio CP changed to 44.1kHz and said "Streaming 44.1kHz". The Windows 7 CP remained at 48kHz. Closing and reopening Windows CP makes no difference. However, the pull down options now include and allow me to change to 44.1.


    This seems to be different from what I saw yesterday, but that may have been because yesterday I had an asio app open at the same time. Or it might be because yesterday's test file was an mp4, today's is an flv.   

    Edit: Just tested with the mp4 file and it behaves the same as the flv, so it's not that.


    I hope you are going to write the definitive guide to all this when you figure it out.

    Saturday, January 15, 2011 12:06 PM
  • Thanks for doing all that - much appreciated.  What a mess. ;^)

    Can you repeat the test, but use the onboard Realtek? Try 44.1kHz and 48kHz. (of course, you won't be able to monitor the sample rate, other than watching the Windows CP) I am very curious to know whether the artifacts are occurring on your system in any situation.

    It is VERY interesting how your device seems to have automatically switched to 44.1kHz when you started to play the clip!! That's how mine behaves on XP, but not Windows 7. (of course, I am assuming that the M-Audio Control Panel always displays the current sample rate correctly)

    It is also very interesting how you have seen more than one sample rate available in your Windows control panel. I haven't seen that yet. (at least, not for the M-Audio)

    I have only tested I.E and Chrome - I will retest using Firefox.

    I hope Microsoft writes the definitive guide. ;^)


    Saturday, January 15, 2011 12:48 PM
  • I've tried the test tone again using the M-Audio FTU, but with the onboard Realtek completely disabled in the Device Manager. (I rebooted for good measure).

    I still hear artifacts at 48kHz.

    Installing Win7 Ultimate on an old P4 machine that has an onboard Realtek AC'97, and a PCI based M-Audio Delta 66. 


    Saturday, January 15, 2011 3:04 PM
  • I keep being interrupted, so tests are a little sporadic, but I've set the Realtek as the default device, opened the Realtek Control Panel where I can set the default sampling rate. The Windows Control Panel appears to follow this.

    It came up initially as 48kHz 24 bit. The 100Hz test file played cleanly, and the Windows C.P stays set to 48kHz, with the file appearing to  play cleanly. Switch the Realtek CP to default 44.1kHz. The Windows CP doesn't update to 44.1, but does if I close and reopen it. The file again plays cleanly.

    This was with the M-Audio device unplugged. Connecting the M-Audio device made no difference when the Realtek was set as default. Just for interest, I then opened an asio application and set the sample rate in that. After a short time juggling sample rates, I got error messages about sample rates, and then the M-Audio device became "unavailable". To recover, I had to restart the machine. None of this was much of a surprise, although I am rather surprised that the Realtek didn't seem to pick up the sample rate from the file.


    Saturday, January 15, 2011 3:14 PM
  • Thanks again Billaboard.

    Yes, I can see that there IS a place in the Realtek Control Panel where the default sampling rate can be set. I wasn't aware of that. 

    I am not surprised that the Realtek did not "pick up the sample rate from the file" (it's not really a "file" though - it's a YouTube clip playing in a browser). My understanding is that this is how Windows 7 (and Vista) works - all audio is mixed to a common sampling rate - the rate that is set for the device in use. I AM surprised that it changed when you were using the M-Audio.

    I want to upload a recording of the artifact, to make sure you can actually hear it. Over on that VLC player forum thread, they could not hear the problem initially,  and I had to actually prove to them that there was a problem by showing them a spectral view of the problematic recording.  Once I did that, it seemed that they made a special effort to hear it, and they could. (and I know they can hear it, because their description matches my own perception of the artifact) 

    p.s I have a bad DIMM on the P4, which means only 512MB available, which seems to be preventing the Win7 installer from working at all. Will try on a Compaq NW8000 Pentium M laptop instead. Not sure how I'll go with drivers.

    Saturday, January 15, 2011 6:31 PM
  • Here is a recording of the artifact, present when I play that same 100Hz test tone:


    It was created by recording the S/PDIF output of the Fast Track Ultra, on a second computer. The FTU was configured for Internal clocking, which means that the recording computer used the FTU's sample clock.

    Billaboard, if you want to play this recording, please download it and play it back using the Windows Media Player. It's a 48kHz recording, so please set all your sample rates to 48kHz, just to minimise the chances of any sample rate conversion being performed.

    If you can't hear anything unusual, I've found that when I play it back on my laptop speakers, which are tiny, I ONLY hear the artifact - not the 100Hz tone. ;^)

    I'm sorry to put you through this!


    Saturday, January 15, 2011 7:26 PM
  • Greg, Yes, I can see and hear that. As far as I can tell, I haven't heard that here today on the tests I have been doing.

    What worries me is that I did have some strange effects previously, which I now can't reproduce. I will continue looking into this, but I think I need to gather my thoughts and re-do many of these tests and experiment a little more with the sliding tones that I can generate here and that have shown some aliasing up. I have other things to do, of course, so it may take a few days.

    I am interested because I have been seeing my unexpected weird events when selecting different tabs in Windows 7 Control panel and hadn't really considered that sample rate conversion might be adding to my confusion. Certainly, I need to understand more about what is happening to the signal in the various ways of recording and playing audio.


    Saturday, January 15, 2011 8:38 PM
  • Thanks again. Very interesting. I really expected you to be able to reproduce the problem, at least on the Realtek! 

    I'm going to test as many systems as I can.

    p.s NW8000 laptop install barfed. (hardly surprising - it's ancient. Haven't researched it yet though)

    Saturday, January 15, 2011 9:28 PM

    I have just tested a Sony VAIO F I7-740QM (running Ultimate 64-bit) through it's internal speakers.  It was in a store on the net, so I used the same 100Hz test tone: http://www.youtube.com/watch?v=mejO0hV_w80  

    By default, it did NOT produce the artifact. However, I noticed that the audio interface (Realtek, again) was set to 44100. When I changed it to 48000, reloaded the page, and played it again,  I heard the artifact very clearly.  Assuming that noone had dinked with the settings, it appears that this system did have a default sample rate of 44100, which seems to be what Matthew would expect. (yes?)


    p.s Yes, I set it back to 44100 before I left. ;^)


    Monday, January 17, 2011 1:07 AM
  • Dell E6500 Latitude running Ultimate 32-bit.
    Audio: IDT High Definition Audio Codec. (not Realtek - hooray!)

    This one is doing it too. The standard driver off the distribution was on 44100 by default, but when I changed it to 48000, the artifact occurred.

    I left it on 48000, and then installed the Dell driver for this device from the Dell driver download page.  The sample rate did not change - it stayed on 48000, and yes, the artifact was audible.  When I switched it to 44100, the sound became pure.

    I don't think the default sample rate is the main issue here, because I'm assuming that it would be completely normal for the sample rate to be altered in normal use. For example, the DVD standard is 48000, so presumably some DVD player applications will change the sample rate to 48000, or at least advise the user to do it manually.   As soon as this happens, YouTube et al will lose fidelity. The sample rate conversion for embedded media simply needs to be improved, as far as I can tell. 


    Monday, January 17, 2011 7:16 AM
  • Installing the official Dell IDT driver (on the E6500 Latitude) changes the sample rate from 44100 to 48000.


    Monday, January 17, 2011 5:24 PM
  • Here's a recording of real music where I think most people would readily notice the improvement in fidelity, when switching from 48000 to 44100:

    I repeat: I noticed the problem straight away on Windows 7, listening to real music - not test tones.


    Monday, January 17, 2011 6:54 PM
  • > some DVD player applications will change the sample rate to 48000

    The good(?) news is that applications can't do this.  They can play to an off-default sample rate via exclusive mode; they can prompt the user to go to the Sound control panel; but there is no API to set the default sample rate from an application.

    Matthew van Eerde
    Monday, January 17, 2011 8:10 PM
  • Matthew,
    Thanks for the info.

    After an application has changed the sample rate via exclusive mode, what happens when the application terminates, if it has not explicitly changed the sample rate back to the default? Does Windows put it back to the default automatically? If it does, does it do that straight away, or does it do that as soon as a standard "shared" mode application opens the device?  


    Monday, January 17, 2011 9:10 PM
  • Opening the device in exclusive mode does not change the default sample rate.
    Matthew van Eerde
    Monday, January 17, 2011 9:29 PM
  • Matthew,
    If an exclusive mode application changes the sample rate of the hardware (for the duration of it's session), and if it does not explicitly change the sample rate of the hardware BACK to the default sample rate when it exits, this means that at some stage, the hardware must be reprogrammed with the default sample rate. When does that  occur, exactly, and are you absolutely sure this will happen?

    Here's another good example of the aliasing artifacts: warning - slightly explicit video of Madonna cavorting around ;^)
    Scroll forward to time 3:50


    • Edited by piriton Wednesday, January 19, 2011 12:53 AM
    Monday, January 17, 2011 10:17 PM
  • The hardware is programmed with the sample rate at every call to KsCreatePin.

    Every exclusive mode stream results in a call to KsCreatePin.

    A shared-mode stream will either:

    • result in a call to KsCreatePin (if there are no other shared-mode streams active)
    • result in the audio engine mixing multiple streams and passing the mixed result down to the already-created KS pin

    The "default sample rate" exposed in the Sound control panel is what the audio engine passes to KsCreatePin for shared-mode streams.

    Matthew van Eerde
    Monday, January 17, 2011 10:38 PM
  • Matthew,
    I have just done the following:

    1. Installed the driver for the M-Audio Fast Track Ultra (a USB audio/MIDI interface)
    2. Checked the default sample rate in Windows (44100)
    3. Opened an ASIO application (Pianoteq) Default sample rate in here was 44100 as well
    4. Changed the sample rate in this application to 48000, and verified that the M-Audio Control Panel reflected this change. (I forgot to look at Windows)
    5. Closed Pianoteq, and verified that no change of sample rate in the M-Audio CP occurred - stayed on 48000
    6. Opened a YouTube clip : sample rate stayed on 48000 in the M-Audio CP
    7. Checked the Windows default sample rate for this device: it had changed to 48000

    So, IF (and that's a big if, I agree) an ASIO application can be considered to be similar to an "exclusve mode" application, then it appears to me that you might be mistaken.

    Even if you're right, and the above would NOT occur for a non-ASIO, Windows exclusive mode application, it appears to me that the default sample rate can easily change, if a user is using any ASIO applications.


    Monday, January 17, 2011 10:46 PM
  • Interesting that an ASIO app can change the default sample rate.

    I know that drivers can change the default sample rate themselves, either by unregistering and reregistering the KS filter or by raising a KSEVENT_PINCAPS_FORMATCHANGE event and favoring 48 kHz in the following KSPROPERTY_PIN_PROPOSEDATAFORMAT query.  I don't know if the app is doing this or is hacking the property key in the registry (I hope the former.)

    Matthew van Eerde
    Monday, January 17, 2011 11:01 PM
  • I doubt it's doing anything like that.

    If I simply change the sample rate myself, in the M-Audio CP, this is immediately reflected in Windows, as the new "default" sample rate. So, I feel confident that the app is simply changing the sample rate in a very standard way, through the ASIO driver.

    EDIT: Apologies - you said driver, not application.

    I'll ask M-Audio whether it is doing as you suggest - thanks.


    Monday, January 17, 2011 11:04 PM
  • Matthew,
    The onboard IDT audio works like you expected. With an ASIO (using ASIO4ALL) app open, the default sample rate in Windows does not change. Moreover, Windows cleverly redirects all audio to the internal speakers, with ASIO using the headphone output.  I never even knew my laptop had independent channels for the internal speakers & headphone out.  As soon as I close the ASIO app down, BANG, the Windows audio is directed back to the headhone output jack. 

    I think I might know why the M-Audio behaves like it does. This device has some level of "multi-client" functionality, in that it allows ASIO and WDM clients to access it simultaneously, with the multiple sources being mixed.  Presumably there is only one way for the driver to tell Windows the current sample rate, and that's the same way it tells Windows the "default" sample rate. If the "default" sample rate were not updated with the current sample rate, the hardware would be using a different sample rate to that which the WDM clients thought the hardware was set to, resulting in erroneous audio. Naturally, I'd rather have the multiclient functionality, and sacrifice a true default sample rate setting.


    Tuesday, January 18, 2011 8:38 AM
  • Greg,  I'm not sure how far I would use asio4all as a representative asio application. It is, after all, simply a (very good) translator between apps requiring asio drivers and non-asio audio interfaces.

    I have now done some more tests, but I have been using a locally generated "pure" 40 to 16000Hz sliding tone pcm wave file. This removes the possibility of any of the artifacts being the result of side effects from the  audiocompression processes.

    I've tested with 2 machines - the Acer 5536 AMD based laptop running 64-bit Win7 Professional and a Lenovo G550 with single core Celeron running Win7 32-bit Home Premium. I've tested with the M-Audio FastTrackUSB device and a Tascam US-122L interface, both of which have asio drivers. The Acer has Realtek on-board with Realtek drivers, the Lenovo IDT on-board with Microsoft Class compliant drivers. It has independent settings for headphones and speakers.

    The applications tested with are: Winamp - to be able to use DirectSound or WaveOut (set to HD Audio as opposed to WaveMapper) as the output, Windows Media Player (which sounds the same as Winamp with DirectSound), Adobe Audition 1.5 and 3.01 and finally Wavosaur, which can be switched between asio and WDM.

    I also trawled through anything related to audio on the machines and removed things where possible, including one Skype related function that may have been cusing some of my earlier confusion.

    Both machines performed essentially the same which was a relief.

    With Winamp set to on-board and DirectSound, the sweep was clean irrespective of which sample rate was set as default. Switch to WaveOut and when the default sample rate was set to 48k and the file was 44.1k, there was clear aliasing. If the 2 sample rates matched, the sound was clean.

    I then installed the M-Audio drivers, which came up in 44.1kHz mode, and reflected into the default settings for the M-Audio in Windows CP, which only offered 16 or 24-bit 44.1kHz. This played cleanly through Winamp etc. Switching the M-Audio CP to 48kHz added the 48kHz option in the Windows CP and switched to it (but only seen when that part of the WinCP was closed and re-opened).

    Switching Winamp to Wave Out before sending to the M-Audio device brought in aliasing when the M-Audio CP was set to 48kHz.

    Then tested with a Tascam US-122L usb2 interface. This appears to work in the opposite way to the M-Audio in that the full range of settings appear in the in the Windows CP and set the parameters shown in the Tascam CP. When playing via an asio app and the app is closed when the audio is finished, if the non asio app is not set to the correct sample rate, the non-asio app (Winamp) will not play

    Using audition 1.5, there is aliasing if the sample rate is set incorrectly in the Windows CP

    Using Wavosaur as the audio app, if the sample rate is set incorrectly in Wavosaur, there is serious aliasing whether using asio or not.

    None of this is much help, I know.

    Tuesday, January 18, 2011 4:23 PM
  • Billabong,
    I haven't fully digested all that yet - many thanks though. It seems that you are experiencing aliasing when using WaveOut, which is what I expected, because that's what we had already discovered over on this blog:


    However, I'm much more concerned with YouTube, and other embedded media, because this is what people DO all the time. People don't generally use media players that use WaveOut much I don't think. It's not the default renderer for anything I have tried yet. (it may well be for some things, such as CoolEdit, as the blogger reported, however that's a VERY old application now, having been replaced by Adobe Audition - I actually own Adobe Audition but haven't tried it yet - I have an old version - V1.5 EDIT: I see you have tried this already - thanks)

    The fact that it occurs when using WaveOut may of course be extremely important information, though.

    Yes, there is MP3 compression in YouTube, but the difference between playing back at 44.1kHz and 48kHz is CLEARLY audible to me.  The artifacts COMPLETELY disappear when playing back at 44.1kHz, and moreover, the problem does not occur on Windows XP.

    So, can you hear the aliasing in the music examples I have given?

    Can you hear the aliasing in the 100Hz sine wave test tone in YouTube? When I tried that at the store, on the VAIO, the noise was VERY audible.  The 100Hz tone was not audible, due to the small speakers, however the high pitched ringing was readily audible, and it simply did not occur when I played back at 44.1kHz.  I realise that you've already tested this and didn't hear anything, but I have a suspicion that if you try harder, you'll hear it. ;^)

    RE: ASIO4ALL, remember that I really wanted to test the Windows "exclusive mode", however I don't have an exclusive mode app to test with. I have tried the beta of Audacity, which purports to support exclusive mode, however it is NOT changing the sample rate of the M-Audio FTU, so I don't trust it yet.  So, I resorted to ASIO, because at the very least, I can see that when I use an ASIO app, and change the sample rate from that app, that the change is reflected in the M-Audio CP, so I have confidence in it.  Given that I decided to test with ASIO, and given that there are no native ASIO drivers for my onboard audio, then naturally I had to resort to ASIO4ALL in order to test the onboard audio with ASIO. 

    EDIT: I think the other issues you have discovered are very important too. As I noted earlier, applications that used to change the sample rate of the hardware no longer do that. It appears that they will have to be ported to the new architecture, unless of course changes are made to Windows to make it backwards compatible. It's very interesting that you were able to create a situation where the app would not play at all!!  (although that type of failure doesn't really bother me much, because it's obvious to the user that something is wrong. The loss of fidelity due to sample rate conversion is not as obvious)


    Tuesday, January 18, 2011 4:41 PM
  • Is there a way to split quote blocks up? I wanted to insert snippets of quoted text, but could not see how to do that. 

    Also, when I click the Edit button to edit a reply, it often inserts raw html into the message composition window. Tried with I.E and Chrome. I have to back out and try again, and it always seems to work the second time. Maybe I should just use the raw mode to insert quote blocks!


    Tuesday, January 18, 2011 6:04 PM
  • I will try using WaveOut rather than DirectSound.
    Matthew van Eerde
    Tuesday, January 18, 2011 6:37 PM
  • Matthew,
    That's good.

    When we watch a YouTube clip, does that use WaveOut? If it does, then it would make testing easier, because we would not need the internet.  (although I have reproduced the aliasing with the standalone Adobe FLASH player - I reported this on the Adobe FLASH Player forum: http://forums.adobe.com/click.jspa?searchID=4973214&objectType=2&objectID=3376436

    Note that I reported in my VERY FIRST POST that the problem occurred with WaveOut. I said:
    "There is some prior discussion of this issue at this blog:


    According to a user there, the problem occurs if the application uses the WaveOut API. Directsound works fine.

    Just on the M-Audio driver behaviour and the default sample rate etc, I've decided NOT to contact them, because the behaviour is desirable. I.e - I don't care how they are doing what they are doing, because the result is what I would want: to be able to use ASIO and normal Windows applications simultaneously. (it's good that this functionality has been retained)


    Tuesday, January 18, 2011 6:44 PM
  • I have a confirmed repro in-house with waveOut.
    Matthew van Eerde
    Tuesday, January 18, 2011 8:34 PM
  • Thanks.  ;^)

    As I said earlier, it seems that WaveOut in Windows 7 is worse than it was in XP, even when I put XP's sample rate conversion setting on the lowest quality setting. That seems very strange.  Note however that I have been doing most testing with that 100Hz test tone, which I accept is NOT the way to do a complete assessment of a sample rate converter. The reason I used that tone was simply because I seem to notice the problem in music when there are low frequency, harmonically pure tones.


    Tuesday, January 18, 2011 8:55 PM
  • I want to thank you for your persistence and attention to detail in bringing this issue to our attention.  It's very helpful.

    Matthew van Eerde
    Wednesday, January 19, 2011 12:36 AM
  • Thanks Matthew. I'm very glad to hear that, and thanks for YOUR patience as well.

    Thankyou Billabong too!!! :) (are you in Australia? It's a very Aussie name. I'm in Sydney)


    p.s I hope I didn't offend anyone with the racy Madonna video. I've gone back and edited the post, adding a warning that the video is slightly explicit.  ;^)  (of course, the fact that the video probably ought not to be on YouTube to begin with is another matter entirely!)

    Wednesday, January 19, 2011 12:49 AM
  • Can anyone load a 100Hz, 44.1kHz sine wave up to a Silverlight page? You can use one from here: http://www.mediacollege.com/audio/tone/download/ (WAV would of course be best)

    The reason I'm interested in this is because I have not yet heard any aliasing on this Silverlight music store:
    http://www.tekmo.com.ec/TekmoRecords.aspx  which I reached via: http://www.silverlight.net/showcase/

    Matthew: again - can you tell us whether watching a YouTube clip will use WaveOut? How about a Silverlight page - what API will that use?

    EDIT: Here's a song where I can clearly hear aliasing in YouTube:
    http://www.youtube.com/watch?v=N1iVi6b3YPc ("Tekmo - Hands on Denon - Part 1")

    However, on the Tekmo site, it sounds crystal clear, regardless of the sample rate I use on my audio interface. (tried 44100 and 48000) To reach the track, open the Tekmo web site, and then access the track on the right, in the Video Playlist.

    Note that I do sometimes hear some artifacts from the lossy compression on Tekmo, I think, (not on this particular track yet), but it's very different to the other aliasing I have been drawing your attention to.  Again - the aliasing in YouTube goes away when I set my audio interface to 44100.

    Note that I am not insinuating anything at all - I am just making observations here. There's simply no doubt in my mind whatsoever that the Tekmo site does NOT suffer from the same problem regarding sample rate conversion. I suppose it would be good to know what format the Tekmo content is in though.


    Wednesday, January 19, 2011 6:54 AM
  • Quicktime seems ok. I don't know whether it makes a difference how the actual web page is constructed, but I haven't noticed any problems with Quicktime yet.


    Wednesday, January 19, 2011 11:44 AM
  • Greg, I now can hear clearly the effect on the Scarbee bass example, the  Moonlight Sonata and the Madonna. I'm still looking at other problems here, so it has taken some time. Both laptop machines produce occasional glitches on both usb audio interfaces if the wifi is enabled, an effect that seems to pop up on forum after forum.

    There is also the effect caused by Skype. I don't have to be logged in - just have the icon on the taskbar, and the M-Audio interface changes from the aliasing to the machine-gun juddery sound I referred to earlier after playing for a few seconds.  This doesn't appear to affect the Tascam interface in the same way, but I need much more time to investigate. I need to ensure that Skype is always completely disabled. Logging out and Closing seems not to be enough.

    I'm Billaboard - not bong, so not in the antipodes - in the UK. I tried sending you (or someone with the same problem) a private message on the M-Audio forum which might appear at the very top of their page under "notifications" if you log in there.

    I am not able to try Silverlight. :-(

    Wednesday, January 19, 2011 5:53 PM
  • Billaboard,
    I'm really sorry for mis-reading your "alias". ;^)

    It's good that you can hear the artifacts in normal recordings, and not just esoteric sliding tones etc - it supports my assertion that the artifacts are audible in normal, everyday recordings.

    Yes, that's me over on the M-Audio forum, and I've replied to your message - thanks.

    RE: Silverlight, it's just a matter of installing the plugin - are you sure you can't try it? It's only a small download, too.





    Wednesday, January 19, 2011 10:17 PM
  • Here's an article about the J River Media Center, and it has good information about WASAPI and Exclusive Mode etc.:


    I've tried it, and the damn thing works exactly as expected. ;^) For example, I did the following test, using the M-Audio Fast Track Ultra (USB device), with J River using WASAPI:

    1. Plugged the M-Audio in, and checked the default sample rate in Windows. It was 44100.
    2. Verified that the sample rate matched in the M-Audio Control Panel
    3. Played a 48000 sample rate WAV file in J River, and while it was playing, observed the M-Audio C.P. The sample rate changed to 48000.
    4. Exited out of J River. Sample rate stayed on 48000 in M-Audio C.P
    5. Did something in Windows that caused a sound to play. Sample rate changed to the default (44100) in the M-Audio C.P, which is the expected behaviour.
    It would be good if the Windows Media Player had the option to use Exclusive Mode, if it does not already have this. Also, it would be nice if there was an "audiophile" mode for Windows, where it warned the user if a sample rate conversion was occurring. (naturally, this would not be of any use for those applications that do their own sample rate conversion).

    So, I have now witnessed Exclusive Mode in action. It does work. :)


    Saturday, January 29, 2011 5:06 AM
  • Hi Greg, Matthew,

    My team has just come across this, having just upgraded all machines to Win7 laptops.

    We work on telephony applications; hence, a lot of 8kHz audio.

    I heard significant aliasing on my machine when listening to wav files with a lot of wind artifacts.  This was replicated first with brown noise and then later with a simple 30Hz tone.  Its very clear--you hear an 8kHz tone. If I up-sample this to 16kHz the aliasing disappears.

    My machine is a Lenovo x201 with Conexant 20585 audio device, running Windows 7.

    The aliasing occurs when playing the wav file in our own proprietary test applications, Audition 1.5, CoolEdit 2000, and Power Point 2007.  But NOT when using Windows Media Player, VLC, or MPC.  It doesn't occur in Audition 3, although it is doing something very strange to the file and the sound quality is very poor.

    It occurs whether using the analog line-out or a USB audio card (Creative SB).

    I confirmed that it is also occurring on other Dell Latitude laptops using the IDT High Definition Audio Codec.

    I'd like to confirm that this is a real issue impacting our presentation materials (power points with 8kHz bef/aft audio samples) and quality judgments of processed, narrow band, speech signals.  And that this was never an issue with XP or Win2000.

    Greg, Matthew, its been a month since your last post--have you seen any resolution to this issue?




    Wednesday, March 2, 2011 9:00 PM
  • I am still watching this, but have been "called away" by more pressing problems. My hope is that Matthew will say that someone in Microsoft is actively investigating the effect.

    My own testing, mainly with sweep tones, confirms that sometimes there is a problem, sometimes not, but the problem can always be reproduced when the conditions are completely identical. The difficulty is the number of variables now involved in Windows 7 audio and tracking which are reflected across into other controls and which are not.

    This is why I feel that the problem needs someone with sufficient time available to address this problem.

    Audition 3 is, of course, an asio application and so introduces a set of additional variables. My different asio audio interfaces don't all act in the same way, and some seem to link settings between the asio part of their drivers and the wdm section.

    Wednesday, March 2, 2011 11:51 PM
  • Thanks Phil. I haven't got anything more to add - I'm simply waiting for a fix or workaround.


    Thursday, March 3, 2011 12:29 AM
  • I've been investigating some audio quality problems in Win7 and just bumped into this thread. Thanks guys, good stuff here!

    1) I can confirm the 44.1 to 48K (and vice versa) SRC path generates audible aliasing tones at appx 3.9k and 7.8KHz when stimulated with a low frequency (1Hz) sine wave. The alias tones are about -70 dB down and have an appx +10 dB ampiltude modulation at the stimulus frequency. Although they are low in amplitude relative to the signal, they are some 30 dB *above* the noise floor and thus are clearly audible.

    2) When the sine frequency is swept up, the two major alias tone peaks each split into two peaks separated by the twice the frequency of the input stimulus. (Now we have four alias tones.)

    This all looks like classic poor performance SRC behaviours to me.

    A very simple test case is to use  VA.EXE "Visual analyser", set the signal generator sample rate to 44.1 the Windows output device hardware sample rate to 48k, and loop back the output to the sound cards input for the spectrum analyzer to look at. The alias tones are clearly audible and visible. I have verified this same result on the built in Azalia/HD Audio codec and a USB audio device. When I get a few spare minutes, I'll do some regression testing on XP just for completeness sake.


    Monday, March 28, 2011 9:47 PM
  • We have found the problem, which is a bug in waveOut on Vista and Windows 7.  Windows XP does not have this problem.

    In Windows XP, the sample rate conversion quality in KMixer is controlled by the Sound control panel:


    In Windows Vista KMixer was removed and the audio engine was moved up into user mode.  The sample rate conversion quality meter was removed from the Sound control panel.

    Media Foundation, DirectShow, DirectSound, and waveOut each do sample rate conversion slightly differently.  There is a bug in the waveOut sample rate conversion which results in a lower-quality sample rate conversion than was done in XP.

    Matthew van Eerde
    Tuesday, March 29, 2011 3:56 PM
  • Matthew, that is good news. Can we expect an update to cure this, and would it be possible to put a reference in this thread to enable people to identify that upgrade?

    Meanwhile, is it allowable to copy, with or without attribution, your final paragraph and present it in forums that I frequent? This has become rather a daunting thread to refer people to.

    Tuesday, March 29, 2011 7:34 PM
  • Thanks Matthew.

    Has the recording path been assessed for the same problem?


    Wednesday, March 30, 2011 9:44 AM
  • Yes - the bug is in code shared by waveOut and waveIn, so it's likely that the same effects would be observed in waveIn capture sample rate conversion.
    Matthew van Eerde
    Wednesday, March 30, 2011 2:59 PM
  • Hello Maurits,


    I have a similar problem as Piriton and Billabord, except I believe mine is a bit more extreme.  I'm running Windows 7 Home Premium on an AMD Phenom 9550 Quadcore 2.1 GHz system with 8 GB Ram and 3 1Tb SATA drives.  My soundcard is M-Audio Audiophile 2496.  I have disabled the onboard HD audio in the BIOS as well as in device manager.  Not only does my soundcard ASIO default to 88,200 Hz. 24 bit, but it locks there in the M-Audio ASIO panel and is the only choice available in the advanced tab of the soundcard properties.  It is also the only choice for ASIO settings in Kontakt 4.2.  But if I fire up some of the other Komple 7 instruments (Kore 2 , Absynth, FM8,) the audio settings default to 44,100 Hz.

    What is going on?  Even when I get my ASIO control panel set to 44,100, it defaults to 88,200 next time I boot.  The downsampling and mixed smpling rates make for very nasty sounding audio when I mix down from my DAW to a WAV or MP3 file.


    Confused in VA


    Saturday, July 9, 2011 3:26 AM
  • Hi Matthew,

    Thanks for the feedback.

    Do you have any updates on this issue?  Can we expect a patch soon?




    Tuesday, August 9, 2011 5:09 PM
  • I confirm that this is a known bug, but I cannot give any updates at this time; in particular I cannot make any statements regarding a patch.
    Matthew van Eerde
    Wednesday, August 10, 2011 5:45 PM
  • I was noticing this same aliasing issue on my Vista and Windows 7 machines, both of which have RealTek HD audio on-board. It was driving me crazy and I was about to give up until I stumbled across this excellent thread. Many thanks to Greg, Billaboard, and Matthew for the careful investigation.

    One strange thing I noticed: on my Vista laptop, a DirectSound app that runs in shared mode (foobar2000 1.1.x, an audio player) experiences the problem in question—aliasing when playing 44.1 content with 48 selected in the RealTek control panel. The app's output format selector is disabled for the RealTek device, so the solution was to use a SRC output plug-in within that app to convert all output to 48. Yet on the Windows 7 desktop, the same app has no problems playing 44.1 content with 48 selected in the RealTek control panel. I can't make it alias at all. The posts in this thread seem to indicate that DirectSound shouldn't have any problems. Any idea what's going on with the Vista machine? I'd be happy to carry out more tests, if it will help.

    Regardless, has there been / will there be any further work on this bug at Microsoft?

    If it's unreasonable to expect the bug to be fixed, then I would like to ascertain and publish some "best practices" to help audio application users, developers, and driver programmers easily determine whether their system is affected and how to work around the issue. Most likely, I'd be posting about it in the Hydrogenaudio forums and/or wiki, if no better venue is suggested. Or would this be a waste of time?



    • Edited by MikeBrown Wednesday, December 14, 2011 7:12 AM
    Wednesday, December 14, 2011 7:03 AM
  • Curious. There is definitely a bug in WinMM in Windows 7 which causes aliasing. It sounds like you've uncovered a DirectSound issue in Windows Vista which was (apparently) fixed in Windows 7.
    Matthew van Eerde
    Wednesday, December 14, 2011 4:12 PM
  • hi Microsoft.

    i search and search, and finally i see some others have the same issue of this 48khz "noise signals".

    at first, i thought that 's the problem of my audio cable, no. then i thought it is the problem of my sound card, no.

    then i thought it is the problem of the driver, no.

    As you may already know, the "noise" is at 3.9khz and 7.8khz . (<-- notice it is a 3.9khz diff. between 44.1 and 48.)

    as illustrated in this graph. i just record the output of a bass sound in win7.


    This noise happens in every application, including game.

    The only solution so far is to set your audio to play at 44.1

    And i am now using my xp to do audio production.

    Monday, January 30, 2012 3:30 PM
  • I have recently purchased a Lenovo Thinkpad laptop and allowed it to run through the "preparing for first use" routine, then, before any other action checked the default sample rates set for the on-board sound. Playback was set to 44.1kHz, record was set to 48kHz.

    I commented on this in another audio forum and replies indicated that this is a common setting for machines as delivered

    This does not agree with Maurits's statement here that the default should be 44.1kHz on a Windows 7 machine, which I assumed applies to both record and playback.

    I wonder if Mike Brown ever submitted his "guidance paper" referred to above? I still find that, because of the number of variables involved (eg soundcard (often internal plus external on a laptop), audio application, source or destination of material) that any advice beyond "set everything to the sample rate you are going to use" has to be on a one to one basis.

    Monday, January 30, 2012 6:02 PM
  • Windows has a list of common formats that it uses to probe the driver for format support.  If the driver says "yes", then Windows adds that format to the dropdown in the control panel.

    An audio driver can also tell Windows that it has a "preferred" format.  If it does, Windows will use that format.

    In the absence of a device-preferred format, Windows will choose one of the formats that the device said "yes" to.  If the device supports both 44.1 and 48, Windows will choose a 44.1 format.

    Matthew van Eerde
    Tuesday, January 31, 2012 2:08 PM
  • It looks like a patch has been released: http://support.microsoft.com/kb/2653312
    Saturday, March 10, 2012 5:51 PM
  • Oh, good.

    Matthew van Eerde

    Monday, March 12, 2012 4:26 PM
  • I guess Vista will get ignored for this issue? No patch for it?
    Sunday, April 8, 2012 8:54 AM