bsnes/ruby/audio/wasapi.cpp

251 lines
8.8 KiB
C++
Raw Normal View History

#include <avrt.h>
#include <mmdeviceapi.h>
#include <audioclient.h>
#include <audiopolicy.h>
#include <devicetopology.h>
#include <endpointvolume.h>
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
#include <functiondiscoverykeys_devpkey.h>
struct AudioWASAPI : Audio {
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
AudioWASAPI() { initialize(); }
~AudioWASAPI() { terminate(); }
auto ready() -> bool { return _ready; }
auto information() -> Information {
Information information;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
for(auto& device : _devices) information.devices.append(device);
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
information.channels = {2};
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
information.frequencies = {(double)_frequency};
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
information.latencies = {0, 20, 40, 60, 80, 100};
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
return information;
}
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
auto exclusive() -> bool { return _exclusive; }
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto device() -> string { return _device; }
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
auto blocking() -> bool { return _blocking; }
auto channels() -> uint { return _channels; }
auto frequency() -> double { return (double)_frequency; }
auto latency() -> uint { return _latency; }
auto setExclusive(bool exclusive) -> bool {
if(_exclusive == exclusive) return true;
_exclusive = exclusive;
return initialize();
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto setDevice(string device) -> bool {
if(_device == device) return true;
_device = device;
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
return initialize();
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
}
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
auto setBlocking(bool blocking) -> bool {
if(_blocking == blocking) return true;
_blocking = blocking;
return true;
}
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
auto setFrequency(double frequency) -> bool {
if(_frequency == frequency) return true;
_frequency = frequency;
return initialize();
}
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
auto setLatency(uint latency) -> bool {
if(_latency == latency) return true;
_latency = latency;
return initialize();
}
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
auto clear() -> void {
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
if(!ready()) return;
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
_queue.read = 0;
_queue.write = 0;
_queue.count = 0;
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
_audioClient->Stop();
_audioClient->Reset();
_audioClient->Start();
}
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
auto output(const double samples[]) -> void {
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
if(!ready()) return;
for(uint n : range(_channels)) {
_queue.samples[_queue.write][n] = samples[n];
}
_queue.write++;
_queue.count++;
if(_queue.count >= _bufferSize) {
if(WaitForSingleObject(_eventHandle, _blocking ? INFINITE : 0) == WAIT_OBJECT_0) {
write();
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
}
}
}
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
private:
auto initialize() -> bool {
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
terminate();
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
if(CoCreateInstance(CLSID_MMDeviceEnumerator, nullptr, CLSCTX_ALL, IID_IMMDeviceEnumerator, (void**)&_enumerator) != S_OK) return false;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
//enumerate all audio endpoint devices, and select the first to match the device() name
IMMDeviceCollection* deviceCollection = nullptr;
if(_enumerator->EnumAudioEndpoints(eRender, DEVICE_STATE_ACTIVE, &deviceCollection) != S_OK) return false;
uint deviceCount = 0;
if(deviceCollection->GetCount(&deviceCount) != S_OK) return false;
for(uint deviceIndex : range(deviceCount)) {
IMMDevice* device = nullptr;
if(deviceCollection->Item(deviceIndex, &device) != S_OK) return false;
IPropertyStore* propertyStore = nullptr;
device->OpenPropertyStore(STGM_READ, &propertyStore);
PROPVARIANT propVariant;
propertyStore->GetValue(PKEY_Device_FriendlyName, &propVariant);
_devices.append((const char*)utf8_t(propVariant.pwszVal));
propertyStore->Release();
if(!_audioDevice && _devices.right() == _device) {
_audioDevice = device;
} else {
device->Release();
}
}
deviceCollection->Release();
//if no match is found, choose the default audio endpoint for the device()
if(!_audioDevice) {
if(_enumerator->GetDefaultAudioEndpoint(eRender, eConsole, &_audioDevice) != S_OK) return false;
}
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
if(_audioDevice->Activate(IID_IAudioClient, CLSCTX_ALL, nullptr, (void**)&_audioClient) != S_OK) return false;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
WAVEFORMATEXTENSIBLE waveFormat = {};
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
if(_exclusive) {
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
IPropertyStore* propertyStore = nullptr;
if(_audioDevice->OpenPropertyStore(STGM_READ, &propertyStore) != S_OK) return false;
PROPVARIANT propVariant;
if(propertyStore->GetValue(PKEY_AudioEngine_DeviceFormat, &propVariant) != S_OK) return false;
waveFormat = *(WAVEFORMATEXTENSIBLE*)propVariant.blob.pBlobData;
propertyStore->Release();
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
if(_audioClient->GetDevicePeriod(nullptr, &_devicePeriod) != S_OK) return false;
auto latency = max(_devicePeriod, (REFERENCE_TIME)_latency * 10'000); //1ms to 100ns units
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto result = _audioClient->Initialize(AUDCLNT_SHAREMODE_EXCLUSIVE, AUDCLNT_STREAMFLAGS_EVENTCALLBACK, latency, latency, &waveFormat.Format, nullptr);
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
if(result == AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED) {
if(_audioClient->GetBufferSize(&_bufferSize) != S_OK) return false;
_audioClient->Release();
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
latency = (REFERENCE_TIME)(10'000 * 1'000 * _bufferSize / waveFormat.Format.nSamplesPerSec);
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
if(_audioDevice->Activate(IID_IAudioClient, CLSCTX_ALL, nullptr, (void**)&_audioClient) != S_OK) return false;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
result = _audioClient->Initialize(AUDCLNT_SHAREMODE_EXCLUSIVE, AUDCLNT_STREAMFLAGS_EVENTCALLBACK, latency, latency, &waveFormat.Format, nullptr);
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
}
if(result != S_OK) return false;
DWORD taskIndex = 0;
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
_taskHandle = AvSetMmThreadCharacteristics(L"Pro Audio", &taskIndex);
} else {
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
WAVEFORMATEX* waveFormatEx = nullptr;
if(_audioClient->GetMixFormat(&waveFormatEx) != S_OK) return false;
waveFormat = *(WAVEFORMATEXTENSIBLE*)waveFormatEx;
CoTaskMemFree(waveFormatEx);
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
if(_audioClient->GetDevicePeriod(&_devicePeriod, nullptr)) return false;
auto latency = max(_devicePeriod, (REFERENCE_TIME)_latency * 10'000); //1ms to 100ns units
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(_audioClient->Initialize(AUDCLNT_SHAREMODE_SHARED, AUDCLNT_STREAMFLAGS_EVENTCALLBACK, latency, 0, &waveFormat.Format, nullptr) != S_OK) return false;
}
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
_eventHandle = CreateEvent(nullptr, false, false, nullptr);
if(_audioClient->SetEventHandle(_eventHandle) != S_OK) return false;
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
if(_audioClient->GetService(IID_IAudioRenderClient, (void**)&_renderClient) != S_OK) return false;
if(_audioClient->GetBufferSize(&_bufferSize) != S_OK) return false;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
_channels = waveFormat.Format.nChannels;
_frequency = waveFormat.Format.nSamplesPerSec;
_mode = waveFormat.SubFormat.Data1;
_precision = waveFormat.Format.wBitsPerSample;
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
_ready = true;
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
clear();
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
return true;
}
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
auto terminate() -> void {
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
_ready = false;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
_devices.reset();
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
if(_audioClient) _audioClient->Stop();
if(_renderClient) _renderClient->Release(), _renderClient = nullptr;
if(_audioClient) _audioClient->Release(), _audioClient = nullptr;
if(_audioDevice) _audioDevice->Release(), _audioDevice = nullptr;
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
if(_eventHandle) CloseHandle(_eventHandle), _eventHandle = nullptr;
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
if(_taskHandle) AvRevertMmThreadCharacteristics(_taskHandle), _taskHandle = nullptr;
}
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
auto write() -> void {
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
uint32_t available = _bufferSize;
if(!_exclusive) {
uint32_t padding = 0;
_audioClient->GetCurrentPadding(&padding);
available = _bufferSize - padding;
}
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
uint32_t length = min(available, _queue.count);
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
uint8_t* buffer = nullptr;
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
if(_renderClient->GetBuffer(length, &buffer) == S_OK) {
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
uint bufferFlags = 0;
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
for(uint _ : range(length)) {
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
double samples[8] = {};
if(_queue.count) {
for(uint n : range(_channels)) {
samples[n] = _queue.samples[_queue.read][n];
}
_queue.read++;
_queue.count--;
}
if(_mode == 1 && _precision == 16) {
auto output = (int16_t*)buffer;
for(uint n : range(_channels)) *output++ = int16_t(samples[n] * 32768.0);
buffer = (uint8_t*)output;
} else if(_mode == 1 && _precision == 32) {
auto output = (int32_t*)buffer;
for(uint n : range(_channels)) *output++ = int32_t(samples[n] * 65536.0 * 32768.0);
buffer = (uint8_t*)output;
} else if(_mode == 3 && _precision == 32) {
auto output = (float*)buffer;
for(uint n : range(_channels)) *output++ = float(samples[n]);
buffer = (uint8_t*)output;
} else {
//output silence for unsupported sample formats
bufferFlags = AUDCLNT_BUFFERFLAGS_SILENT;
break;
}
}
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
_renderClient->ReleaseBuffer(length, bufferFlags);
}
}
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
bool _ready = false;
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
bool _exclusive = false;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
string _device;
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
bool _blocking = true;
uint _channels = 2;
uint _frequency = 48000;
uint _latency = 20;
uint _mode = 0;
uint _precision = 0;
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
struct Queue {
double samples[65536][8];
uint16_t read;
uint16_t write;
uint16_t count;
} _queue;
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
IMMDeviceEnumerator* _enumerator = nullptr;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
vector<string> _devices;
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
IMMDevice* _audioDevice = nullptr;
IAudioClient* _audioClient = nullptr;
IAudioRenderClient* _renderClient = nullptr;
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
HANDLE _eventHandle = nullptr;
Update to v103r16 release. byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see.
2017-07-17 10:32:36 +00:00
HANDLE _taskHandle = nullptr;
REFERENCE_TIME _devicePeriod = 0;
uint32_t _bufferSize = 0; //in frames
};