Add Foobar to the list of programs that does not play 24/96 correctly in Windows. Including with the optional ASIO driver component installed.
Which version of Windows? From Win 7 on its not been well suited to this. In Win 10 you must switch everything, including the windows sound engine. Working with the Lynx in ASIO you may have a similar problem where the Lynx works only at what you set and sample rate converts. This is Windows copying Apple it seems.
XP and some cards (ESI Juli@ for example) will follow what the application asks for in WDM (windows driver).
JRiver can manage all of that for you with some cards. This is why I have 4 cards I switch between on Windows. Linux does allow a way to obviate all of this.
XP and some cards (ESI Juli@ for example) will follow what the application asks for in WDM (windows driver).
JRiver can manage all of that for you with some cards. This is why I have 4 cards I switch between on Windows. Linux does allow a way to obviate all of this.
Windows 10 Professional here.
Programs that bypass most of Window and use ASIO to take control of the sound card have no problem, they just need to be configured correctly. Reaper works fine if configured correctly.
Apparently, programs that use ASIO and don't take control of the sound card don't change the Windows auto SRC. Foobar with the ASIO option would fit this category.
Professional recording programs could take control of the sound card and set the sample rate in all versions of Windows for as long as ASIO has existed.
It just appears that most media player programs do not take control of the sound card, they leave that to Windows and operate in Windows "shared mode" sound. In shared mode, Windows does auto SRC.
Regarding Lynx, it can work is multiple ways depending on configuration and what is sent to it by Windows. However, in this case auto SRC was always occurring in Windows.
The reason I reported my findings here is because people have said that they don't hear a difference between hi-res and CD quality, so they conclude it doesn't really matter. In reality, they may have been fooled by Windows. Therefore, I thought this topic might be of general interest.
Programs that bypass most of Window and use ASIO to take control of the sound card have no problem, they just need to be configured correctly. Reaper works fine if configured correctly.
Apparently, programs that use ASIO and don't take control of the sound card don't change the Windows auto SRC. Foobar with the ASIO option would fit this category.
Professional recording programs could take control of the sound card and set the sample rate in all versions of Windows for as long as ASIO has existed.
It just appears that most media player programs do not take control of the sound card, they leave that to Windows and operate in Windows "shared mode" sound. In shared mode, Windows does auto SRC.
Regarding Lynx, it can work is multiple ways depending on configuration and what is sent to it by Windows. However, in this case auto SRC was always occurring in Windows.
The reason I reported my findings here is because people have said that they don't hear a difference between hi-res and CD quality, so they conclude it doesn't really matter. In reality, they may have been fooled by Windows. Therefore, I thought this topic might be of general interest.
Last edited:
This is not a problem with the application, it's a problem with your hardware's driver.
It is a characteristic of Windows 10. And as I said, it can be changed in Windows control panel, sound, device, properties, advanced, shared mode sample rate.
Windows 10 does auto SRC in general if the source sample rate differs from the shared mode sample rate.
The problem with applications is most of them can't or don't override default Windows behavior. Professional recording programs such as Reaper or Cubase can do it just fine using ASIO. (I haven't tried other drivers lately.)
Last edited:
Which hardware doesn't do this in Win 10? I have used Win 10 with a dozen sound interfaces or so including motherboard, PCI consumer and pro and USB. In all of them the Windows driver has that setting field for the cards sample rate which is fixed once set.
Even in cards like the Juli@ which work fine in XP with application controlled sample rates on the same system. That's why I have dual boot (and found the imbedded XP magic key) on all the test systems.
Even in cards like the Juli@ which work fine in XP with application controlled sample rates on the same system. That's why I have dual boot (and found the imbedded XP magic key) on all the test systems.
ASIO is not part of the Windows audio stack. What your driver decides to do when it gets an ASIO stream of a different sample rate is up to it.
My EMU 1820m does not do what you describe and I am running Windows 10 (post Anniversary Update).
My EMU 1820m does not do what you describe and I am running Windows 10 (post Anniversary Update).
An externally hosted image should be here but it was not working when we last tested it.
I don't doubt that a lot of hardware behaves this way. I am pretty sure though that the driver could choose to change the system sample rate. When I play any ASIO through the EMU cards on Windows 10 I get no audio outside of the app unless it's at the same sample rate as the ASIO session.
No, EMU PatchMix DSP shows the exact clock rate. I cannot even play 48KHz audio in this mode. You'll note my volume mixer shows no color in the bars, hence NO audio is routed through the Windows stack at all.
Here is further evidence if you don't believe me. The EMU driver has placed the audio device in exclusive mode and is playing at 96kHz no matter what Windows is set to.
An externally hosted image should be here but it was not working when we last tested it.
Here is info on how things work in Windows 10 direct from MS:
https://msdn.microsoft.com/en-us/wi...atency-audio#windows_audio_session_api_wasapi
Starting in Windows 10 , WASAPI has been enhanced to:
Allow an app to specify that it wishes to render/capture in the format it specifies without any re-sampling by the audio engine
Now, this doesn't apply to ASIO, only WASAPI. ASIO is not part of the Windows audio stack so whatever the driver decides to do is up to the developers I am 99% sure.
https://msdn.microsoft.com/en-us/wi...atency-audio#windows_audio_session_api_wasapi
Starting in Windows 10 , WASAPI has been enhanced to:
Allow an app to specify that it wishes to render/capture in the format it specifies without any re-sampling by the audio engine
Now, this doesn't apply to ASIO, only WASAPI. ASIO is not part of the Windows audio stack so whatever the driver decides to do is up to the developers I am 99% sure.
Good, I think we are in agreement.
The only remaining problem is most media playback applications do not override resampling. Again, I believe this has to do with accessing Windows sound drivers in either "shared mode" or "exclusive mode." The applications I tried seemed to be using shared mode. However, the version of foobar I used was an old one. It could be newer versions use exclusive mode. Presumably, exclusive mode permits disabling of resampling. That would not appear to be a practical option for shared mode. For applications using shared mode, the shared mode sample rate can be set in Windows control panel.
The only remaining problem is most media playback applications do not override resampling. Again, I believe this has to do with accessing Windows sound drivers in either "shared mode" or "exclusive mode." The applications I tried seemed to be using shared mode. However, the version of foobar I used was an old one. It could be newer versions use exclusive mode. Presumably, exclusive mode permits disabling of resampling. That would not appear to be a practical option for shared mode. For applications using shared mode, the shared mode sample rate can be set in Windows control panel.
Attachments
We agree on WASAPI playback, but not ASIO. Exclusive mode is a Microsoft stack construct.
The fact that playing back ASIO does not switch your device into exclusive mode is a decision by the driver developers (it may be a lack of decision also - default behavior). I can play back ASIO from any source application and it will trigger this behavior because that's how the EMU drivers are designed. I could go back and test an old version of Foobar, but it's not up to the application when it comes to ASIO. You are correct when it comes to WDM/WASAPI playback.
I am not sure what ASIO driver you are using, but if it's ASIO4ALL, you should know that it's not the same as a real ASIO driver; it's a wrapper that still ends up using your WDM driver for output.
The fact that playing back ASIO does not switch your device into exclusive mode is a decision by the driver developers (it may be a lack of decision also - default behavior). I can play back ASIO from any source application and it will trigger this behavior because that's how the EMU drivers are designed. I could go back and test an old version of Foobar, but it's not up to the application when it comes to ASIO. You are correct when it comes to WDM/WASAPI playback.
I am not sure what ASIO driver you are using, but if it's ASIO4ALL, you should know that it's not the same as a real ASIO driver; it's a wrapper that still ends up using your WDM driver for output.
Last edited:
It's Lynx ASIO, but I only use it with Reaper. And Reaper has settings to either read the existing sound card sample rate and use it, or to set the sound card sample rate. That is useful for when the Lynx is synced to an external A/D via SPDIF or AES that has a manually set sample rate. I assume the ASIO driver supports both functions, as both functions work correctly with Lynx2.
Also, it looks like the original Lynx2 I have is now considered a legacy device and only supports ASIO and WDM. It was working with most applications using WDM apparently, after some more investigation. And setting the shared mode sample rate in Windows changed what Windows sent to it. Anyway, still working on it, or I will pick it up again tomorrow sometime.
I have other sound devices that support WASAPI, and they can be used for SPDIF out to the DAC-1, but they don't have control panels to show the actual sample rate in use, so maybe the only way to tell if Windows is in shared mode is to try to send it two audio streams and see if the second one fails. Haven't tried it yet.
The remaining uncertainty about when Windows WASAPI is in shared or exclusive mode, and therefore when resampling might be active may still be an issue for users in general. Maybe there is some way to find out the mode in use with a script call to Windows, or maybe there is some utility to show it. Don't know.
Also, it looks like the original Lynx2 I have is now considered a legacy device and only supports ASIO and WDM. It was working with most applications using WDM apparently, after some more investigation. And setting the shared mode sample rate in Windows changed what Windows sent to it. Anyway, still working on it, or I will pick it up again tomorrow sometime.
I have other sound devices that support WASAPI, and they can be used for SPDIF out to the DAC-1, but they don't have control panels to show the actual sample rate in use, so maybe the only way to tell if Windows is in shared mode is to try to send it two audio streams and see if the second one fails. Haven't tried it yet.
The remaining uncertainty about when Windows WASAPI is in shared or exclusive mode, and therefore when resampling might be active may still be an issue for users in general. Maybe there is some way to find out the mode in use with a script call to Windows, or maybe there is some utility to show it. Don't know.
Looks like Foobar can be setup to use WASAPI exclusive mode: foobar2000: Components Repository - WASAPI output support
Thus assuring no resampling (SRC - Sample Rate Conversion)
Foobar can also work correctly with ASIO, although the documentation for configuring it appears incomplete.
http://www.foobar2000.org/components/view/foo_out_asio
Thus assuring no resampling (SRC - Sample Rate Conversion)
Foobar can also work correctly with ASIO, although the documentation for configuring it appears incomplete.
http://www.foobar2000.org/components/view/foo_out_asio
Last edited:
With Windows playback in foobar working correctly, the differences between George's 24/96 file, and the undithered 16/44.1 file (6), are striking (to me, anyway). Test files are referenced here: http://www.diyaudio.com/forums/everything-else/169484-what-wrong-op-amps-476.html#post4955946
Last edited:
http://www.diyaudio.com/forums/digital-line-level/281212-hi-rez-you-cant-hear-difference.html
Striking (and accepting the personal distinction) suggests the difference is pretty big, which, isn't out of the question, but certainly an exceptional case. Mark, you sure the chain is working right? 16/44 even undithered on downsample vs 24/96 should make for a very subtle change.
Edit to add: I haven't had a chance to make sure my Windows routing is correct to give George's test a decent shake.
Striking (and accepting the personal distinction) suggests the difference is pretty big, which, isn't out of the question, but certainly an exceptional case. Mark, you sure the chain is working right? 16/44 even undithered on downsample vs 24/96 should make for a very subtle change.
Edit to add: I haven't had a chance to make sure my Windows routing is correct to give George's test a decent shake.
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.