Hydrogenaudio Forums

Hosted Forums => foobar2000 => 3rd Party Plugins - (fb2k) => Topic started by: GCRaistlin on 2018-10-15 16:58:48

Title: WASAPI shared output (foo_out_wasapis)
Post by: GCRaistlin on 2018-10-15 16:58:48
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2018-10-15 18:22:04
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: GCRaistlin on 2018-10-15 18:53:05
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?
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2018-10-15 19:18:20
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: jaro1 on 2018-11-17 07:18:21
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2018-11-17 08:29:00
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".
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: jaro1 on 2018-11-18 06:08:56
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. 
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Eric75 on 2018-11-25 23:27:35
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 ?
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: sveakul on 2018-11-26 00:34:01
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))

Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2018-11-26 05:50:29
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Teddy_the_barber on 2019-01-27 08:07:05
@Case, will you be adding fading effects in Wasapi shared mode just like DS? Thanks.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-01-27 09:10:47
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Musique-Rabbit on 2019-02-01 08:26:45
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-02-01 12:48:28
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Musique-Rabbit on 2019-02-01 14:38:28
Is it possible that DS sounds louder than ASAPI?
I tested without changing volume, just the driver at the page of Playback|output.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-02-01 14:58:56
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Musique-Rabbit on 2019-02-01 15:15:29
Thanks a lot for explaining the volume related issues. I'll use it from now on...
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: snowseals on 2019-02-28 16:24:13
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-02-28 17:23:37
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: snowseals on 2019-02-28 19:41:22
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?

Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: kode54 on 2019-02-28 23:57:59
Correct. You're just resampling the 44100Hz signal up without any further processing.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: rev6 on 2019-03-06 01:33:53
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-03-08 18:44:08
It's certainly possible and I have been thinking about it. I'll keep your request in mind.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-03-09 09:32:14
Feature implemented in v0.5.5 (https://foobar.hyv.fi/?view=foo_out_wasapis).
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: rev6 on 2019-03-09 21:14:15
Feature implemented in v0.5.5 (https://foobar.hyv.fi/?view=foo_out_wasapis).

Great news. Thank you!
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: xerxeshowie on 2019-04-01 00:47:57
 :'(
0.6  hacve bug , music breaking up !, please fix asap !
http://www.foobar2000.org/components/view/foo_out_wasapis
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: xerxeshowie on 2019-04-01 02:19:50

0.6 music break up when play DSD ! ! !

please fix it asap !
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-04-01 05:50:49
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-04-01 08:55:55
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: MJmusicguy on 2019-04-01 17:32:39
Hi @Case  maybe I am missing somthing but what separates your component from peters and which one should i be using?
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Toad King on 2019-04-02 03:07:47
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-04-02 08:12:09
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Kraeved on 2019-04-03 16:21:52
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
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-04-04 06:47:33
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: pulbitz on 2019-04-04 14:52:05
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: lvqcl on 2019-04-04 16:27:19
Please create an option to turn off automatic resampling.

Shared WASAPI without resampling? How?
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: pulbitz on 2019-04-04 17:40:20
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).
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-04-05 07:08:10
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".
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: pulbitz on 2019-04-05 09:24:14
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: kode54 on 2019-04-06 07:35:19
"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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: lvqcl on 2019-04-06 10:06:29
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?
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-04-07 15:39:47
New version with the seek-while-paused glitch fixed and buffering is back to the pre-resampled/pre-downmixed circular buffer.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Toad King on 2019-04-07 21:41:06
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).
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: rev6 on 2019-04-08 03:31:30
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-04-08 08:10:04
I actually saw that too but out of silliness didn't do anything. Will be fixed.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: rev6 on 2019-05-21 14:49:03
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-05-21 16:13:28
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: GCRaistlin on 2019-05-31 13:51:58
Sometimes playback fails unexpectedly with error: "Unrecoverable playback error: WASAPI playback thread terminated". What could be the reason?
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-05-31 15:36:24
Have you checked the foobar's console? It might report some additional error information.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: GCRaistlin on 2019-05-31 15:42:03
Code: [Select]
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
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-05-31 16:28:16
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: GCRaistlin on 2019-05-31 16:35:10
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-06-14 23:41:47
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: GCRaistlin on 2019-06-17 16:23:13
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-06-17 17:24:28
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: GCRaistlin on 2019-06-17 18:02:42
The issue is stable enough but appears each time at different time points. It seems to be gone with the new version. Thanks!
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-06-17 18:40:54
Thanks for the quick confirmation. I released the fixed version for everyone.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: nsstudios on 2019-06-19 02:01:14
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).
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-06-19 06:18:33
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: nsstudios on 2019-06-21 20:28:22
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. :)
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-06-22 00:22:05
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: nsstudios on 2019-06-24 02:59:25
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).
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-06-24 19:20:39
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2019-06-27 21:17:48
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: nsstudios on 2019-07-02 08:12:10
Thanks! I can confirm it works properly now. Sorry for the belated reply. :)
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: eagleray on 2019-08-03 19:20:18
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Vicas on 2019-12-25 19:43:57
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!
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: GoaLitiuM on 2020-02-17 12:27:53
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: Case on 2020-02-17 16:57:33
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: GoaLitiuM on 2020-02-17 20:19:14
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.
Title: Re: WASAPI shared output (foo_out_wasapis)
Post by: bennetng on 2020-02-18 13:17:52
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.
SimplePortal 1.0.0 RC1 © 2008-2020