WASAPI Event Style: Difference between revisions

From wiki.jriver.com
Jump to navigation Jump to search
No edit summary
No edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
{{See Also
{{See also|WASAPI}}
| relatedPage=[[WASAPI]] }}


There are two main ways to communicate using [[WASAPI]]:
There are two main ways to communicate using [[WASAPI]]:
Line 31: Line 30:
[[Category:Audio]]
[[Category:Audio]]
[[Category:Options]]
[[Category:Options]]
[[Category:Audio Troubleshooting]]
[[Category:Troubleshooting]]

Latest revision as of 06:34, 17 April 2014

There are two main ways to communicate using WASAPI:

  • Event Style
  • Push Style

Both deliver the same audio data and will sound the same. One may work better with specific hardware.

Please Note: As of MC 18.0.183, WASAPI Event Style is now the default. If your audio device does not support this mode, it can be disabled in the WASAPI Device settings dialog.

WASAPI is now just WASAPI. In the options (next item below the selection) you can check "Disable event style..." to get the output mode previously called "WASAPI", used mainly with older hardware. In other words, WASAPI now defaults to Event Style.

Versions prior to 18.0.183

WASAPI output mode pushes data from Media Center to the sound device. It works with nearly all hardware.

WASAPI Event Style lets a sound device pull data from Media Center. This method is not supported by all hardware, but is recommended when supported.

This has several advantages:

  • It lets 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 sees 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 system that J. River built for ASIO), so that fullfilling a pull request is as fast as possible.