WASAPI: Difference between revisions
Line 53: | Line 53: | ||
Some hardware is very demanding about buffer sizes. You may need to experiment with different buffering values using Options > Audio > Output mode settings... |
Some hardware is very demanding about buffer sizes. You may need to experiment with different buffering values using Options > Audio > Output mode settings... |
||
'''Other Problems''' |
|||
For playback problems, please see [http://yabb.jriver.com/interact/index.php?topic=57343.msg389010 this thread]. |
|||
[[Category: Frequently Asked Questions]] |
[[Category: Frequently Asked Questions]] |
Revision as of 18:01, 14 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 - Event Style 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...
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...