diff options
author | wm4 <wm4@nowhere> | 2017-03-29 14:36:00 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2017-03-29 15:19:25 +0200 |
commit | c68be80a63f100d1a55d8be7273c89734d6abeeb (patch) | |
tree | 3b66b938ab09b8760270a90f6e15b1d17dc40360 /misc/node.c | |
parent | 4d07fce04175bf353e8de538571d3afa2c7b3e00 (diff) | |
download | mpv-c68be80a63f100d1a55d8be7273c89734d6abeeb.tar.bz2 mpv-c68be80a63f100d1a55d8be7273c89734d6abeeb.tar.xz |
ao_wasapi: do not pass nonsense to drivers with double
This tried to use AF_FORMAT_DOUBLE as KSDATAFORMAT_SUBTYPE_IEEE_FLOAT,
with wBitsPerSample==64. This is probably not allowed, and drivers
appear to react inconsistently to it. (With one user, the format was
accepted during format negotiation, but then rejected on actual init.)
Remove it, which essentially forces it to fall back to some other
format. (Looks like it'll use af_select_best_samplerate(), which would
probably make it try S32 next.)
The af_fmt_from_planar() is so that we don't have to care about
AF_FORMAT_FLOATP. Wasapi always requires packed data anyway.
This should actually handle other potentially unknown sample formats
better.
This changes that set_waveformat() always set the exact format. Now it
might set a "close" format instead. But all callers seem to deal with
this well. Although in theory, callers should probably handle the
fallback. The next cleanup (if ever) can take care of this.
Diffstat (limited to 'misc/node.c')
0 files changed, 0 insertions, 0 deletions