There's a bug in v0.4: if 2 audio devices are present WASAPI output will always use one of them - even if another one is selected.
I have Realtek HDA and Creative Audigy 4. I select WASAPI output for Creative but the sound is going from Realtek HDA. See the attached file.
Thanks, I was using wrong GUID to ID devices but with my setup I see no problems. Can you verify on your system if this version can differentiate between the devices?
Edit: attachment removed. The fixed version is now properly released.
The new version works correctly, thanks.
In comparison to WASAPI output support 3.3 plugin, yours has less options to setup so I have a few questions:
1. What output data format does it use?
2. What mode does it work in - push or event?
3. What does "shared" mean in the names of output devices?
1. It uses 32-bit floating point at the sample rate and channel count configured for your device. The component will automatically resample and downmix channels if needed.
2. Event.
3. It's the opposite of Exclusive mode. There can be only one exclusive mode WASAPI session open on a device and all other sound sessions are blocked. Shared mode allows multiple sessions to share the device, they just need to take care to output sound at the format the mixer is configured for.
Thank you for this component, much appreciated. I use it since v0.5.2 without any issues. On my configuration, it uses significantly less cpu cycles than dsound during playback when no SRC is necessary.
"the component will automatically resample.." here I have a question, does it SRC by itself or it uses fb2k resampling service so that it can use sox plugin when installed? I figured out, it probably doesn't use media foundation resampler (resampledmo.dll) used by windows build-in apps, which is btw. extremely fast and transparent.
It uses foobar2000 resampling service. If you want to make sure SoX gets picked go to Preferences -> Advanced -> Tools and enter "Resampler (SoX)" under "Automatic resampling preference".
Great, thank you Case. Frankly, i don't know the benefits of dsound over this output component on W7up systems other than fading settings. Regarding WXP market share, dsound support could be provided as plugin and this one should be build-in..
But I understand the dsound support still provides "safe" like solution how to provide shared audio stream for the engine for most configurations. However, your component proved it's better for W7up sound driver support, at least according to my experience.
Hello,
it looks this component does not bypass Windows soundmixer ?
If I change settings on windows sound like echo, loudness etc Foobar sound with Wasapi shared is impacted whereas there is no change with he classic Wasapi exclusive component
Does that mean that only Wasapi in exclusive mode can bypass Windows soundmixer ?
If yes what is the advantage using Wasapi shared compared to DS ?
Does that mean that only Wasapi in exclusive mode can bypass Windows soundmixer ?
If yes what is the advantage using Wasapi shared compared to DS ?
foo_out_wasapis does its own resampling and channel downmixing as needed.
Advantage of foo_out_wasapis over DS: "This component tries to provide smoother volume adjustment and seek/pause/stop transitions than existing outputs." (https://www.foobar2000.org/components/view/foo_out_wasapis (https://www.foobar2000.org/components/view/foo_out_wasapis))
Here's a simple test file that should show the smoother transitions in effect. Play the file with various outputs and adjust volume/seek in the track and compare how much clicks and pops you hear. Same issues are present in regular music but may not be as easy to hear all the time.
@Case, will you be adding fading effects in Wasapi shared mode just like DS? Thanks.
I have no plans to add additional configuration. The fades the component does now are all as short as possible and only done because without them there could be loud glitches that don't belong in the original signal. Also a regular DSP could not be used to achieve them. Other than that I believe output component should play all samples that come from the source. If further fades are desired they can be handled with a DSP component.
Thanks for the component and I installed and tested with the sine wave provided.
However, the Meier crossfeed seemed not functioning as with DS using music tracks.
DSP components do not depend on output method. Remember that Meier crossfeed effect is very subtle. Try comparing the lowest strength against the maximum and you should see that it does work with this WASAPI output too.
Is it possible that DS sounds louder than ASAPI?
I tested without changing volume, just the driver at the page of Playback|output.
If you didn't have foobar2000 volume at maximum that does happen. The default outputs synchronize their volume with Windows mixer and the OS remembers what the mixer was previously set to. My component does all volume adjusting itself and doesn't touch the OS mixer, so old settings cause the volume to be lowered twice. You can safely open the Windows' volume mixer and drag the player's volume to maximum.
There are two benefits for not using the OS mixer: one is the ability to interpolate adjustment steps to prevent noises and the second is ability to bypass limiter when it wouldn't be needed.
Thanks a lot for explaining the volume related issues. I'll use it from now on...
I've bought a MQA album from highresaudio.com (https://www.highresaudio.com/en/album/view/7mwskf/david-bowie-let-s-dance-2018-remastered-version), set up foobar2000 with WASAPI(http://foobar2000.org/components/view/foo_out_wasapi + http://foobar2000.org/components/view/foo_out_wasapis).
When I play a track from the album with foo_out_wasapi set to either WASAPI event or push, my Dragonfly Red led lights up Blue.
When I play a track from the album with foo_out_wasapis set to either WASAPI (shared), my Dragonfly Red led lights up Green.
DragonFly Red 1.0’s LED lights up in different colors to indicate status or sample rate:
Red: Standby
Green: 44100 Hz
Blue: 48000 Hz
Amber: 88200 Hz
Magenta: 96000 Hz
When I play the same album in Roon, led lights up Magenta.
I love to be able to play my MQA files in max. quality available with foobar2k though.
If someone reverse engineers the MQA format and releases a usable decoder library you can get foobar2000 to behave like Roon too.
If you wonder the difference between the two WASAPI components, this shared one uses the mixer format you have configured in Windows for your sound interface. The other WASAPI component forces the device to use the same format as the source.
Ah, so foobar2000 actually misses a software decoder to unfold the 1st level of MQA.
Fun-factor: With your foo_out_wasapis, I'm now able to play the bought MQA FLAC file in foobar2000, while led lights up Magenta, by indeed, preconfigure the Dragonfly Red in Windows to play at 24-bit/96khz.
But this means it not doing any unfolding though, right?
Correct. You're just resampling the 44100Hz signal up without any further processing.
A suggestion/issue.
When using Default, say Bluetooth headphones set to Default audio device, once it's disconnected it falls back to Speakers, the new Default, which is expected. When the headphones reconnect and are the Default again, it continues using the Speakers. Is it feasible to detect this and switch back to headphones?
Thanks.
It's certainly possible and I have been thinking about it. I'll keep your request in mind.
Feature implemented in v0.5.5 (https://foobar.hyv.fi/?view=foo_out_wasapis).
Feature implemented in v0.5.5 (https://foobar.hyv.fi/?view=foo_out_wasapis).
Great news. Thank you!
:'(
0.6 hacve bug , music breaking up !, please fix asap !
http://www.foobar2000.org/components/view/foo_out_wasapis
0.6 music break up when play DSD ! ! !
please fix it asap !
I'll be busy at work for several hours so I can't take a look, but I'll attach version 0.5.8 here for anyone who needs to revert.
I was afraid the changes in 0.6 could have side effects.
Old version resampled and downmixed the data as it was received from inputs so the entire output buffer was in the mixer format. That worked otherwise fine but when using the default output mode and the device changed during playback, the transition wasn't smooth. Old version actually discarded the currently buffered samples entirely and just started the buffering from current internal decode position.
The 0.6 version keeps buffered sampes as they were received and performs the resampling/downmixing just before playback. It worked fine in my tests but it is a way more processing time critical method.
I'll see if I can improve things.
Hi
@Case maybe I am missing somthing but what separates your component from peters and which one should i be using?
I've noticed a small bug: If you are playing a track and then pause it, there will be a pop if you start playing another track or seek somewhere in the track. There's no pop if you stop the track instead. This happened in 0.5.8 as well as 0.6 so it doesn't appear to be a regression at least.
Hi @Case maybe I am missing somthing but what separates your component from peters and which one should i be using?
The main technical difference is that the other WASAPI component takes full control of the output device. Nothing else can use the device while it's open in foobar2000. That also means the other WASAPI component can only play source material your sound card / DAC supports, unless you manually add the required DSPs to resample, downmix or upmix the signal to supported specs. My component automatically resamples the signal to sound card's chosen sample rate, downmixes channels when needed or pads missing channels with silence.
Another difference and the main reason I created the component are the added interpolation effects. Whenever signal changes suddenly - which happens if you pause or stop a track while it's playing or seek in a track - there's a pop sound. I hate those so my component tries to eliminate them. Similar effect can be heard while adjusting volume so the component interpolates volume adjustments too. The built-in DirectSound output has configurable fades that can eliminate the seeking pops but its stop fade doesn't fade audio fully (so it can make a pop) and it has no means to fix scratching sound while adjusting volume.
Some people use the exclusive WASAPI component to make sure the signal isn't resampled anywhere before the sound card. Proper resampling as done by foobar2000 DSPs is transparent (doesn't cause audible change) so audio quality wise this isn't necessary.
Some people use the exclusive component to make sure no other sounds can interfere with music. I have all operating system notification sounds turned off so I don't get unwanted interruptions from unexpected beeps. And I want to be able to watch a video clip or use voice chat while music is playing. If I don't want interruptions I don't do interrupting actions.
Only reason I'd use the exclusive WASAPI component would be to bitstream digital audio to external receiver for decoding. Though in my opinion doing that makes no sense as then you can't use ReplayGain, can't use any DSPs and can't control volume with foobar2000 or the operating system. Also without proper decoders you can't use Converter to transcode these files to other format.
So my recommendation would be to use the default DirectSound output unless you have a reason to use something else. If you think my WASAPI shared component offers smoother experience use it, if you think bit-perfect output to DAC is a must, use ASIO or WASAPI exclusive.
I've noticed a small bug: If you are playing a track and then pause it, there will be a pop if you start playing another track or seek somewhere in the track. There's no pop if you stop the track instead. This happened in 0.5.8 as well as 0.6 so it doesn't appear to be a regression at least.
Thanks, confirmed. Will need fixing.
0.6 causes a cracking sound (for example, listen to Spain.ogg (https://myfile.is/ycw9k5Ycm4/05_Spain_ogg) between 2:15 and 2:30), rolled back (https://hydrogenaud.io/index.php/topic,116739.msg969942.html#msg969942) to 0.5.8
I took down the 0.6 version from the component repository so people won't automatically update to it. So far I haven't managed to find the time to fix the issues.
0.6 causes a cracking sound (for example, listen to Spain.ogg (https://myfile.is/ycw9k5Ycm4/05_Spain_ogg) between 2:15 and 2:30), rolled back (https://hydrogenaud.io/index.php/topic,116739.msg969942.html#msg969942) to 0.5.8
foobar2000 | Preferences | Advanced | Tools | Automatic resampling preference
Resampler (dBpoweramp/SSRC)
-> No cracking sound.
PPHS is not good.
(I do not know if this is a component bug or PPHS bug.)
Anyway, Windows's own resampler also does not have such a problem.
Please create an option to turn off automatic resampling.
Please create an option to turn off automatic resampling.
Shared WASAPI without resampling? How?
Please create an option to turn off automatic resampling.
Shared WASAPI without resampling? How?
I just saw it being in another player(potplayer). I do not know the technical part.
I can choose between shared and exclusive modes in the potaplayer's wasapi audio renderer and set it to shared mode(default).
Shared WASAPI requires resampling if the mixer and source formats don't match. Otherwise the audio will play at wrong speed and pitch. I also interpret that screenshot of yours showing some resampler being active as the grayed out "Resample" field says "Always".
Shared WASAPI requires resampling if the mixer and source formats don't match. Otherwise the audio will play at wrong speed and pitch. I also interpret that screenshot of yours showing some resampler being active as the grayed out "Resample" field says "Always".
greyed out = none available
Sample rate = target sample rate
Resample = resampling condition(always/when sample rate is smaller than/when sample rate is larger than)
Take a look at the items Input, Output and Rendering sample rate on the player screen.
"Same as input" implies that it is changing the shared sample rate for the device, which also forces everything else on the system to resample to that rate, and can have jarring effects if you're changing the rate every time a different format file comes up for output.
Maybe Potplayer simply has the same config dialog for both modes (shared and exclusive)? But some settings are only valid for exclusive mode, and have no effect on shared mode?
New version with the seek-while-paused glitch fixed and buffering is back to the pre-resampled/pre-downmixed circular buffer.
0.6.1 fixes the pop when seeking while paused, but there's still a pop if you pause a track then start playing another track (like by double-clicking it while the first track is still paused).
Yeah same, If I pause the track and wait a second then play another it pops/glitches, but it seems like it's not every time.
I actually saw that too but out of silliness didn't do anything. Will be fixed.
I actually saw that too but out of silliness didn't do anything. Will be fixed.
Just giving you a nudge in case about the fix.
I haven't forgotten it. Fixing it wasn't as simple as I had hoped and I consider the issue quite minor so haven't allocated the required time to get it done. But I'll be on a vacation soon which should provide plenty of spare time to get it done.
Sometimes playback fails unexpectedly with error: "Unrecoverable playback error: WASAPI playback thread terminated". What could be the reason?
Have you checked the foobar's console? It might report some additional error information.
WASAPI (shared) PlayThread error: Received event to fill buffer but IAudioClient::GetCurrentPadding reported the buffer was still full during 70 ms of retrying
Unrecoverable playback error: WASAPI playback thread terminated
My fail safe code is terminating the playback thread as things look broken. The thread received an event that requested more data but even after retrying a few times the playback buffer had no room for new samples.
I attached a modified version that waits for about 0.5 seconds until erroring out if buffer stays full. I'd like to hear if this solves the issue.
Edit: attachment removed. Improved version of the change is included in the latest release.
Thanks. I'll try it but, as the problem occurs rarely (say, one time per month), can't say for sure if it is fixed.
This took longer than I'd have liked.
Attached is a new version I just finished which should fix all the transition glitches. I rewrote large parts of the functionality so I don't dare to upload it to the repository yet until I have had time to properly play with it. And hopefully some people here too can confirm that nothing got changed for the worse.
Edit: attachment removed. Version released properly now.
With the new version, the sound stutters sometimes during the playback. I recorded the output via Line-In: https://mir.cr/XCVHPFMS https://mir.cr/18KWZGTW
Compare sound at 01:21.
How reproducible is the issue? Can you try if the attached version solves it? I restored the false event handling to work almost identically with the prior version.
Edit: attachment removed. The fixed version is released.
The issue is stable enough but appears each time at different time points. It seems to be gone with the new version. Thanks!
Thanks for the quick confirmation. I released the fixed version for everyone.
Hi. Love the component, but can you please allow fading to be changed? It doesn't even have to be where direct sound does it, or anything fancy, just maybe an ini/xml file which would allow you to change fading times.
I particularly have a problem with the fading on start because it alters the way the beginning of the audio sounds like, i.e., it fades in noticeably, and if I don't know the audio I'm listening to isn't supposed to do that, I might think that's how it really sounds like (which is exactly why I have the direct sound fade on start all the way down to 0).
The fading is only enabled when you manually change from one track to another. If you allow track to change normally without user intervention you will hear all the samples. Or if you hit stop and then pick a track you will also bypass the fade.
I do not get the behavior you described when stopping the playback and playing a track again; it still fades in (super obvious if a track starts with a kick/bass drum) (I'm using the latest version available through check updated components UI). I use a crossfader dsp to smoothly transition between tracks, so auto switching doesn't really help.
Also, not sure if there's anything you can do about this, but I have various dsp profiles with different dsp plugins, and when switching profiles, in certain situations the switch is a lot faster than direct sound (with 1k ms buffer), and at other times it seems as if the whole process hangs, it takes a while to switch, and unlike with direct sound where I can fast forward/rewind to force it to switch, with wasapi it doesn't let me do anything. Dsp's I normally use: EQ, crossfade, and Dolby headphone, and it seems as if resetting the profile from one with 2/3 plugins to a profile with none causes the hang.
I'm not sure how hard it'd be for you to allow changing the fading time, but It'd be very helpful if that were possible.
I really appreciate your great job with this plugin, these are just little things that bug me about it. :)
I can't replicate any scenario where the process would appear frozen. I need more information about the files you play that trigger it (format, channel count, sample rate), which resampler is used (if any), and perhaps some more info about your DSP setup. In my test I used the bundled EQ and adjusted some sliders, enabled Dolby Headphone DSP with its default config and the bundled Crossfader with its default config.
But I did spot a downmix bug when the DSP toggling changed channel count on the fly. There was unwanted noise as resampler buffer got downmixed with an incorrect channel configuration. That issue is fixed in the freshly released version (0.6.4).
I'll attach a test file I use to verify that beginning of the audio isn't cut off or faded when it's not supposed to. The first sample is a dirac pulse and the rest of the file is silence. It makes a rather loud tick sound when played on its own and when fade in is active it's completely silent.
I have tested the fading on start again, and you're right; it does not fade if I stop the playback and then play the file again, but it also sometimes produces a click that is not a part of the original audio. The dsp profile I use: built-in crossfade set to 10218 ms, and built-in equalizer with the first 3 parameters set to 70%. The freeze occurs when switching from the profile I described to the empty profile, i.e., when resetting the dsp chain.
As far as the format of the audio goes, it does that for everything (tried 96k 32 bit wave, 44.1k 16 bit mp3, etc.), and I do not use a resampler.
The freeze also occurs when switching from my other profile to an empty one (built-in channel mixer: 6 channels|surround mode|add low freqs, dolby headphone: live room, and built-in crossfade: 10218 ms).
Thanks. I can replicate the UI freeze with those settings. But I can't replicate any playback glitching. Even tried running LinX to fully stress all the CPU cores but playback starts and runs smoothly.
Sorry it took a while. Here's a new version that won't freeze the player UI anymore with the DSP change. I don't expect the change to break anything but just in case I'll initially offer the new version only here.
Edit: attachment removed. Fixed version released.
Thanks! I can confirm it works properly now. Sorry for the belated reply. :)
Surprised I didn't notice this before. I can't get exclusive mode wasapi to work in the event mode with native Win 10 USB 2 support. It needs either a manufacturers driver, or it runs fine in push mode. This shared mode method works in the event mode and doesn't make so many entries in the output device window.
Resampling is a non issue as I am using the convolver to implement EQ at arbitrary frequencies. Everything is already resampled to 96k. CPU usage is super low.
Thanks.
This is great!
I've recently got an external sound card and by using direct sound and exlusive wasapi output there were some popping sounds when stopping or switching songs. (not often tho but it used to happen). Currently I'm using this and no more popping sounds so far.
Thanks Case!
There seems to be some significant audio delay after switching to next track and immediately seeking somewhere in the middle of the track. Also the playback position in Waveform seekbar/minibar does not get immediately updated after switching to next track or starting the playback from stop. These issues doesn't happen with WASAPI push/event modes or DirectSound output, nor does the Buffer length have any affect on this delay.
Are you using the latest version or the old one attached to this thread? I seem unable to replicate the issue with the current version. Though my "immediately" means I hit keyboard to switch to the next track and try to click mouse button to seek to the middle of the track simultaneously.
Are you using the latest version or the old one attached to this thread? I seem unable to replicate the issue with the current version. Though my "immediately" means I hit keyboard to switch to the next track and try to click mouse button to seek to the middle of the track simultaneously.
0.6.8. It takes ~3 seconds after pressing next track when it actually seeks where I clicked.
Edit: Most of the tracks in my library seems to have this issue but not all, for example in one album I can start seeking right away with in 2 songs out of 11. This happens with both MP3 and FLAC files so it doesn't seem to be related to the file format.
I don't have such issues with 0.6.8, but would like to have configurable fade support, like the DS output. I use your output mainly due to DS's forced limiter behavior.
It is strange that no one writes that the sound became quieter with this wasapi. WASAPI shared is playing about 2 times quieter than on other outputs (e.g. wasapi event, ds). Sound card ZxR, Windows 10 with latest updates.
Volume issue was mentioned in the early posts (https://hydrogenaud.io/index.php?topic=116739.msg967976#msg967976). Since my component doesn't touch Windows mixer fixing its level has to be done by the user. Just slide foobar2000's volume to max in mixer and you're done.
Tin. And what should I correct her every time? The fact is that I often change the volume in the Foobar and the main volume is also not at my maximum, I also change it often.
There seems to be some confusion. You are free to touch Windows's volume control and it will work like it has always worked. You only need to adjust the per-application mixer for foobar2000 once. If you stick with this WASAPI output component that mixer setting will remain where it is. You don't even need to touch it manually - you can switch to DS output, set foobar's volume to max, switch back and you're good to go.
Every time my computer went to sleep while I paused a playback, it shows the popup when wake up:
WASAPI (shared) PlayThread error: Received event to fill buffer but IAudioClient::GetCurrentPadding reported the buffer stayed full during <number> ms of retrying
Is it possible to permanently hide the popup? It's very annoying.
New version released with hopefully proper support for power events. The playback thread should no longer die from power events and if you don't manually pause the playback the component should handle it for you.
I'm sorry but I'm still getting error
Unrecoverable playback error: WASAPI playback thread terminated: Received event to fill buffer but IAudioClient::GetCurrentPadding reported the buffer stayed full during 1010 ms of retrying
I'm using foo_out_wasapis 0.6.9. All I'm doing is 1) play a music. 2) put to sleep. 3) immediately wakeup. 4) observe error.
I'll attach a test version that prints to console some status info. Could you tell what it prints when you test that scenario again.
Edit: I must have been lucky when testing the change on my laptop. I just tried with my desktop and replicated the issue. I reset the sleep flag in a stupid position. Replaced the attachment with hopefully working version. If it fails I'd appreciate the console output. If it works I'll release a proper version with the change.
Edit 2: Obsolete attachment removed.
Thank you for help. The test version has the same error message. Here is the print from console:
WASAPI shared: machine going to sleep
WASAPI shared: playback paused by sleep
WASAPI shared: sleep flag reset
WASAPI shared: sleep flag:0
WASAPI (shared) PlayThread error: Received event to fill buffer but IAudioClient::GetCurrentPadding reported the buffer stayed full during 1015 ms of retrying
Unrecoverable playback error: WASAPI playback thread terminated: Received event to fill buffer but IAudioClient::GetCurrentPadding reported the buffer stayed full during 1015 ms of retrying
WASAPI shared: playback resumed after sleep
WASAPI shared: power broadcast: 7, 0
If you need me to test more versions, feel free to shoot me PM. You can upload file to something like Firefox Send.
BTW, my OS is Windows 10 build 2004. foobar2000 ver 1.5.4.
Did you notice the edit and update to the test version?
Yes. When I download, I saw the "Edit" paragraph. Also just tested again. Although the two lines swapped, the issue persists.
WASAPI shared: playback resumed after sleep
WASAPI shared: power broadcast: 7, 0
Thanks to testing help from
@CrendKing I released a new version that should finally handle standby correctly. On my laptop it was OK to just reopen playback chain immediately after waking from standby but proper handling required waiting for the OS to signal that machine has woken up.
Another power event you could look in to or comment on.
Output = HDMI monitor (which has also sound)
track is paused (e,g, long podcast) after a while the screen is put on stand-by.
After waking up the screen foobar2000 shows an "unrecoverable playback error WASAPI".
Is that avoidable?
Have you tried to enable "Show Disconnected Devices" following advice from HP, https://support.hp.com/us-en/document/c01186408
Cheers
Yes, that is on (by default).
Not that it matters. The HDMI device disappears anyway when it switches off.
Error should be gone with the just released 0.6.11 version.
Wow, I'm impressed. Thanks, it works.
From foobar v1.6 change log "Default output mode is now WASAPI shared"
Does that mean that there is no need to have it installed on v1.6?
Different implementations. It would certainly be good if as many people as possible would help test the native mode in foobar2000. I don't know if the built-in output uses lockless design or how its mixer compares to mine. For example at the moment my output is the only one that allows you to play the 10 channel audio sample from this thread (https://hydrogenaud.io/index.php?topic=119435.msg984800#msg984800). But my component will be obsolete soon. The new smooth fade options for output implements identical methods as my component to remove glitches when playback is adjusted.
Thanks for clarification.
Anyway, thank you Case for this plugin, I have used it to my complete satisfaction from the very beginning.
It would be nice if the creators used your experience in debugging the official component as well.
I am running the v1.6 beta 2 and output through primary sound driver via SPDIF to a receiver with DTS 5.1 signal. It sounds awesome. I decided to select the WASAPI shared to see if it made any difference and it was very muted in volume and tone. Just thought it might be worth mentioning but I think I screwed up by adding the WASAPI component when the beta has it included...I am new to all the audio formats. Sounds rad here, no crashes or real errors. Thank you for making sheltering so so much better! :)
It sounds awesome. I decided to select the WASAPI shared to see if it made any difference and it was very muted in volume and tone. Just thought it might be worth mentioning but I think I screwed up by adding the WASAPI component when the beta has it included...
If you switch an existing foobar from DirectSound to WASAPI, you probably need to open the windows volume mixer and set foobar to max volume. Right click on system tray volume icon -> open volume mixer.
(https://i.imgur.com/r8I8tOb.png)
With DS output foobar changes volume by adjusting the windows mixer -- for example, I normally have -7db volume in foobar, so my mixer looks like the above image. In WASAPI foobar is doing volume internally so it doesn't need to do that, which is better. But if you switch from DS to WASAPI and the mixer doesn't get reset, volume gets cut from both the windows mixer and in foobar. So with WASAPI you want foobar to be up at your system default maximum.
I just installed 1.6b5 and Output format is grayed out with my Schiit Modius DAC
please remove, answered already
Is there any chance you could add support for spatial audio (over 8 channels via hdmi, using the built in Dolby Atmos encoder):
https://docs.microsoft.com/en-us/windows/win32/coreaudio/spatial-sound
I know of only 1 player that can do it:
https://sourceforge.net/p/playpcmwin/wiki/WWSpatialAudioPlayer/
But it ain't foobar!
Since most people with immersive sound systems don't have >8 channel audio interfaces (or even home theater boxes with more than 8 analog inputs) this would really enable immersive music content to be used in a user friendly player.
Thanks for considering.
No offense against Case, whom I regard highly, and his great WASAPIS plugin, but wouldn't it be more sensible to direct any such requests regarding the WASAPI output to Peter?
That would be a different output component as that spatial sound tech doesn't seem to be part of WASAPI. I might take a look when I have time.
Hello everyone,
I'm using the latest version of Wasapi Shared but it also happened to me with the previous one. Every now and then I have very brief interruptions in the reproduction (small clicks at high frequencies). Does it happen to any of you? How can I fix this? Thank you.
Sincerely.
Vincenzo
Hi, Case. Is it possible to compile foo_out_wasapis 0.6.18 for foobar2000 1.4x-1.6x? I have a foobar2000 1.6.16 installation, and 0.6.16 (for foobar2000 1.4x) (https://foobar.hyv.fi/?view=foo_out_wasapis) has a bug: it does not stop playback after the last track in the playlist. 0.6.18 (for foobar2000 2.0x) (https://foobar.hyv.fi/2.0/?view=foo_out_wasapis) has fixed this issue, but cannot be used with foobar2000 1.6.16.
Hi
@Compact Dick. It's been a long time since I last heard of you.
I compiled the 0.6.18 version with the latest SDK in foobar2000 v1.6 compatible mode and uploaded it to the official repository.
Thank you so much,
@Case — 0.6.18 works perfectly fine with 1.6.16. I am most grateful.
Yes, it has been a while since I was last active, but I still lurk when possible. How much has changed since the frenzied days of the 2000s.
Glad to chat with you again after all this time. Thanks for all the wonderful work you and the rest do for us. When time permits, I'll drop into the IRC channel. Cheers! 👍