Difference between revisions of "WASAPI"

From JRiverWiki
Jump to: navigation, search
(Problems)
(Problems)
Line 47: Line 47:
 
'''Hiccups using WASAPI - Event Style'''
 
'''Hiccups using WASAPI - Event Style'''
  
The default buffering value for WASAPI (post 18.0.183) is 50ms.  With some hardware, and especially USB DAC's, a larger value is necessary.  If you hear hiccups, select a larger value for buffering in Options > Audio > Output mode settings...
+
The default buffering value for WASAPI is 100ms.  With some hardware, and especially USB DAC's, a larger value is necessary.  If you hear hiccups, select a larger value for buffering in Options > Audio > Output mode settings...
  
  

Revision as of 15:16, 31 May 2013

WASAPI is Microsoft's most modern method for talking with sound devices. WASAPI stands for Windows Audio Session API. It is available in Windows Vista, Windows 7, and newer. It allows delivering an unmodified bitstream to a sound device.

WASAPI support was first added to Media Center 13. Media Center 15 added event style WASAPI support.

For XP, ASIO is similar.

An Interact thread on the original creation of WASAPI can be found here: http://yabb.jriver.com/interact/index.php?topic=48478.0

WASAPI Modes

There are two main ways to communicate using WASAPI. Both deliver the same audio data and will sound the same. One may work better with specific hardware.

Terminology Changes IN 18.0.183 and Above

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.

Problems

Stuttering

Some devices (most commonly USB DAC's) will start stuttering during playback when using WASAPI. This is due to a bug in Microsoft's WASAPI system itself, or in the 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. (WASAPI in 18.0.183 or above)

There are more details here: http://yabb.jriver.com/interact/index.php?topic=59460.0


Hiccups using WASAPI - Event Style

The default buffering value for WASAPI is 100ms. With some hardware, and especially USB DAC's, a larger value is necessary. If you hear hiccups, select a larger value for buffering in Options > Audio > Output mode settings...


Playback won't start or playback stalls

Some hardware is very demanding about buffer sizes. You may need to experiment with different buffering values using Options > Audio > Output mode settings...