Version 3.2.3:
WASAPI output support
By: Peter
Adds Windows Audio Session API exclusive mode output support, allowing bit-exact output and muting all other sounds. Windows Vista SP1 or newer required.
3.2 version highlights:
• Different default hardware buffer size for event mode - known to work better with specific soundcards.
• Different detection of stream formats supported by the device - should improve compatibility with certain SPDIF receivers.
3.2.1 version highlights:
• Fixed a crash bug from version 3.2.
3.2.2 version highlights:
* Compatibility improvements - removed the advanced preferences switch; the correct behavior is now determined automatically.
3.2.3 version highlights:
* Fixed 3.2.3 regression that made certain channel layouts not work.
Download: use the link on that page, as it is dynamically generated
Documentation: http://wiki.hydrogenaudio.org/index.php?ti.../foo_out_wasapi (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Components_0.9/foo_out_wasapi)
[original post below]
—
In case it generates a lot of discussion as its pre-releases did (http://www.hydrogenaudio.org/forums/index.php?showtopic=94907&pid=807346&st=175&#entry807346), I think it may be best that we try to keep things in one thread. Worth a try, anyway!
2012-09-02
The long-awaited update of the WASAPI output component has been released.
Component page (http://www.foobar2000.org/components/view/foo_out_wasapi)
WASAPI output support
By: Peter
Adds Windows Audio Session API exclusive mode output support, allowing bit-exact output and muting all other sounds. Windows Vista SP1 or newer required.
3.0 version highlights:
* Faster volume control
* 32bit integer mode if 32bit floating-point is not supported by the device
* Operates in two different modes, regular and event-driven - the latter seems to be more compatible with USB devices, but not supported by some other devices.
* Separate process sandbox for improved stability.
Current version
3.0, released on 2012-09-02
Links
Download (http://www.foobar2000.org/components/view/foo_out_wasapi)
Documentation (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Components_0.9/foo_out_wasapi)
Thanks! I am using it now and I cannot find any faults...
Thanks for this.
Thanks ! Using "Event mode" on HRT Music Streamer II firmware 2.2 within foobar 1.1.14a/W7HP64bit, 1030 msec buffer, 24bit. Works perfectly.
Is the WASAPI component supposed to work with ReplayGain compensation applied? I've hit Apply gain and prevent clipping according to peak (album mode), and fb2k sure as hell doesn't prevent clipping. The album in question has positive gain. I have a +0.0 for albums with RG info. Problem appears to be independent of push vs event mode chosen.
Furthermore, it often simply refuses to play, after it has been fed one of these albums. Even switching over to DS does not always work – I might have to restart foobar2000.
Using: 1.15 beta 1 with WASAPI 3.0. It is a fresh computer, so I have not tried any older version of the component.
I am getting a possible bug when performing the following steps:
1) Play a song
2) Click on Playback > Stop
3) Adjust system volume via taskbar icon so that the volume change sound gets triggered
4) Immediately try to resume playback (within 1 second after sound finishes playing)
5) Get playback error: "Unrecoverable playback error: Device in use"
Also, it would be great if the component would allow for sounds to be played while the sound is "Paused" versus "Stopped."
System Specs: foobar 1.1.14a, Win 7 x64, component version 3.0 final
Edit: Exclusive Mode in "Speaker Properties" is set to "Give exclusive mode applications priority," which may be the reason this is occurring.
Event mode sounds great. I didn't think there would be such a big difference between the two modes.
Can you qualify that claim according to #8 of the terms of service (http://www.hydrogenaudio.org/forums/index.php?showtopic=3974)?
Is the WASAPI component supposed to work with ReplayGain compensation applied? I've hit Apply gain and prevent clipping according to peak (album mode), and fb2k sure as hell doesn't prevent clipping.
Update: might be a quirky USB device. I have at one instance managed to provoke it to clip on a file without ReplayGain. But not (yet) after a fresh restart.
Should I use push mode or event mode for an onboard soundcard?
Why is the hardwarebuffer 200ms for push mode and only 10ms for event mode?
im having issues with foobar 1.1.15 and wasapi 3 with my usb dac it just doesnt work anymore
was ok in 1.1.13 and earlier 2.1 wasapi
it now tries to start playing n locks like it cant find the place to start playing
i uninstalled foobar and the dacs driver and reinstalled everything and still no joy
its a recent install of win 7 also ran fidleizer on it
i put the older wasapi 2.1 component back in and it works
its a recent install of win 7 also ran fidleizer on it
You might want to avoid using useless scam software like that (http://www.windowsxlive.net/fidelizer/), which affects system performance and stability.
You probably tried both "push" and "event" mode of WASAPI 3.0?
its a recent install of win 7 also ran fidleizer on it
You might want to avoid using useless scam software like that (http://www.windowsxlive.net/fidelizer/), which affects system performance and stability.
You probably tried both "push" and "event" mode of WASAPI 3.0?
i did try both yes...why do u say? is there a issue with doing that? could u be a bit more helpful and expand on that statement?
anyways this isnt about fidleizer. i can take that outta the equation anyways.
the older wasapi 2.1 works when put back in, could u expand on your statement of .. 'you prob tried both' instead of leaving me hanging thinking yes and and ....... what effect does that have? is it a known issue? etc
It seems there is a little cosmetic problem: WASAPIHost64 instead of foobar2000
(http://imageshack.us/a/img854/486/sonjr.png)
Using foobar2000 on Win7 x64
I have this bug also. When foobar is playing a song, and i double click other song, it hangs immediately. I see a process something like wasapihost64.exe, and cannot stop this process. I need to restart the computer and change back to V2.1.
If you cannot stop the process, it's stuck in a driver call; therefore it's the your driver that's broken. Also, posting exact info about your which exact soundcard you're using would be very helpful.
I can report after a few days usage that the new version works perfectly for me on Windows 7 x64. Both event and push modes seem flawless driving a Benchmark DAC through USB.
One difference I noted between v2.1 and v3 is that I could not increase the buffer size much above 1000mS using v2.1, but its full range is functional for me in v3.0. This is useful for handling imperfect data delivery systems (e.g. a Samba share on my NAS.) So, although v2.1 worked for me, I see v3.0 as a real improvement. Many thanks to Peter.
I can see the effect noted by Xin-Hong above but I don't see it as a bug. As described by Peter the WASAPI code now runs in a separate process, so that is what connects to the output device and therefore is displayed by Microsoft in the mixer window. If you are using WASAPI you could not use the mixer so the fact that it displays the name of the host process that has exclusive access to the output device is not really important. It might be nice if Microsoft indicated in some way that the whole mixer channel is non-functional once an exclusive mode application has claimed the output device.
Same issue as above. Cannot play files anymore with either WASAPI mode on my USB DAC.
The play speed increases at 1/10th of the speed. IE. After 10 seconds I see the timer go from 0:00 to 0:01.
Going to revert back to 2.1
what USB Dac are you using?
Anedio D1.
However its fed by a USB-to-COAX digital interface (Audio-gd DI-DSP) which uses the Tenor TE8802 chip (asynchronous USB)
If you cannot stop the process, it's stuck in a driver call; therefore it's the your driver that's broken. Also, posting exact info about your which exact soundcard you're using would be very helpful.
My system config
win7 x64
Creative 0404usb
Foobar 1.1.5
i hope the information is enough.
Maybe I have overlooked something but actually neither of the two playback methods doesnot produce any sound when trying to play SACD album (88.2kHz / 2channels / 24bps), although my soundcard is setup to play at 96kHz and 24bit:
(http://content.screencast.com/users/nobody5/folders/Snagit/media/8b842633-faa9-4fe8-8486-48cb16ea9d7c/Realtek%20HD%20Audio.png)
(http://content.screencast.com/users/nobody5/folders/Snagit/media/0e6e0a60-9e7c-42a8-83da-4a3876da4f91/10.05.2012-08.png)
I'm getting "Unrecoverable playback error: Unsupported stream format: 88200 Hz / 24-bit / 2 channels" message.
At standard CD album both method seems to play OK however. Is this due some missing component in my system or hardware limitation of my soudcard? I'm having Realtek HD audio.
Sounds like your soundcard does not support 88200Hz and you need to resample, or simply use DirectSound which resamples unsupported formats automatically for you.
See also: http://wiki.hydrogenaudio.org/index.php?ti...g_Windows_Mixer (http://wiki.hydrogenaudio.org/index.php?title=Bypassing_Windows_Mixer)
If you cannot stop the process, it's stuck in a driver call; therefore it's the your driver that's broken. Also, posting exact info about your which exact soundcard you're using would be very helpful.
My system config
win7 x64
Creative 0404usb
Foobar 1.1.5
i hope the information is enough.
I'm using the same gear and hv exactly the same problem. I had to switch back to WASAPI 2.1.
Surprisingly, my old Harman Kardon soundsticks (USB) works with WASAPI 3.0. I think it is a EMU 0404 driver issue.
I'm considering to upgrade to mytek 192 DSD DAC. Does WASAPI 3.0 work with it ?
If you cannot stop the process, it's stuck in a driver call; therefore it's the your driver that's broken. Also, posting exact info about your which exact soundcard you're using would be very helpful.
My system config
win7 x64
Creative 0404usb
Foobar 1.1.5
i hope the information is enough.
I'm using the same gear and hv exactly the same problem. I had to switch back to WASAPI 2.1.
Surprisingly, my old Harman Kardon soundsticks (USB) works with WASAPI 3.0. I think it is a EMU 0404 driver issue.
if it is really 0404 driver problem, i have no idea why wasapi 2.1 works.
Anyway, i am happy with 2.1, and can the component site keep 2.1 for us to download?
thanks for great work!
can I ask for feature request pls? There's problem when output sound via HDMI.
It's related to playback, when track changes or i do seek, the foobar interrupts sound and enables it again in a small moment (what is normal of course).
But it causes to reanitilize the reciever each time and the sound disappears for a second (what is right behavior of receiver when sound stream changes).
But that is the issue.
Is there a chance to do something like 'keep connection alive' or output digital silence, when foobar stops sound, within wasapi plugin? It would solve the problem.
*Also what I notice -
when I test Wasapi on Amd videocard it works 100% Perfect, for some reason it doesn't interrupt sound.
but wasapi with Nvidia and intelHd interrupt sound as i describe above and the problem is present
thank you,
Alex
Unrecoverable playback error: Unsupported stream format: 88200 Hz / 16-bit / 2 channels
WASAPI gives me this error in fb2k. Default settings. Win 7 64. FiiO E7 USB DAC with TI PCM2706 USB receiver.
It works fine when I play 16 / 44100 stuff but anything else and it just complains.
Unrecoverable playback error: Unsupported stream format: 88200 Hz / 16-bit / 2 channels
WASAPI gives me this error in fb2k. Default settings. Win 7 64. FiiO E7 USB DAC with TI PCM2706 USB receiver.
It works fine when I play 16 / 44100 stuff but anything else and it just complains.
You Fiio only supports upto 16 / 48000 output, you need to put a resampler in your playback DSP chain or use another output mode.
Cheers, I figured it had one built in like in the Winamp version. How do I make it so that the resampler is only active if the sampling rote is not 44,100 or 48,000? I don't want needless resampling.
The standard fb2k resampler, by default, won't touch anything at the exact same sample rate but AFAIK, you can only choose one sampling rate (44.1kHz, I guess is best for you, but 48 kHz material will be downsampled to 44.1 kHz too).
Perhaps someone else is aware of a resampler that lets the user either choose one specific sample rate (for non-standard sampling rates) or lets them select one or more allowable or target sample rates from the standard set (e.g. 32, 44.1 48 kHz and these three values each multiplied by 0.25, 0.5, 2, and 4) so that it will pass through anything at any supported target rate and will resample anything outside that to the nearest supported sample rate (e.g. an 8000 Hz WAV would upsample to 44.1kHz in your case, and an 88.2kHz FLAC would downsample to 48kHz but 44.1 and 48kHz samples would be unchanged).
I have recently got a problem.
There are some song with different sampling rate, e.g. 48KHz, 96KHz, 192KHz.
If I am playing 48KHz, and change other song with different sampling rate, foobar will hang immediately.
If I am playing 48KHz, and stop playing, and then change other song with different sampling rate, foobar will working properly.
So it is foobar problem or wasapi problem?
What soundcard are you using?
What soundcard are you using?
0404 usb in win7 64bit
Hi. I'm also having trouble with this version of the plugin and the 0404 usb, but on Win8 64bit (RTM). But I'm using the ASIO plugin and it works well so it does not bother me much.
What I've noticed with the new WASAPI plugin:
One bug was fixed - the issue from the previous version, when if I resumed playback from pause, there would be skipping in the audio until the playback is restarted or until seek.
The problems now - when playing stuff with different sample rates, foobar throws errors and plays nothing. Errors like "Device invalidated" or "Device in use" or something like that. I also noticed that if you are stubborn and just keep pressing Play, these two errors alternate and eventually (after I press play like 20 times) playback starts. Also weird is that when the playback finally starts, the default audio format in Windows' Sound panel for the emu 0404 usb changes to the sample rate of the played file. If I want to play a file with different sample rate, I have to go through all this again and the default format changes again.
But since the playback is absolutely fine on my integrated audio (Realtek), only the 0404 usb is having these problems, I would say that it is because of the drivers for the e-mu card, which are beta and haven't been updated since 2010... So probably the plugin is fine and the problem is with the emu's usb drivers.
Edit - Update: I just restarted my PC and all works fine now. The default format is not changing (I have set it to 24/96), playing files with different sampling rates works and e-mu control panel show correct sampling rate when playing stuff... I hope it stays this way.
Off-topic quick question:
When my soundcard's DAC is 24bit then to get the best sound I should select 24 bit output in Foobar output options, right? And the same applies to the ASIO driver's control panel, right? Just making sure...
following on from my earlier post
i tried it on a fresh install on a sep drive i had spare with foobar 1.1.17
event wasapi works for a bit then starts popping a bit etc so i switched to push and then nothing works again neither event or push with wasapi 3.0
yet on jriver both event and 'normal' wasapi work fine
so would this not mean foobar is the issue and not the drivers of the usb dac
Hi,
Any chance on getting WASAPI working with DFX (http://www.fxsound.com/dfx/) ?
When I try and play a song via DFX using WASAPI I get something like:
Opening track for playback: "D:\Music\Country Music\Taylor Swift\Red (2012)\CD 1\Taylor Swift - Starlight.flac"
Unrecoverable playback error: Unsupported stream format: 44100 Hz / 16-bit / 4 channels
Thanks,
Will
Wasapi output version 3.1 was released (http://www.foobar2000.org/components/view/foo_out_wasapi)
* Fixed playback getting stuck on audio stream format change. (different sample rates)
My system config
win7 x64
Creative 0404usb
Doesn't come with ASIO drivers? No need to mess around with WASAPI when you have native ASIO drivers...
The playback is getting stuck with the Emu 0404 usb even with the new 3.1 version (device invalidated, device in use). But I have 2 solutions:
1) Use ASIO instead. It's working flawlessly on my system (Win 8 pro x64), always.
2) Do not power the 0404 usb on while in Windows. The driver gets somehow confused if you start Windows with the 0404 usb turned off and turn it on after Windows' boot. Also, do not turn the 0404 usb off while in Windows unless you do not plan on using it until next boot. If I boot Windows with the 0404 usb on and do not turn it off and then on again while in Windows, I have no problems with WASAPI. I think it's the beta driver's problem.
New version: 3.2 beta 1
(beta link removed)
Changes:
- Different default hardware buffer size for event mode - known to work better with specific soundcards.
- Different detection of stream formats supported by the device:
- Does not try to play formats indicated by Windows as "unsupported" by default
- Probing for supported bit depth specs was known to cause problems with certain SPDIF receivers
- Old behavior can be re-enabled thru Advanced Preferences
Thank you very much for an update, Peter.
Thanks, Peter. This now works with my M-Audio Audiophile 192 card, if you're keeping a list.
Thanks for letting me know. The new version will be available thru auto-update shortly.
New version up. No changes from the beta.
New version up. No changes from the beta.
Thanks, works perfectly here.
I would suggest to put the latest version announcement in the first post. maybe start another "official" thread so you own that first thread?
Peter is free to edit my OP if he prefers to it that way. Of course, as an admin, he could do it even if I denied permission, but hey! Here it is.
In the meantime, I have updated the OP and subtitle to reflect this new version.
Last version works here with a MOTU 896 mkIII but i have to check "Attempt to play unsupported stream formats" in Advanced/Playback/WASAPI; If not i get a playback error "Unrecoverable playback error: Unsupported stream format 44100Hz/24-bit/2channels" when i try to play a 16bit/44.1kHz file. Didn't have this issue with v3.1.
If you're getting this error, Windows thinks your card isn't capable of playing this format. Perhaps you need to toggle some checkboxes in Windows audio control panel / device properties.
Hello! Today I updated wasapi to 3.2.1 and got 'Unrecoverable playback error: Unsupported stream format: 88200 Hz / 24-bit / 2 channels'
5 minutes ago with version 3.1 all was fine. Used spdif output to yamaha rx 671 in wasapi push mode.
Please help.
--
Win7 64 sp1. Asus xonar D1.
Hello! Today I updated wasapi to 3.2.1 and got 'Unrecoverable playback error: Unsupported stream format: 88200 Hz / 24-bit / 2 channels'
5 minutes ago with version 3.1 all was fine. Used spdif output to yamaha rx 671 in wasapi push mode.
Please help.
--
Win7 64 sp1. Asus xonar D1.
Just go in foobar2000 option then in Advanced/Playback/WASAPI check "Attempt to play unsupported stream formats".
Hello! Today I updated wasapi to 3.2.1 and got 'Unrecoverable playback error: Unsupported stream format: 88200 Hz / 24-bit / 2 channels'
5 minutes ago with version 3.1 all was fine. Used spdif output to yamaha rx 671 in wasapi push mode.
Please help.
--
Win7 64 sp1. Asus xonar D1.
Just go in foobar2000 option then in Advanced/Playback/WASAPI check "Attempt to play unsupported stream formats".
Thanks! It works, but I assume this is a bug in wasapi 3.2.1.
[/quote]
(...) but I assume this is a bug in wasapi 3.2.1.
[/quote]
Don't know where it come from but i've the same issue since v3.2.1
This goes for me too, though I have different sound-card & my error messages were for different sample rates:
"Last version works here with a MOTU 896 mkIII but i have to check "Attempt to play unsupported stream formats" in Advanced/Playback/WASAPI; If not i get a playback error "Unrecoverable playback error: Unsupported stream format 44100Hz/24-bit/2channels" when i try to play a 16bit/44.1kHz file. Didn't have this issue with v3.1."
Win8 64bit
M-Audio Audiophile 24/96
I have the "Unrecoverable playback error: Unsupported stream format" issues with this new WASAPI version on my two laptops (one with Realtek ALC269 and another with Connexant SmartAudio HD; both running Win7 x64), and setting "Attempt to play unsupported stream formats" checkbox doesn't work for me.
Please someone let me know where do I get previous version (it was working fine for me)? Maybe someone can upload previous release of WASAPI to some file sharing service?
I’m not preventing anyone from doing that for you, but it would be much more helpful if you were to provide as much information about your hardware and software configurations as possible so that it can hopefully be solved in future versions, rather than having to stay in the past.
No problem - I would be happy to provide any information needed, but not sure what's relevant. So just please let me know what kind of information could be of use. I could make full aida64 log but believe it could be overhelming.
On the other hand, to continue to listen my HD music now I would be highly thankful to anyone who's willing to share older version.
Just tried 3.2.2 - it's no good. Whereas before with 3.2.1 I could play any SACD decoded with parameters up to 176khz, 24bit, 5.1 (attempt to play unsupported formats unchecked), now foobar2000 throws a fit on all MC recordings that are not strict 5.1 but 5.0, 4.0, 3.0:
Unrecoverable playback error: Unsupported stream format: 176400 Hz / 24-bit / 5 channels (0x37)
My Yamaha RX-V3067 should and can handle anything thrown at it via HDMI.
Unfortunately, the previous version was overwritten by the updater, does anyone still have 3.2.1 for me? In case of a component like this which may or may not work for everybody, a link to a previous version on the official download page would be nice.
Here's the previous version until a fix is available: [attachment=7404:wasapi_3...pi_3.2.1.fb2k-component]
Bug hopefully fixed in 3.2.3. Thanks for the quick report.
Confirmed to work. Thanks for the quick update.
Hi,
first of all thanks for this component.
I would like to know if is it possible to have smooth transitions on skip, prev. and next operations sending silence to the device instead of reset the stream.
I'm using the latest version of foobar2000 and wasapi componenet (event mode, 10ms buffer), my dac is NwAvGuy ODAC connected through netgear xaub2511.
I tested JRiver WASAPI and it seems to never break the stream to the device on skip (checked with Wireshark). Foobar2000 WASAPI seems to stop the previous stream and start a new one.
Thanks.
what is "bit-exact output" and how is it better than using the default output?
the muting other sounds thing doesn't seem like something desirable
It just bypasses Windows’ mixer and other potential sources of alterations to the audio stream, none of which will be audible anyway. It also, as you have noted, comes with some restrictions upon other things. Generally, if you don’t know that you need it, you don’t need it.
It could be most useful for things like lossless transfer to an external digital device (e.g. DAC) and/or a device that decodes a signal encoded within a ‘normal’ stream that might be scrambled if the stream is changed even slightly (e.g. DTS surround-sound).
Don’t need any of these things? You should be able to continue with the default DirectSound with no worries.
Thank you Peter.
An heads up: After updating Foobar2k to version 1.2.4beta1 WASAPI output (both push and event versions) causes a program crash as soon as playback starts. ASIO and DS outputs still work without fault.
Illegal operation:
Code: C000001Dh, flags: 00000000h, address: 009698D6h
Call path not available.
Code bytes (009698D6h):
00969896h: 8B 7C 24 14 8B EA F3 0F 10 2D 7C 99 A8 00 F3 0F
009698A6h: 10 35 00 9C A8 00 F3 0F 10 7C 24 18 0F 10 25 04
009698B6h: 9C A8 00 0F C6 ED 00 0F C6 F6 00 0F C6 FF 00 85
009698C6h: ED 74 30 0F 10 06 83 C6 10 0F 59 C7 66 0F 5B C0
009698D6h: 66 0F 38 3D C5 66 0F 38 39 C6 66 0F 38 00 C4 F2
009698E6h: 0F 11 07 66 0F 70 C0 E6 F3 0F 11 47 08 4D 8D 7F
009698F6h: 0C 75 D0 5B 5D 5F 5E C2 08 00 56 57 55 53 8B F1
00969906h: 8B 7C 24 14 8B EA F3 0F 10 2D 7C 99 A8 00 F3 0F
Stack (1103FC64h):
1103FC44h: 00000000 FFFFFD34 000002E4 FFFFFD34
1103FC54h: 000002CC 00000019 00000000 1103FC54
1103FC64h: 079F4730 1103FCD0 0000089E 1103FD18
1103FC74h: 0096A0ED 0F1C2A38 4B000000 1103FD18
1103FC84h: 057588B8 057588A8 0096A34D 0F1C2A38
1103FC94h: 0575CAD0 4B000000 00800000 057588A8
1103FCA4h: 0000089E 0109001F 03000300 1103FCE4
1103FCB4h: 03BE6F6E 057588B8 02287C38 00000000
1103FCC4h: 1103FD68 00A6A2F8 00000000 1103FD74
1103FCD4h: 03BE25B2 1103FD18 1103FD44 00000018
1103FCE4h: 00000018 00000000 3F800000 05758944
1103FCF4h: 057588A8 00000000 03BFD278 00000000
1103FD04h: 00000000 00000000 00000000 00000000
1103FD14h: 00000000 03BFD338 05758988 0000044F
1103FD24h: 0575CAD0 03BFD2AC 0F1C2A38 000019DA
1103FD34h: 000019DA 0000AC44 00000002 00000003
1103FD44h: 03BFD328 1103FD28 00000000 00000000
1103FD54h: 000008C8 0000044F 00000006 00000000
1103FD64h: 03BE24A5 1103FD94 03BF649B 00000002
1103FD74h: 1103FDA0 03BE27D5 0000044F 00000002
Registers:
EAX: 0575CAD0, EBX: 079F4730, ECX: 0575CAD0, EDX: 00000227
ESI: 0575CAE0, EDI: 0F1C2A38, EBP: 00000227, ESP: 1103FC64
Crash location:
Module: foobar2000
Offset: 198D6h
Loaded modules:
foobar2000 loaded at 00950000h - 00B0F000h
ntdll loaded at 77A90000h - 77C10000h
snxhk loaded at 72080000h - 720BF000h
KERNEL32 loaded at 75F30000h - 76040000h
KERNELBASE loaded at 76530000h - 76577000h
COMCTL32 loaded at 74C00000h - 74D9E000h
msvcrt loaded at 76EE0000h - 76F8C000h
GDI32 loaded at 75E20000h - 75EB0000h
USER32 loaded at 76CA0000h - 76DA0000h
ADVAPI32 loaded at 76A00000h - 76AA0000h
sechost loaded at 76E90000h - 76EA9000h
RPCRT4 loaded at 76440000h - 76530000h
SspiCli loaded at 75170000h - 751D0000h
CRYPTBASE loaded at 75160000h - 7516C000h
LPK loaded at 769F0000h - 769FA000h
USP10 loaded at 763A0000h - 7643D000h
SHLWAPI loaded at 76930000h - 76987000h
DSOUND loaded at 74DC0000h - 74E32000h
ole32 loaded at 76580000h - 766DC000h
WINMM loaded at 74EE0000h - 74F12000h
POWRPROF loaded at 71DB0000h - 71DD5000h
SETUPAPI loaded at 76AD0000h - 76C6D000h
CFGMGR32 loaded at 76C70000h - 76C97000h
OLEAUT32 loaded at 76860000h - 768EF000h
DEVOBJ loaded at 766E0000h - 766F2000h
UxTheme loaded at 74E60000h - 74EE0000h
dbghelp loaded at 73430000h - 7351B000h
SHELL32 loaded at 751D0000h - 75E1A000h
zlib1 loaded at 62E80000h - 62E9E000h
shared loaded at 6D7D0000h - 6D7FB000h
imagehlp loaded at 76EB0000h - 76EDA000h
COMDLG32 loaded at 75EB0000h - 75F2B000h
CRYPT32 loaded at 770B0000h - 771CE000h
MSASN1 loaded at 76390000h - 7639C000h
Secur32 loaded at 73880000h - 73888000h
gdiplus loaded at 71DE0000h - 71F70000h
WINHTTP loaded at 733D0000h - 73428000h
webio loaded at 73360000h - 733AF000h
apphelp loaded at 73580000h - 735CC000h
AcGenral loaded at 6DFF0000h - 6E208000h
samcli loaded at 6F1D0000h - 6F1DF000h
MSACM32 loaded at 6F1B0000h - 6F1C4000h
VERSION loaded at 73540000h - 73549000h
sfc loaded at 73520000h - 73523000h
sfc_os loaded at 6FAC0000h - 6FACD000h
USERENV loaded at 726E0000h - 726F7000h
profapi loaded at 73890000h - 7389B000h
dwmapi loaded at 74E40000h - 74E53000h
urlmon loaded at 76050000h - 76161000h
iertutil loaded at 76170000h - 76329000h
WININET loaded at 76F90000h - 770AB000h
Normaliz loaded at 76DF0000h - 76DF3000h
MPR loaded at 71F70000h - 71F82000h
IMM32 loaded at 76330000h - 76390000h
MSCTF loaded at 76700000h - 767CC000h
RTSSHooks loaded at 10000000h - 10024000h
MSVCR90 loaded at 736E0000h - 73783000h
foo_plorg loaded at 6D7A0000h - 6D7CA000h
MSVCP100 loaded at 6D4A0000h - 6D509000h
MSVCR100 loaded at 6D3E0000h - 6D49F000h
foo_freedb2 loaded at 6D390000h - 6D3DE000h
foo_uie_vis_channel_spectrum loaded at 00210000h - 0024D000h
MSIMG32 loaded at 74DB0000h - 74DB5000h
foo_input_dts loaded at 6D320000h - 6D383000h
foo_uie_vis_peakmeter_spectrum loaded at 004C0000h - 004FF000h
foo_cdda loaded at 6CDA0000h - 6CDEF000h
foo_scheduler loaded at 69DA0000h - 69E77000h
foo_fileops loaded at 6CAF0000h - 6CB3A000h
foo_uie_elplaylist loaded at 69D20000h - 69D93000h
foo_out_asio loaded at 005D0000h - 00602000h
foo_uie_lyrics3 loaded at 02DB0000h - 02E7A000h
foo_texttools loaded at 69CE0000h - 69D14000h
foo_unpack loaded at 6CFB0000h - 6CFDF000h
foo_ui_columns loaded at 03690000h - 03820000h
foo_ui_std loaded at 69BF0000h - 69CD9000h
foo_uie_esplaylist loaded at 68AE0000h - 68B48000h
foo_out_upnp loaded at 68A80000h - 68AD4000h
IPHLPAPI loaded at 72FF0000h - 7300C000h
NSI loaded at 00940000h - 00946000h
WINNSI loaded at 73550000h - 73557000h
WS2_32 loaded at 768F0000h - 76925000h
foo_ac3 loaded at 6CE10000h - 6CE41000h
foo_converter loaded at 68A00000h - 68A7E000h
foo_playcount loaded at 69BB0000h - 69BEE000h
foo_albumlist loaded at 689A0000h - 689FC000h
foo_dsp_eq loaded at 68960000h - 68996000h
foo_uie_albumlist loaded at 024D0000h - 02513000h
foo_channel_mixer loaded at 02630000h - 0266A000h
foo_upnp loaded at 67F40000h - 681F8000h
foo_dsp_resampler loaded at 040F0000h - 04248000h
foo_input_tak loaded at 68910000h - 68951000h
tak_deco_lib loaded at 027E0000h - 02801000h
foo_uie_biography loaded at 688B0000h - 68908000h
foo_rgscan loaded at 68650000h - 6869B000h
foo_keep_queue loaded at 6E4E0000h - 6E4EF000h
foo_dsp_xgeq loaded at 68610000h - 6864C000h
foo_uie_wsh_panel_mod loaded at 68520000h - 6860C000h
foo_input_std loaded at 683B0000h - 6851E000h
avcodec-fb2k-54 loaded at 04D00000h - 04FA2000h
avutil-fb2k-52 loaded at 635C0000h - 635F9000h
foo_input_monkey loaded at 02900000h - 02949000h
foo_dsp_crossfader loaded at 02B10000h - 02B42000h
foo_masstag loaded at 02E80000h - 02ED4000h
foo_uie_panel_splitter loaded at 03520000h - 03579000h
foo_httpcontrol loaded at 68340000h - 683AD000h
WSOCK32 loaded at 73560000h - 73567000h
foo_quicksearch loaded at 682E0000h - 68337000h
WindowsCodecs loaded at 6E360000h - 6E490000h
foo_cuefilter loaded at 02D70000h - 02D99000h
foo_vis_shpeck loaded at 68290000h - 682D1000h
foo_dsp_std loaded at 67F00000h - 67F35000h
foo_queuecontents loaded at 03A20000h - 03A8E000h
foo_out_wasapi loaded at 03BE0000h - 03C09000h
foo_wave_seekbar loaded at 67690000h - 6782A000h
foo_vst loaded at 67CD0000h - 67D24000h
CLBCatQ loaded at 76E00000h - 76E83000h
DropboxExt.17 loaded at 04350000h - 04372000h
MSVCP90 loaded at 73650000h - 736DE000h
EhStorShell loaded at 69B70000h - 69BA1000h
PROPSYS loaded at 71C70000h - 71D65000h
ntshrui loaded at 6CA20000h - 6CA90000h
srvcli loaded at 72870000h - 72889000h
cscapi loaded at 6C9E0000h - 6C9EB000h
slc loaded at 6C9D0000h - 6C9DA000h
SXS loaded at 6D2C0000h - 6D31F000h
frontend_direct2d loaded at 67630000h - 67688000h
d2d1 loaded at 672E0000h - 67627000h
frontend_direct3d9 loaded at 67AD0000h - 67B33000h
d3d9 loaded at 686B0000h - 68873000h
d3d8thk loaded at 686A0000h - 686A6000h
d3dx9_42 loaded at 670F0000h - 672D5000h
SciLexer loaded at 67040000h - 670E2000h
AhAScr loaded at 6C9F0000h - 6CA17000h
aswCmnBS loaded at 737F0000h - 7384C000h
aswCmnOS loaded at 737D0000h - 737EE000h
aswCmnIS loaded at 73790000h - 737C1000h
Aavm4h loaded at 73030000h - 730F3000h
PSAPI loaded at 76040000h - 76045000h
AavmRpch loaded at 731C0000h - 731E5000h
ashBase loaded at 735D0000h - 7364E000h
aswEngLdr loaded at 73530000h - 7353E000h
ashTask loaded at 73230000h - 73258000h
aswAux loaded at 73260000h - 73308000h
aswProperty loaded at 731F0000h - 7322F000h
avastIP loaded at 73010000h - 73022000h
jscript loaded at 66F80000h - 67032000h
aswJsFlt loaded at 68880000h - 688A6000h
CRYPTSP loaded at 72660000h - 72676000h
rsaenh loaded at 725C0000h - 725FB000h
RpcRtRemote loaded at 72EF0000h - 72EFE000h
tiptsf loaded at 66F20000h - 66F78000h
mswsock loaded at 726A0000h - 726DC000h
wshtcpip loaded at 72690000h - 72695000h
dhcpcsvc loaded at 72310000h - 72322000h
head-fit-lite loaded at 0CAC0000h - 0CED5000h
WINSPOOL loaded at 71F90000h - 71FE1000h
DH_BIQUAD loaded at 0AA00000h - 0AA27000h
DH_VOLTAGETOFLOAT loaded at 0AAB0000h - 0AAC3000h
DH_MODULEKEY loaded at 0AAD0000h - 0AAE5000h
DH_FLOATTOBOOL loaded at 0ABA0000h - 0ABB2000h
EZMATH4 loaded at 0BC30000h - 0BC49000h
SC_1P1Z_XOVER loaded at 0BC50000h - 0BC65000h
KDL_SAMPLERATE_V loaded at 0BC70000h - 0BC83000h
KDL_B2GB loaded at 0BDC0000h - 0BDD3000h
DH_BOOLTOFLOAT loaded at 0BDE0000h - 0BDF2000h
Audiocation Equalizer (stereo) loaded at 0DE00000h - 0DFEC000h
dhcpcsvc6 loaded at 72330000h - 7233D000h
sud loaded at 66E60000h - 66F1B000h
ADVPACK loaded at 67ED0000h - 67EFE000h
DUI70 loaded at 66DA0000h - 66E52000h
explorerframe loaded at 66C30000h - 66D9F000h
DUser loaded at 67CA0000h - 67CCF000h
DLL_Wheel4D loaded at 6F250000h - 6F272000h
MMDevApi loaded at 71D70000h - 71DA9000h
wship6 loaded at 72680000h - 72686000h
DNSAPI loaded at 72530000h - 72574000h
mdnsNSP loaded at 724F0000h - 72515000h
rasadhlp loaded at 724A0000h - 724A6000h
fwpuclnt loaded at 724B0000h - 724E8000h
avrt loaded at 6DC50000h - 6DC57000h
PatchMemory loaded at 0BF40000h - 0BF68000h
Stack dump analysis:
Address: 0096A0EDh (foobar2000+1A0EDh)
Address: 0096A34Dh (foobar2000+1A34Dh)
Address: 03BE6F6Eh (foo_out_wasapi+6F6Eh), symbol: "foobar2000_get_interface" (+B2Eh)
Address: 00A6A2F8h (foobar2000+11A2F8h)
Address: 03BE25B2h (foo_out_wasapi+25B2h)
Address: 03BFD278h (foo_out_wasapi+1D278h), symbol: "foobar2000_get_interface" (+16E38h)
Address: 03BFD338h (foo_out_wasapi+1D338h), symbol: "foobar2000_get_interface" (+16EF8h)
Address: 03BFD2ACh (foo_out_wasapi+1D2ACh), symbol: "foobar2000_get_interface" (+16E6Ch)
Address: 03BFD328h (foo_out_wasapi+1D328h), symbol: "foobar2000_get_interface" (+16EE8h)
Address: 03BE24A5h (foo_out_wasapi+24A5h)
Address: 03BF649Bh (foo_out_wasapi+1649Bh), symbol: "foobar2000_get_interface" (+1005Bh)
Address: 03BE27D5h (foo_out_wasapi+27D5h)
Address: 03BE280Bh (foo_out_wasapi+280Bh)
Address: 03BF6809h (foo_out_wasapi+16809h), symbol: "foobar2000_get_interface" (+103C9h)
Address: 03BE22F9h (foo_out_wasapi+22F9h)
Address: 03BF687Fh (foo_out_wasapi+1687Fh), symbol: "foobar2000_get_interface" (+1043Fh)
Address: 03BE3999h (foo_out_wasapi+3999h)
Address: 03BF6360h (foo_out_wasapi+16360h), symbol: "foobar2000_get_interface" (+FF20h)
Address: 03BE39BBh (foo_out_wasapi+39BBh)
Address: 03BE9A64h (foo_out_wasapi+9A64h), symbol: "foobar2000_get_interface" (+3624h)
Address: 03BEB290h (foo_out_wasapi+B290h), symbol: "foobar2000_get_interface" (+4E50h)
Address: 03BE9AEEh (foo_out_wasapi+9AEEh), symbol: "foobar2000_get_interface" (+36AEh)
Address: 75F433AAh (KERNEL32+133AAh), symbol: "BaseThreadInitThunk" (+12h)
Address: 77AC9EF2h (ntdll+39EF2h), symbol: "RtlInitializeExceptionChain" (+63h)
Address: 75F67717h (KERNEL32+37717h), symbol: "UnhandledExceptionFilter" (+0h)
Address: 75F67717h (KERNEL32+37717h), symbol: "UnhandledExceptionFilter" (+0h)
Address: 77B071D5h (ntdll+771D5h), symbol: "WinSqmSetIfMaxDWORD" (+31h)
Address: 77AC9EC5h (ntdll+39EC5h), symbol: "RtlInitializeExceptionChain" (+36h)
Address: 03BE9A8Ah (foo_out_wasapi+9A8Ah), symbol: "foobar2000_get_interface" (+364Ah)
Address: 03BE9A8Ah (foo_out_wasapi+9A8Ah), symbol: "foobar2000_get_interface" (+364Ah)
Address: 685421CDh (foo_uie_wsh_panel_mod+221CDh)
Address: 68636952h (foo_dsp_xgeq+26952h), symbol: "foobar2000_get_interface" (+195F2h)
Address: 10000000h (RTSSHooks+0h)
Address: 00960000h (foobar2000+10000h)
Environment:
App: foobar2000 v1.2.4 beta 1
UI: Columns UI 0.3.8.8
Components:
Core (2013-03-18 12:23:28 UTC)
foobar2000 core 1.2.4 beta 1
foo_ac3.dll (2012-09-09 19:48:27 UTC)
AC3 decoder 0.9.7
foo_albumlist.dll (2013-02-11 11:28:58 UTC)
Album List 4.5
foo_cdda.dll (2013-03-07 09:48:32 UTC)
CD Audio Decoder 3.0
foo_channel_mixer.dll (2008-03-12 09:37:47 UTC)
Channel Mixer 0.9.6.5
foo_converter.dll (2013-03-18 12:22:06 UTC)
Converter 1.5
foo_cuefilter.dll (2013-02-16 11:18:17 UTC)
CUE Playlist Filter 0.1.7.0
foo_dsp_crossfader.dll (2010-01-13 19:46:10 UTC)
Gapless Crossfader 1.3.4.1
foo_dsp_eq.dll (2013-02-11 11:28:58 UTC)
Equalizer 1.0
foo_dsp_resampler.dll (2012-08-17 18:41:42 UTC)
SoX Resampler 0.8.0
foo_dsp_std.dll (2013-02-11 11:28:50 UTC)
Standard DSP Array 1.2
foo_dsp_xgeq.dll (2012-02-13 12:17:29 UTC)
Graphic Equalizer 0.3.7
foo_fileops.dll (2013-02-11 11:28:10 UTC)
File Operations 2.2
foo_freedb2.dll (2013-02-11 11:27:56 UTC)
Online Tagger 0.7
foo_httpcontrol.dll (2013-01-27 19:33:14 UTC)
HTTP Control 0.97.13
foo_input_dts.dll (2013-02-10 23:53:10 UTC)
DTS decoder 0.3.1
foo_input_monkey.dll (2012-09-09 19:48:27 UTC)
Monkey's Audio Decoder 2.1.6
foo_input_std.dll (2013-03-18 12:22:16 UTC)
Standard Input Array 1.0
foo_input_tak.dll (2013-03-14 15:11:26 UTC)
TAK Decoder 0.4.6 beta 2
foo_keep_queue.dll (2011-08-03 23:29:28 UTC)
Keep Queue 0.3.5
foo_masstag.dll (2010-07-17 16:50:37 UTC)
Masstagger 1.8.4
foo_out_asio.dll (2013-03-12 15:11:06 UTC)
ASIO support 2.1.2
foo_out_upnp.dll (2013-03-18 00:46:48 UTC)
UPnP MediaRenderer Output 1.0 beta 4
foo_out_wasapi.dll (2013-03-09 21:26:37 UTC)
WASAPI output support 3.2.3
foo_playcount.dll (2011-08-30 19:57:43 UTC)
Playback Statistics 3.0.2
foo_plorg.dll (2011-09-17 00:23:26 UTC)
Playlist Organizer 2.4
foo_queuecontents.dll (2012-03-20 23:45:53 UTC)
Queue Contents Editor 0.5.1
foo_quicksearch.dll (2012-11-06 01:54:29 UTC)
Quick Search Toolbar 3.4
foo_rgscan.dll (2013-03-18 12:21:32 UTC)
ReplayGain Scanner 2.2
foo_scheduler.dll (2013-02-10 23:53:10 UTC)
Scheduler 4.11
foo_texttools.dll (2010-11-07 17:51:39 UTC)
Text Tools 1.0.5
foo_ui_columns.dll (2011-02-27 20:23:00 UTC)
Columns UI 0.3.8.8
foo_ui_std.dll (2013-03-18 12:22:00 UTC)
Default User Interface 0.9.5
foo_uie_albumlist.dll (2009-06-13 22:49:19 UTC)
Album list panel 0.3.5
foo_uie_biography.dll (2010-12-13 20:38:26 UTC)
Biography View 0.4.2.4
foo_uie_elplaylist.dll (2011-01-06 09:07:35 UTC)
ELPlaylist 0.6.9.1.2(beta)
foo_uie_esplaylist.dll (2011-02-19 08:20:42 UTC)
EsPlaylist 0.1.3.7
foo_uie_lyrics3.dll (2012-09-09 19:48:27 UTC)
Lyric Show Panel 3 0.3.5.2
foo_uie_panel_splitter.dll (2010-05-27 11:03:02 UTC)
Panel Stack Splitter 0.3.8.3(alpha)
foo_uie_vis_channel_spectrum.dll (2010-03-07 08:23:55 UTC)
Channel Spectrum panel 0.17.2
foo_uie_vis_peakmeter_spectrum.dll (2010-03-07 08:24:47 UTC)
Peakmeter Spectrum Visualisation 0.2.0.0 beta
foo_uie_wsh_panel_mod.dll (2012-10-16 00:45:19 UTC)
WSH Panel Mod 1.5.6
foo_unpack.dll (2013-02-11 11:28:10 UTC)
ZIP/GZIP/RAR Reader 1.6
foo_upnp.dll (2013-02-22 14:30:13 UTC)
UPnP/DLNA Renderer, Server, Control Point 0.99.45
foo_vis_shpeck.dll (2009-09-28 10:32:16 UTC)
Shpeck - Winamp vis plugins wrapper 0.3.7
foo_vst.dll (2013-02-21 01:01:37 UTC)
VST 2.4 adapter 0.9.0.3
foo_wave_seekbar.dll (2012-12-18 15:56:12 UTC)
Waveform seekbar 0.2.29
Recent events:
Graphic Equalizer: initialized (SSE support: 3)
Autoplaylists initialized in: 0:00.131501
"Rating >2/5" : 0:00.027402
"Recent Toegevoegd" : 0:00.104060
Startup time : 0:02.096036
foo_upnp: created 12496 path registry entries in 0.594s
WSH Panel Mod: Warning: Obsolete: Please use AppendTo() method to create sub menu instead of AppendMenuItem()
foo_upnp: loaded Media Library tree in 5.811s
Opening track for playback: "Z:\Downloads\uTorrent\Voltooid\A State Of Trance 2013 (Mixed By Armin van Buuren) (Inspiron)\Split Mix\CD 1\08 Aly & Fila feat. Tricia McTeague - Speed Of Sound.mp3"
WSH Panel Mod: Warning: Obsolete: window.CreateTimerInterval() is now obsolete, please use window.SetInterval() in new script.
Machine specifications:
OS: Windows 6.1.7601 Service Pack 1 x64
CPU: Intel® Core™2 Quad CPU Q6600 @ 2.40GHz, features: MMX SSE SSE2 SSE3
Audio: Speakers (ASUS Xonar DG Audio Device); S/PDIF Pass-through Device (ASUS Xonar DG Audio Device)
First things first, Peter, love this plugin. So much so, the first time I have an issue with it is the reason I finally decided to register and post something. Thank you for the plugin, can't live without the the difference in sound over DS.
Will post a crash dump in a bit... But I found a bit of info that may help without the crash dump even. The crash only occurs when outputting in 24-bit. Dropped down to 16-bit and it works fine in 1.2.4 beta 1.
If remove old foo_out_wasapi.dll.cfg - no crashes, but WASAPI doesn't work: Unrecoverable playback error: Device invalidated (push/event/16/24/misc buffer - no difference). /foo v1.2.4 beta 1 + wasapi v3.2.3
Sounds like new SSE code for 24-bit audio handling in fb2k 1.2.4 is acting funny on specific CPUs. Please stick with fb2k 1.2.3 until this is fixed.
This is not a problem with the WASAPI component, it's a bug in fb2k 1.2.4 beta 1.
Update: beta 2 out, bug should be fixed, please test.
can't live without the the difference in sound over DS.
It appears you have not read #8 of the Terms of Service to which you agreed during registration, nor the official FAQ for foobar2000, nor any of the countless threads here where it has been explained that different output methods do not produce differing quality of sound.
Please retract this claim – acknowledging that it is almost certainly based solely upon expectation bias/placebo resulting from sighted comparison – unless you can provide objective evidence for it, which would be revelatory.
Sounds like new SSE code for 24-bit audio handling in fb2k 1.2.4 is acting funny on specific CPUs. Please stick with fb2k 1.2.3 until this is fixed.
This is not a problem with the WASAPI component, it's a bug in fb2k 1.2.4 beta 1.
Update: beta 2 out, bug should be fixed, please test.
Downloaded beta 3, problem has been fixed. No more crashes with Wasapi. That was a fast fix!
As for the sound quality claim above.... can't it be possible using Wasapi bypasses some detrimental DSPs/'sound enhancements'/effects/low quality resampling algorithm that may be part of someone's souncard's drivers and/or control panel software? Still such a claim would need to be ABX tested of course. Lack of evidence does not mean there's evidence for the contrary however (i.e. a hard statement like "there is no difference" without objective evidence is just as wrong, you don't know which soundcard/drivers he's using and how these might affect the SQ)
can't live without the the difference in sound over DS.
It appears you have not read #8 of the Terms of Service to which you agreed during registration, nor the official FAQ for foobar2000, nor any of the countless threads here where it has been explained that different output methods do not produce differing quality of sound.
Please retract this claim – acknowledging that it is almost certainly based solely upon expectation bias/placebo resulting from sighted comparison – unless you can provide objective evidence for it, which would be revelatory.
Perhaps "..can't live without the the difference in sound vs DS I perceive..." ?
Didn't think it was much to say "difference" in sound as it not really a statement of me saying it is better or worse then something as for quality. Guessing my use of the word "over" may have lead to that. Although the output device being headphones/speakers ultimately can have such an effect. I see my entire PC (sound card/hardware, drivers, and yes foobar2000 as part of the said output device). Will still say I am happier with the net effect of bypassing the "Windows’ mixer and other potential sources of alterations to the audio stream, none of which will be audible anyway".
In this case, I do not care for a few things that the bit of addons the maker of my sound card threw into the mix that has possibly caused any alterations audible or otherwise to myself or someone else listening.
With that said, somewhat expected the 24 bit playback was related to the 24 bit changes in the latest beta. 1.2.4 beta 3 came so fast I didn't even see beta 2. Anyway, same confirmation. 24 bit playback is again fine with 1.2.4 beta 3.
Can we have Default WASAPI Event mode (like JRiver)? Hence I dont have to go and set preferences for my external USB sound card all the time.
Regards.
Hello.
Is it possible to redirect output to DirectSound (or other output) in cases when WASAPI plugin detects that certain output mode (i.e. sampling frequency & bit depth combination) are not supported by HW or driver?
It would be very helpful in a typical case when the sound device supports sampling rates of 44100 and 96000, but doesn't support 88200 -- otherwise one need to switch to DS manually each time when 88200 content is played back; and then swith back to WASAPI
It would be very helpful in a typical case when the sound device supports sampling rates of 44100 and 96000, but doesn't support 88200 -- otherwise one need to switch to DS manually each time when 88200 content is played back; and then swith back to WASAPI
You could use Resampler (SoX) mod2. You can specify which bitrates to resample.
OR
The regular mod lets you specify which bitrates NOT to resample.
That way, anything that isn't handled by your device can be resampled to a rate that is. No need to change between WASAPI and DS.
http://www.hydrogenaudio.org/forums/index....showtopic=67373 (http://www.hydrogenaudio.org/forums/index.php?showtopic=67373)
...That way, anything that isn't handled by your device can be resampled to a rate that is. ...
Thanks a lot!
Hey, I don't post here much, but I thought I'd bring this up because I'm frankly baffled as to why this happens with foobar's WASAPI component.
Computer Specs: Windows 8 Pro, Realtek Onboard Audio, M-Audio Fastrack USB; computer sound settings are set to 16-bit, 44khz playback
The issue: When playing some files on my computer, every now and then the sample rate changes depending on the source file. When using WASAPI, foobar will quit and say "Unrecoverable playback error: Unsupported stream format: 22050 Hz / 16-bit / 2 channels". This is just one possibility...it hates any 24-bit 96khz files from HDTracks as well. It doesn't matter if WASAPI is in push/event mode, and it does not matter which device I use, onboard or USB sound.
Now, you must be thinking, well, its because your computer is set to 16-bit 44khz. If that's so, why does the WASAPI components in other media players (namely AIMP and xmplay) not choke on these files? They play them as if there's nothing fishy or automatically adjust for the different in bit depth and sample rate. Only foobar stops on me. Any ways to prevent foobar from stopping when it hits one of these files?
Any ways to prevent foobar from stopping when it hits one of these files?
The exhaustive solution is just two posts above yours.
Please take an advice as a rule: to read few last pages plus the first post of any forum thread before asking a question.
80+% of questions will be answered even before you ask
Just missed that post I guess! Oops! Well, anyway, the SOX resampler works great and I'm not having any major issues now with odd sampling rates and WASAPI.
thanks for great work!
can I ask for feature request pls? There's problem when output sound via HDMI.
It's related to playback, when track changes or i do seek, the foobar interrupts sound and enables it again in a small moment (what is normal of course).
But it causes to reanitilize the reciever each time and the sound disappears for a second (what is right behavior of receiver when sound stream changes).
But that is the issue.
Is there a chance to do something like 'keep connection alive' or output digital silence, when foobar stops sound, within wasapi plugin? It would solve the problem.
*Also what I notice -
when I test Wasapi on Amd videocard it works 100% Perfect, for some reason it doesn't interrupt sound.
but wasapi with Nvidia and intelHd interrupt sound as i describe above and the problem is present
thank you,
Alex
Please, please, please fix this bug! I can't use WASAPI in Foobar because every time I do a manual track change, the first second or so of the song gets cut off. This is due to the nVidia "silent stream bug" and is only fixed by changing the behaviour to output silence instead of interrupting the stream. Every time the stream is interrupted and restarted, the receiver has to "lock on" to the signal again and thus you miss the first second or so of audio.
This can be fixed using third party software in DirectSound mode but not WASAPI. From what I've read, it's fixed in Media Monkey and JRiver already!
I was going to start a new thread, but this one might be better for my problem...
I have a Musica Pristina music server that uses Windows8 and foobar2000 as the file control interface. I have been accessing the server to rip and play music with a windows wireless laptop using remote desktop and the servers IP address. That all works fine, but I bought an IPad Mini and installed Jump so that I could have a more mobile controller. I am also having Jump access the server via the IP address (not Google), and that works fine also, but for one small issue, actually it is a big issue. Keep in mind that the Ipad will be dedicated to being a controller, nothing else.
Foobar users will know that in the file-preferences-playback-output menu, you have to pick an output device. Once my NAD amp is powered up, foobar normally sees it and offers it as a selection, in my case it is "WASAPI (event)-speakers (2-NAD USB Audio)" That happens when I am using the laptop and Remote Desktop to see the server, but it does NOT offer that output option when using the IPAD with Jump to access the server. If I immediately take control from the IPad and enter the server with the Laptop, everything is normal and the output option for my NAD is visible, grab control back with the IPad/jump, and the option disappears. Needless to say, without that output option, I cannot make the server/foobar play music with the IPad, only with the laptop. I can, however, do everything else, including ripping CD's.
I was hoping someone else may have had this issue and figured out a resolution.
Windows 8 x64, Realtek High Definition Audio on board, Schiit Audio Bifrost USB (GEN 2) using USB to connect to computer. foobar2000 v1.29 + WASAPI v3.2.3
DS and WASAPI (push) are working, but after configuring WASAPI (event) to the Bifrost and attempting to play the same FLAC and I'm prompted with an error. "Unrecoverable playback error: Invalid argument"
Playback devices -> Bitfrost Properties -> Advanced Tab
Default Format set to 24 bit, 192000 Hz (Studio Quality)
Exclusive Mode options checked: Allow applications to take exclusive control of this device, Give exclusive mode applications priority
I have tried configuring the Bitfrost Properties to use various formats and bitrates in the 16 bit and 24 bit space. Am I overlooking something and making a newbie mistake or is this a bug? Help! I would love to explore bit-perfect playback.
I'm using WASAPI 3.2.3, FB2K 1.2.9 and SoX Resampler Mod.
Under Advanced > Playback > WASAPI, there is no checkbox for "Attempt to play unsupported stream formats". Where can I find this? I'm trying to make it play 88.2khz but 96khz is all it can play right now.
Windows 8 x64, Realtek High Definition Audio on board, Schiit Audio Bifrost USB (GEN 2) using USB to connect to computer. foobar2000 v1.29 + WASAPI v3.2.3
DS and WASAPI (push) are working, but after configuring WASAPI (event) to the Bifrost and attempting to play the same FLAC and I'm prompted with an error. "Unrecoverable playback error: Invalid argument"
Playback devices -> Bitfrost Properties -> Advanced Tab
Default Format set to 24 bit, 192000 Hz (Studio Quality)
Exclusive Mode options checked: Allow applications to take exclusive control of this device, Give exclusive mode applications priority
I have tried configuring the Bitfrost Properties to use various formats and bitrates in the 16 bit and 24 bit space. Am I overlooking something and making a newbie mistake or is this a bug? Help! I would love to explore bit-perfect playback.
UPDATE: This was a driver issue. It turns out Schiit released an updated driver the same week I posted. After installing the updated "Schiit_USB_1_03" drivers, WASAPI (event) playback is functional.
I downloaded this (http://www.foobar2000.org/components/view/foo_out_wasapi) version (3.2.3, released on 2013-03-09) but it's not listed on output list (after foobar restart). [link] (http://cl.ly/RNGd/fb2k.png)
Did you install the component using the proper method? The importance of this has been discussed in the past with specific reference to this plugin.
Did you install the component using the proper method? The importance of this has been discussed in the past with specific reference to this plugin.
What's the proper method? I clicked onto download link and foobar opened the component I applied the settings and foobar restarted himself that's all.
Yeah, that should be the right way. I was just checking because there were problems before with people who had used other (non-)methods of installation. Someone else will have to advise about this problem as I have no other ideas; sorry.
Yeah, that should be the right way. I was just checking because there were problems before with people who had used other (non-)methods of installation. Someone else will have to advise about this problem as I have no other ideas; sorry.
I had to reinstall foobar, now it works.
Works great with a M2Tech Hiface USB to SPDIF interface and a Bryston BDA-1 DAC, all rates and formats, including HD Tracks.
Thank you!!
i tried WASAPI for the first time today, connecting my PC straight into my AVR via HDMI. stereo sound never was so good before. now i finally got to enjoy my AVR dac.
Did you verify that subjective impression with an objective double-blind test, or should I just bin it as most likely a symptom of expectation bias and as per TOS #8?
I'd like to request the addition of fade-in/fade-out capability to the WASAPI output component. I prefer to use WASAPI over DirectSound for reasons related to my hardware setup. However, the abrupt stopping of sound on pausing a track or switching tracks is a pain sometimes and makes it less usable to me.
I did search for this topic and it seems that there isn't much support for adding this feature. I understand that the data output is no longer bit-perfect during the fading, but that really isn't a big deal (as I said, I don't prefer WASAPI because of some idea that bit-perfect output sounds any different than DirectSound). Adding this feature would just make the program feel much more polished for those that use WASAPI. Additionally, this is a feature that's offered by JRiver and MediaMonkey, so I hope this is something that can be easily added.
Something like foo_dsp_crossfader (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Components/Crossfader_(foo_dsp_crossfader)) might work. Haven't used it myself since version ~1.1.11 of foobar started supporting crossfading (DS only though), so I don't knwo if it still works.
Something like foo_dsp_crossfader (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Components/Crossfader_(foo_dsp_crossfader)) might work. Haven't used it myself since version ~1.1.11 of foobar started supporting crossfading (DS only though), so I don't knwo if it still works.
Thanks. Unfortunately that DSP doesn't allow for fading on pause/stop.
hi,
@db1989
any chance you could implement DSD over PCM in WASAPI in the near (or distant) future?
really like WASAPI component, and i jsut got a DAC that can do DSD, but through DoP.
i know there is a component, but there is an audible difference between WAWSAPI and and that one when i stream PCM data. that one sounds more congested, i think the PCM is not just passed through to the ASIO driver. and it is a real hassle to switch outputs each time i want to listen to PCM/DSD
thanks for reading!
Why AIMP3's WASAPI is not exclusive and foobar2000's doesn't even have the option? Sometimes the non-exclusive can be more suitable.
Never used or cared much about it, I was just testing AIMP3 and saw WASAPI was configured and other sounds were playing as well. It would be a useful option IMO but if Peter didn't integrate it probably there is a good reason. Is there?
(http://i.imgur.com/mz7qCrl.png)
hello again,
i asked the moderator who started the thread.. but the thread seems dead
do once again, @Peter this time.
is there any chance this plugin, or foobar for that matter might support DSD over PCM (DoP) standard?
i know there is a component, but i think that it has a much greater audio path than what you could do in WASAPI.
would help the few of us that want to stick with foobar with the really high end systems that can do DoP.
thanks much, still hoping for an answer.
hello again,
i asked the moderator who started the thread.. but the thread seems dead
Well ... you might get a moderator's attention for writing this:
i know there is a component, but there is an audible difference between WAWSAPI and and that one when i stream PCM data. that one sounds more congested, i think the PCM is not just passed through to the ASIO driver. and it is a real hassle to switch outputs each time i want to listen to PCM/DSD
... without having actually tested.
Maybe a bug?
I'm using a 24-bit codec (VT2021). With Wasapi 2.1 I get a warning when I use a wrong output format.
8-bit: Unrecoverable playback error: Unsupported stream format: 44100 Hz / 8-bit / 2 channels
32-bit: Unrecoverable playback error: Unsupported stream format: 44100 Hz / 32-bit / 2 channels
Since Wasapi 3.0 - 3.2.3 there's still a warning for 8-bit output, but not for 32-bit.
When I play a lossless file in 32-bit output format you can hear sound on the left speaker, the right speaker is muted.
When I play a lossy mp3 file in 32-bit output format you can hear sound on the left speaker, the right speaker plays static noise.
Is this a driver thing or a Wasapi bug? It should display a warning since my card doesn't support 32-bit.
Sounds like a driver bug. Old 2.1 version of the component tried to use floating point output in 32-bit mode. This was changed for v3.0 and it now reverts to PCM mode if float mode fails. Your drivers report it as supported, yet fail horribly with it.
For the benefit of any one having glitching/pausing problems with WASAPI Event Mode, I've managed to fix my issues by adjusting advanced settings within Foobar. I'm playing back FLAC's and MP3's from my external 320GB hard drive, using Foobar2000 v 1.3.1 and WASAPI 3.2.3 on Windows 7 (64 bit). My specific issue was the playback of MP3's regularly pausing and/or stuttering when using Event Mode. The issue did not occur with FLAC's, or when using Push Mode. I'm on a work laptop that is locked down so hard I can't change anything in the OS, even down to my task bar auto hide or turning the date/time display on or off. I've found Event Mode drastically clearer and more open sounding compared to Push Mode, so I've tried just about everything possible to get it working glitch free.
The main setting that fixed the glitching was Advanced>Playback>Thread priority>Thread priority (1-7) and setting it to 1, rather than the default 7. This is the opposite of what I've read on various forums.
I also had to bump up the "Hardware buffer in MS - event mode" to 75. I tried up to 100, but then foobar would have a melt down and do this weird, glitchy, fast forward playback.
Other settings that I'm using are:
Using MMCSS set to Pro Audio
Buffer length set to 350ms (minimum determined by the ctrl-alt-delete method)(http://www.head-fi.org/t/539638/how-to-set-perfect-buffer-lengths)
Everything else is default and no active DSP's.
I still get the occasional glitch, so there is obviously a DPC latency issue on the computer, which I can't fix due to the PC being locked down.
You say you have tried just about anything but have you tried keeping the output buffer longer and playback priority high? Put the playback thread priority back to 7 and pump the output buffer to something like 5000 ms. Low output buffer offers no benefits in music playback. And unless you have a very special output device with broken drivers there is absolutely no difference in the playback between event and push WASAPI outputs.
I've found Event Mode drastically clearer and more open sounding compared to Push Mode, so I've tried just about everything possible to get it working glitch free.
Don't waste your time on hunting figments of your imagination. If "push" mode or DirectSound don't have any glitches, use those, preferably the latter.
Buffer length set to 350ms (minimum determined by the ctrl-alt-delete method)(http://www.head-fi.org/t/539638/how-to-set-perfect-buffer-lengths)
There is zero benefit of having a short buffer for music playback other than that changing DSPs on-the-fly will have the changes kick in earlier. If you are experiencing glitches, try to increase buffer size to something reasonable like a couple of seconds to avoid those. The guide on head-fi is plain wrong:
Having the lowest latency possible is important for your audio.
This is a lie, at least with respect to audio playback.
I still get the occasional glitch, so there is obviously a DPC latency issue on the computer, which I can't fix due to the PC being locked down.
Too bad, this might also be important to solve.
If I set a long buffer, the pauses increase and take longer for playback to recover. But yeah, I agree that low latency shouldn't be that important for playback unless you're simultaneously recording or using DSP's. I'll try some further tests.
I probably should do an ABX test or something, but at least on my work machine there is an easily discernible difference in sound quality between modes. Maybe an RMAA test would prove the point, however it's not the main purpose of my post, so please ignore my previous comment on sound quality (I should have known better). On my home PC there is no significant differences between the two modes. More than likely my work PC's sound or usb drivers are broken, but there's nothing I can do.
I did a "reset page" for the advanced preferences. This seemed to help quite a bit, so maybe my settings were corrupted or something. At 350 ms output buffer, the stutters were still there, but only after a few songs played, not straight away. I put the buffer up to 3000 ms and everything seems pretty good now.
didnt update this component for a long time. After i did it i found some problem: when next track has different format (96khz/24bit instead of previously played 44.1/16) playback stops with error message: "Unrecoverable playback error: Device invalidated" or "wrong arguments (or somehow like that)", but if wait 2-3 seconds and manually begin playback of new file, it plays fine. I didnt noticed this problem before. Using USB sound card E-MU 0204, Win8.1 x64.
p.s. maybe somehow add pause between different source tracks?
I have no problems switching from 16/44.1 to 24/96 using WASAPI.
Are there any newer drivers for your E-MU 0204?
nope, they are old as this soundcard. And no any hope for update. WASAPI ver. 2.1 make it same, looks like i get it after win8.1 update. Seems like it really need some delay between tracks like this.
Does the 0204 support ASIO output? Maybe that's the way to go?
only ASIO4ALL, but it plays fine only 16/44.1. In higher resolution it begins play cracks, noise and more over the music.
Best of all 0204 handles by DS output, but it begins to glitch when i work in visual studio, so i need WASAPI.
also, is it possible to get sources of this foo_out_wasapi? Intersting in some moments
Have you tried using LatencyMon (http://www.resplendence.com/latencymon) to see if it could be a driver causing the problem?
Also tried changing USB ports?
Tried the beta driver?
http://support.creative.com/downloads/welc...Type=11#type_11 (http://support.creative.com/downloads/welcome.aspx?nDriverType=11#type_11)
LatencyMon says my pc isnt good for realtime audio. But playing music - isnt real-time task. Dont want install beta drivers - files from it smaller than the original driver, so i dont believe them. Also, problem isnt in playback, it between different tracks. Maybe, device configured for new track after buffer is filled with new pcm data (async, or maybe something like that). Or hardware problem - device really need some time to switch something
I would be looking in to the reason why LatencyMon is reporting your PC is struggling with realtime audio. That would explain why your getting glitches when your using ASIO.
First thing i would try is the beta driver, if it doesn't fix it then just roll back to the latest stable version. Other than that i don't think your going to be about to the the source code for foo_out_WASAPI since it is maintained by the creator of Foobar2000.
i have installed beta drivers and my problem has been solved after few reboots, so stay on wasapi renderer
asking for sources not to fix them, now digging in microsoft`s example wasapi out for win8, and this one are cracking too much on start or end playback
Is there any reason why foobar2000 WASAPI plugin supports only exclusive mode? I really, really dislike this "exclusive" part, I use WASAPI because I have sound issues when using DirectSound (sound crackling and skipping). Other programs like AIMP3 support WASAPI Shared mode (http://i.imgur.com/qqpdpyG.png), which is perfect for me, but I don't want to change my audio player that I use since 2004. Is there any way I can use foobar2000 with WASAPI non-exclusive mode?
DirectSound uses WASAPI shared mode behind the scenes. There's no need for foobar2000 to reimplement it. Don't use too small buffers or touch priority settings and there won't be glitching.
What does this error signify: Unrecoverable playback error: Invalid argument
I have foobar into my AVR via SPDIF. I'm using v 3.2.3 of the component and the v 1.3.4 of Foobar. Playback is set to WASAPI (event): SPDIF OUT (2 creative SB X-Fi).
EDIT: If I add in SOX and reample to 48Hz the error goes away on the problem files. But, playback is glitchy (even with a huge buffer set) with pops/clicks on seeking and start/end.
As a second, essentially unrealated question, is it possible to have the foo-out WASAPI not let the driver know it's out of data to play i.e continue to send silence? If not, would it be possible to introduce such an option? Reason being that I (and I have seen other people experiencing this via google searches) have been experiencing pops/clicks/glitches at the start and end of songs. It might be a resampling issue but it might also be an issue with the PCM stream stopping. Have tested on my X-Fi soundcard, integrated HD audio on mobo and also on the HMDI audio chip of my graphics card.
WASAPI Output Component version 3.2.3, Foobar2000 version 1.3.4
Windows 8 x64, Realtek High Definition Audio on board,S/PDIF optical to external DAC
I have encountered the following error: '
Unrecoverable playback error: Unsupported stream format: 88200 Hz / 24-bit / 2 channels'
Obviously, this is due to the fact that my embedded card’s driver (Realtek, maybe it’s actually a generic Microsoft’s driver) provides for only a limited number of choices for sampling frequencies supported by a receiver (external DAC): 44.1; 48; 96; 192. See Figure 1 below.
(http://s4.postimg.org/5t39ftim5/Realtek_Digital_Output_Quantization_Frequencis.png)
Fig 1
This issue has been already raised with regards to WASAPI Output Component version 3.2.1. (See http://www.hydrogenaud.io/forums/index.php...6805&st=50) (http://www.hydrogenaud.io/forums/index.php?showtopic=96805&st=50))
The proposed solution was to
Just go in foobar2000 option then in Advanced/Playback/WASAPI check "Attempt to play unsupported stream formats”
However, in the current version of the component there is
no longer such an option. (See Figure 2.)
(http://s4.postimg.org/i8zz9kby5/foobar_wasapi_advanced_options.png)
Fig 2
I understand that a possible solution is to resample, e.g. with the Sox. However, I prefer to stream unchanged at a sampling rate actually supported by my DAC. 88200 Hz / 24-bit / 2 channels.
Please, advice what happened to the "Attempt to play unsupported stream formats” option of the component.
How to stream unaltered 88200 Hz?
Pavlo, OK, you DAC supports 88200. But does your realtek supports 88200? I guess no.
Pavlo, OK, you DAC supports 88200. But does your realtek supports 88200? I guess no.
Realtek does support it. See http://www.realtek.com.tw/products/product...&ProdID=284 (http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=28&Level=5&Conn=4&ProdID=284)
I have tried both most up-to-date drivers for audio on the motherboard vendor site and on the Realtek site. But of no avail. The Windows dialog does not list 88200 as a choice.
Pavlo did you manage to fix this in the end? I have the same problem.
http://www.head-fi.org/t/550087/realtek-al...15#post_7455952 (http://www.head-fi.org/t/550087/realtek-alc892-does-not-play-88-2khz-files/15#post_7455952)
IOW, the generic Windows driver recognizes the hardware capability, but Realtek's own driver intentionally disables one of its output modes.
The Realtek driver includes all the EQ and sound effects software, but I'm not sure I need that, so I uninstalled all audio drivers and let Windows install its own driver a 2nd time, and now I have 88.2kHz playback capability.
...but, slightly later:
I did try it to uninstalling the realtek drivers and indeed the default Microsoft driver gives an 88.2 kHz option. However when I use foobar2000 with the wasapi driver to playback a 88.2 kHz file (which it was first refusing todo) my receiver is reporting 96 kHz so it seems like the Microsoft driver is doing a sample rate conversion.
At least you can try MS drivers.
Hi Sir,
I have installed WASAPI component, there are 2 options in Output:
1. WASAPI (event)
2. WASAPI (push)
Which plays better sound?
What is the
There're sudden pause sometimes with WASAPI event mode after upgrade my computer to windows 10, I don't know why.
Foobar2000 behaves quite well on windows 8.1. Is there anything that we should do to avoid such issues, or it's just the driver not mature for windows 10?
I have a schiit Bofrost USB Audio DAC, with a asynchronous usb connection to the computer.
Edit: Manually installed the driver for windows 8.1, now it works perfect. It seems the 'windows 10' specified new driver has serious bugs.
There're sudden pause sometimes with WASAPI event mode after upgrade my computer to windows 10, I don't know why.
Foobar2000 behaves quite well on windows 8.1. Is there anything that we should do to avoid such issues, or it's just the driver not mature for windows 10?
I have a schiit Bofrost USB Audio DAC, with a asynchronous usb connection to the computer.
Tried with almost every driver that I can find, the problem still there, until I run foobar2000 with windows 8 compatible mode.
Found that there's slight changes around WASAPI in windows 10:
https://msdn.microsoft.com/en-us/library/wi...v=vs.85%29.aspx (https://msdn.microsoft.com/en-us/library/windows/hardware/mt298187%28v=vs.85%29.aspx)
If any modification on the plugin's side is ever needed to made it compatible for windows 10's new api?
I also had to bump up the "Hardware buffer in MS - event mode" to 75. I tried up to 100, but then foobar would have a melt down and do this weird, glitchy, fast forward playback.
Bug:
If you set "Hardware buffer in MS - event mode" more than 90
Reference:
http://blog.sina.com.cn/s/blog_68397a5e0102v8hr.html (http://blog.sina.com.cn/s/blog_68397a5e0102v8hr.html) <--- Chinese
(https://i.imgur.com/5gzdw5q.png)
Hi Everyone, let's suppose you connect an external DAC to a PC, using WASAPI. For example:
(http://i.snag.gy/bXo4N.jpg)
My question is, if someone randomly plays 16 bit and 24 bit tracks, the "Output data format" should be set to:
1) Always 16 bit.
2) Always 24 bit.
3) 16 bit or 24 bit, depending on the track being played.
What would be preferable:
- If the track being played is 16 bit, then output 16 bit.
- If the track being played is 24 bit, then output 24 bit.
Why? Are you assuming that outputting 16 bit files with a few insignificant 0's is somehow harmful?
I didn't think about that. So, I suppose that, when randomly playing some 16 and 24 bit tracks, it would be fine to just leave the "Output data format" to 24 bit? Won't it change the track from 16 to 24 bit, trying to reconstruct the missing bits, destroying the original samples?
trying to reconstruct the missing bits, destroying the original samples?
No.
512348576.87
512348576.8700000000
Mathematically, does the value of those two numbers change, just because there are more significant digits? No.
"Bit depth" is just the same principle happening with binary numbers instead of decimal numbers.
This is an interesting answer which solve my doubts. Thank you!
Is there a reason why WASAPI "Hardware buffer in MS" option should have an impact on sound quality? Perhaps on jitter or something like that? Maybe with onboard sound chips? Cause I swear I hear a difference (i.e. better sound quality) when I set that option to 0.
"0" should use a default buffer size or some minimum. And no, it doesn't change jitter. Buffer size is a tradeoff between latency (doesn't matter in an audio player), memory usage, efficiency (larger buffers improve efficiency) and glitch prevention.
If you could set buffer sizes arbitrary low then you'd either experience massive glitches or no sound playing at all.
Dears,
ny HTPC plays to a Harman Kardon receiver in WASAPI event mode via HDMI.
Any tracks is started the receiver takes 1-2 seconds to identify audio stream format, then starts playing.
Because of this the beginning of any tracks is not played.
How can I configure Foobar in order to open the stream and wait 2 seconds to begin to play?
Thanks and best regards
Try foo_dsp_noise (https://hydrogenaud.io/index.php/topic,73072.0.html)
Any tracks is started the receiver takes 1-2 seconds to identify audio stream format, then starts playing.
Because of this the beginning of any tracks is not played.
How can I configure Foobar in order to open the stream and wait 2 seconds to begin to play?
I have created Pregap DSP (http://www.saunalahti.fi/~cse/foobar2000/?changes=foo_dsp_pregap) component precisely for helping with this issue. The old version from 2010 had some limitations but I uploaded a new version today that should work for everyone.
At the risk of appearing an idiot, but what's the different between WASAPI (event) and (push) modes. I have a HeadRoom Micro DAC connected via USB to a headphone based system.
Thanks Case for updating the Pregap DSP! My setup is working much better with the new version adding noise at the beginning
Just out of curiosity: What type of noise you're creating and how silent is it? (I assume white noise and LSB)
...what's the different between WASAPI (event) and (push) modes.
They are just different ways to keep the sound card's buffer filled. Normally it makes no difference which one you use but with some devices only one of them may work without audible glitches.
What type of noise you're creating and how silent is it? (I assume white noise and LSB)
It's quiet white noise, at 16-bit output it can get sample values -1, 0 or +1. The component doesn't know output bit depth so it always uses the same formula. At 24-bit the values will be quite a bit higher but it will still be inaudible with sane playback volumes.
Is there a place where I can download older versions of WASAPI plugin?
Hi!
Could it be possible to have "default audio device" selection for WASAPI output? What I mean is that the WASAPI plugin will output the data to the device which is selected as default in Windows sound devices.
That would be greatly useful for the persons who use HDMI as audio transport. For example: when I have the TV off and AVR on, the device name in HDMI EDID is the model of my AVR. When both are on, the name is my TV model. Windows classifies these as two different sound devices and I don't think there is a way to make the same.
If I'm listening music with foobar2000 and turn on the TV, playback jams.
If the playback is started after turning on TV and the audio output isn't corrected, foobar prompts me to select available output
These two happen also vice versa (after a while when I've turned off my TV).
IMO this is annoying. For example Kodi has 'WASAPI: default'. 'DirectSound: default' can be selected in foobar too so 'WASAPI: default' should be possible to implement.
ASIO could be a choice too but I have to use ASIO4ALL and sometimes it jams (plays some sample over and over again for couple of seconds) when I use seekbar or change track.
Is there a place where I can download older versions of WASAPI plugin?
https://web.archive.org/web/*/http://www.foobar2000.org/components/view/foo_out_wasapi
Is there a reason why WASAPI "Hardware buffer in MS" option should have an impact on sound quality? Perhaps on jitter or something like that? Maybe with onboard sound chips? Cause I swear I hear a difference (i.e. better sound quality) when I set that option to 0.
I also use/experiment with on PCs with internal sound cards 0/0 WASAPI buffer settings without stuttering and I am wondering what effects it has on actual sound processing.
Since the last windows 10 feature update WASAPI event has been broken. I have a Grace M9xx DAC. WASAPI push works.