Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Improved WASAPI output to be supported? (Read 8634 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Improved WASAPI output to be supported?

Like the title asks, I wonder if foobar2000 will support the new WASAPI Event Style output in the future. It does indeed bring quite a few advantages.

Quote:
"WASAPI - Event Style
The output mode lets a sound device pull data from Media Center. This method is not supported by all hardware, but is recommended when supported.

WASAPI - Event Style has several advantages:
It let's the audio subsystem pull data (when events are set) instead of pushing data to the system. This allows lower latency buffer sizes, and removes an unreliable Microsoft layer documented below.
It creates, uses, and destroys all WASAPI interfaces from a single thread.
The hardware (or WASAPI interface) never see any pause or flush calls. Instead, on pause or flush, silence is delivered in the pull loop. This removes the need for hacks for cards that circle their buffers on pause, flush, etc. (ATI HDMI, etc.).
It allows for a more direct data path to the driver / hardware.
The main 'pull loop' uses a lock-free circle buffer (a neat system J. River built for ASIO), meaning fullfilling a pull request is as fast as possible.

Current WASAPI problems

Stuttering
Some devices (most commonly USB DACs) will start stuttering during playback when using WASAPI. This is due to a bug in the WASAPI system or stock Microsoft driver where the circling buffers get out of order. Stopping and restarting playback is required to reset the stuttering.
Using WASAPI - Event Style will fix this problem."

Improved WASAPI output to be supported?

Reply #1
I've had some comment to this topic in the main wasapi thread, and it seems there isn't an interest or reaction from Peter to explain how is the existing plugin designed, what is a big pity. Pull (event-driven) mode is a question of driver support, so maybe plugin uses it, if supported by the driver, but without his explanation this is only throlling.
I know Peter is very allergic to audio playback/latency topic, but this is, in the case of audio playback, mainly about glitch resilience of some kind of audio peripherals used (mostly usb devices) by taking some part of activity from audio app to the driver. This is IMO performance/efficiency benefit, that is worth to mention about, at least.

Improved WASAPI output to be supported?

Reply #2
You're pointing out the specific advantages I find relevant. I've been using USB DACs for quite some time, and this WASAPI output does seem to make for a more reliable playback experience. Latency wise, I don't find it that relevant, at least for foobar, as I can control it externally.

Also, is there a way to check for Pull mode support at driver level?

I feel bad for asking, but could you point me to the main WASAPI thread?

Improved WASAPI output to be supported?

Reply #3
any more news whether there will be a new wasapi update for foobar?

I just want to add that I found something weird about using wasapi either event style or standard wasapi on J River Media Center when in exclusive mode as well as when using wasapi for foobar. A short glitch at the beginning of tracks is always there when using my FiiO E10 USB DAC/AMP unless I make it shared mode. It doesn't matter whether it is event style or not which is why I use directsound on foobar when using this dac/amp unit. One song where it is very noticeable is on Everything But The Girl's "Love is Here Where I Live". The drums distort at the beginning when wasapi exclusive mode is on, regardless of whether it is foobar or JRiver media center.

Improved WASAPI output to be supported?

Reply #4
Interesting tidbit about WASAPI event mode. It will only work in Windows 7, or Windows Vista 32-bit. There is a bug with event mode in Windows Vista where in 64-bit operating systems, only 64-bit software can receive the event notifications. 32-bit software will never work with event mode in 64-bit Windows Vista. It will work with 64-bit Windows 7, though.

Really, though, in 90% of these WASAPI (or ASIO) use cases where problems are occurring, they can be fixed by switching to DirectSound. Well, it will fix the issue of sound not working properly.

Improved WASAPI output to be supported?

Reply #5
Unfortunately, there are plenty of people on the remaining 10% cases, and one point of WASAPI is specifically to avoid DirectSound.

Event Mode working on Windows 7 32/64 already provides plenty of user support, specially when considering that Vista ended up being a stopgap solution until Windows 7 was released.

 

Improved WASAPI output to be supported?

Reply #6
Theres no problem with event mode on win7/32 here... It is only when I set it to exclusive mode instead of shared regardless of event mode or regular wasapi being used that causes the glitch in the beginning of songs.

EDIT: As far as foobar is concerned, do you guys have any idea if anyone is developing an event mode wasapi for it?

Improved WASAPI output to be supported?

Reply #7
Creating output components is not part of the public SDK. Peter is the only one who writes output components.
elevatorladylevitateme

Improved WASAPI output to be supported?

Reply #8
And you just said that your problem is with exclusive mode. Shared mode was tested and found to be buggy. What is the point of even using WASAPI if you want the device to be shared with the rest of the operating system?

Improved WASAPI output to be supported?

Reply #9
The output device can be mapped solely for foobar2000 or in the event it is the system's output, system sounds and individual software sound can be disabled, avoiding any audio calls that might disrupt the output device's from performing in exclusive mode.

Is an Event Style output plugin something even remotely considered by any developers?

Improved WASAPI output to be supported?

Reply #10
But you just said event mode wasn't what fixed your problem, so why even bother?

Improved WASAPI output to be supported?

Reply #11
Wait, that wasn't me who said that, it was Donunus.

Improved WASAPI output to be supported?

Reply #12
Sorry to break into what seems to be a very 'informed' forum, but I am new to Foobar and want to set it up so that my laptop has as little impact on the sound as possible - but I am not sure whether to select 'WASAPI event' or 'WASAPI push' when connecting to my Digital to Digial box (USB/Optical with asyncronous USB) which feeds my DAC (optical input only).  I have not found the 'direct' option yet.  Which should I use please?  Grateful for any help.

Mitch

Improved WASAPI output to be supported?

Reply #13
Just choose which ever mode works properly. If they both work fine then just choose either.
Who are you and how did you get in here ?
I'm a locksmith, I'm a locksmith.

Improved WASAPI output to be supported?

Reply #14
sorry for bumping after such a long time

in WASAPI - Event Style :
Quote
The hardware (or WASAPI interface) never see any pause or flush calls. Instead, on pause or flush, silence is delivered in the pull loop.


does it means that it would fix 'silent stream bug' ?
Now Event Style is avaliable in foobar,  but unfortunately it doesn't helps