bsnes/ruby/audio/oss.cpp

128 lines
3.2 KiB
C++
Raw Normal View History

#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sys/soundcard.h>
Update to v101r07 release. byuu says: Added VDP sprite rendering. Can't get any games far enough in to see if it actually works. So in other words, it doesn't work at all and is 100% completely broken. Also added 68K exceptions and interrupts. So far only the VDP interrupt is present. It definitely seems to be firing in commercial games, so that's promising. But the implementation is almost certainly completely wrong. There is fuck all of nothing for documentation on how interrupts actually work. I had to find out the interrupt vector numbers from reading the comments from the Sonic the Hedgehog disassembly. I have literally no fucking clue what I0-I2 (3-bit integer priority value in the status register) is supposed to do. I know that Vblank=6, Hblank=4, Ext(gamepad)=2. I know that at reset, SR.I=7. I don't know if I'm supposed to block interrupts when I is >, >=, <, <= to the interrupt level. I don't know what level CPU exceptions are supposed to be. Also implemented VDP regular DMA. No idea if it works correctly since none of the commercial games run far enough to use it. So again, it's horribly broken for usre. Also improved VDP fill mode. But I don't understand how it takes byte-lengths when the bus is 16-bit. The transfer times indicate it's actually transferring at the same speed as the 68K->VDP copy, strongly suggesting it's actually doing 16-bit transfers at a time. In which case, what happens when you set an odd transfer length? Also, both DMA modes can now target VRAM, VSRAM, CRAM. Supposedly there's all kinds of weird shit going on when you target VSRAM, CRAM with VDP fill/copy modes, but whatever. Get to that later. Also implemented a very lazy preliminary wait mechanism to to stall out a processor while another processor exerts control over the bus. This one's going to be a major work in progress. For one, it totally breaks the model I use to do save states with libco. For another, I don't know if a 68K->VDP DMA instantly locks the CPU, or if it the CPU could actually keep running if it was executing out of RAM when it started the DMA transfer from ROM (eg it's a bus busy stall, not a hard chip stall.) That'll greatly change how I handle the waiting. Also, the OSS driver now supports Audio::Latency. Sound should be even lower latency now. On FreeBSD when set to 0ms, it's absolutely incredible. Cannot detect latency whatsoever. The Mario jump sound seems to happen at the very instant I hear my cherry blue keyswitch activate.
2016-08-15 04:56:38 +00:00
//OSSv4 features: define fallbacks for OSSv3 (where these ioctls are ignored)
#ifndef SNDCTL_DSP_COOKEDMODE
Update to v098r01 release. byuu says: Changelog: - SFC: balanced profile removed - SFC: performance profile removed - SFC: code for handling non-threaded CPU, SMP, DSP, PPU removed - SFC: Coprocessor, Controller (and expansion port) shared Thread code merged to SFC::Cothread - Cothread here just means "Thread with CPU affinity" (couldn't think of a better name, sorry) - SFC: CPU now has vector<Thread*> coprocessors, peripherals; - this is the beginning of work to allow expansion port devices to be dynamically changed at run-time - ruby: all audio drivers default to 48000hz instead of 22050hz now if no frequency is assigned - note: the WASAPI driver can default to whatever the native frequency is; doesn't have to be 48000hz - tomoko: removed the ability to change the frequency from the UI (but it will display the frequency used) - tomoko: removed the timing settings panel - the goal is to work toward smooth video via adaptive sync - the model is broken by not being in control of the audio frequency anyway - it's further broken by PAL running at 50hz and WSC running at 75hz - it was always broken anyway by SNES interlace timing varying from progressive timing - higan: audio/ stub created (for now, it's just nall/dsp/ moved here and included as a header) - higan: video/ stub created - higan/GNUmakefile: now includes build rules for essential components (libco, emulator, audio, video) The audio changes are in preparation to merge wareya's awesome WASAPI work without the need for the nall/dsp resampler.
2016-04-09 03:40:12 +00:00
#define SNDCTL_DSP_COOKEDMODE _IOW('P', 30, int)
#endif
#ifndef SNDCTL_DSP_POLICY
Update to v098r01 release. byuu says: Changelog: - SFC: balanced profile removed - SFC: performance profile removed - SFC: code for handling non-threaded CPU, SMP, DSP, PPU removed - SFC: Coprocessor, Controller (and expansion port) shared Thread code merged to SFC::Cothread - Cothread here just means "Thread with CPU affinity" (couldn't think of a better name, sorry) - SFC: CPU now has vector<Thread*> coprocessors, peripherals; - this is the beginning of work to allow expansion port devices to be dynamically changed at run-time - ruby: all audio drivers default to 48000hz instead of 22050hz now if no frequency is assigned - note: the WASAPI driver can default to whatever the native frequency is; doesn't have to be 48000hz - tomoko: removed the ability to change the frequency from the UI (but it will display the frequency used) - tomoko: removed the timing settings panel - the goal is to work toward smooth video via adaptive sync - the model is broken by not being in control of the audio frequency anyway - it's further broken by PAL running at 50hz and WSC running at 75hz - it was always broken anyway by SNES interlace timing varying from progressive timing - higan: audio/ stub created (for now, it's just nall/dsp/ moved here and included as a header) - higan: video/ stub created - higan/GNUmakefile: now includes build rules for essential components (libco, emulator, audio, video) The audio changes are in preparation to merge wareya's awesome WASAPI work without the need for the nall/dsp resampler.
2016-04-09 03:40:12 +00:00
#define SNDCTL_DSP_POLICY _IOW('P', 45, int)
#endif
struct AudioOSS : Audio {
AudioOSS() { initialize(); }
~AudioOSS() { terminate(); }
auto ready() -> bool { return _ready; }
auto information() -> Information {
Information information;
information.devices = {"/dev/dsp"};
for(auto& device : directory::files("/dev/", "dsp?*")) information.devices.append(string{"/dev/", 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.frequencies = {44100.0, 48000.0, 96000.0};
information.latencies = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
information.channels = {1, 2};
return information;
}
auto device() -> string { return _device; }
auto blocking() -> bool { return _blocking; }
auto channels() -> uint { return _channels; }
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 frequency() -> double { return _frequency; }
auto latency() -> uint { return _latency; }
auto setDevice(string device) -> bool {
if(_device == device) return true;
_device = device;
return initialize();
}
auto setBlocking(bool blocking) -> bool {
if(_blocking == blocking) return true;
_blocking = blocking;
updateBlocking();
return true;
}
auto setChannels(uint channels) -> bool {
if(_channels == channels) return true;
_channels = channels;
return initialize();
}
Update to v101r07 release. byuu says: Added VDP sprite rendering. Can't get any games far enough in to see if it actually works. So in other words, it doesn't work at all and is 100% completely broken. Also added 68K exceptions and interrupts. So far only the VDP interrupt is present. It definitely seems to be firing in commercial games, so that's promising. But the implementation is almost certainly completely wrong. There is fuck all of nothing for documentation on how interrupts actually work. I had to find out the interrupt vector numbers from reading the comments from the Sonic the Hedgehog disassembly. I have literally no fucking clue what I0-I2 (3-bit integer priority value in the status register) is supposed to do. I know that Vblank=6, Hblank=4, Ext(gamepad)=2. I know that at reset, SR.I=7. I don't know if I'm supposed to block interrupts when I is >, >=, <, <= to the interrupt level. I don't know what level CPU exceptions are supposed to be. Also implemented VDP regular DMA. No idea if it works correctly since none of the commercial games run far enough to use it. So again, it's horribly broken for usre. Also improved VDP fill mode. But I don't understand how it takes byte-lengths when the bus is 16-bit. The transfer times indicate it's actually transferring at the same speed as the 68K->VDP copy, strongly suggesting it's actually doing 16-bit transfers at a time. In which case, what happens when you set an odd transfer length? Also, both DMA modes can now target VRAM, VSRAM, CRAM. Supposedly there's all kinds of weird shit going on when you target VSRAM, CRAM with VDP fill/copy modes, but whatever. Get to that later. Also implemented a very lazy preliminary wait mechanism to to stall out a processor while another processor exerts control over the bus. This one's going to be a major work in progress. For one, it totally breaks the model I use to do save states with libco. For another, I don't know if a 68K->VDP DMA instantly locks the CPU, or if it the CPU could actually keep running if it was executing out of RAM when it started the DMA transfer from ROM (eg it's a bus busy stall, not a hard chip stall.) That'll greatly change how I handle the waiting. Also, the OSS driver now supports Audio::Latency. Sound should be even lower latency now. On FreeBSD when set to 0ms, it's absolutely incredible. Cannot detect latency whatsoever. The Mario jump sound seems to happen at the very instant I hear my cherry blue keyswitch activate.
2016-08-15 04:56:38 +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 setFrequency(double frequency) -> bool {
if(_frequency == frequency) return true;
_frequency = frequency;
return initialize();
}
auto setLatency(uint latency) -> bool {
if(_latency == latency) return true;
_latency = latency;
return initialize();
}
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(auto n : range(_channels)) {
int16_t sample = samples[n] * 32768.0;
auto unused = write(_fd, &sample, 2);
}
}
private:
auto initialize() -> bool {
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(!information().devices.find(_device)) {
_device = information().devices.left();
}
_fd = open(_device, O_WRONLY, O_NONBLOCK);
if(_fd < 0) return false;
Update to v101r07 release. byuu says: Added VDP sprite rendering. Can't get any games far enough in to see if it actually works. So in other words, it doesn't work at all and is 100% completely broken. Also added 68K exceptions and interrupts. So far only the VDP interrupt is present. It definitely seems to be firing in commercial games, so that's promising. But the implementation is almost certainly completely wrong. There is fuck all of nothing for documentation on how interrupts actually work. I had to find out the interrupt vector numbers from reading the comments from the Sonic the Hedgehog disassembly. I have literally no fucking clue what I0-I2 (3-bit integer priority value in the status register) is supposed to do. I know that Vblank=6, Hblank=4, Ext(gamepad)=2. I know that at reset, SR.I=7. I don't know if I'm supposed to block interrupts when I is >, >=, <, <= to the interrupt level. I don't know what level CPU exceptions are supposed to be. Also implemented VDP regular DMA. No idea if it works correctly since none of the commercial games run far enough to use it. So again, it's horribly broken for usre. Also improved VDP fill mode. But I don't understand how it takes byte-lengths when the bus is 16-bit. The transfer times indicate it's actually transferring at the same speed as the 68K->VDP copy, strongly suggesting it's actually doing 16-bit transfers at a time. In which case, what happens when you set an odd transfer length? Also, both DMA modes can now target VRAM, VSRAM, CRAM. Supposedly there's all kinds of weird shit going on when you target VSRAM, CRAM with VDP fill/copy modes, but whatever. Get to that later. Also implemented a very lazy preliminary wait mechanism to to stall out a processor while another processor exerts control over the bus. This one's going to be a major work in progress. For one, it totally breaks the model I use to do save states with libco. For another, I don't know if a 68K->VDP DMA instantly locks the CPU, or if it the CPU could actually keep running if it was executing out of RAM when it started the DMA transfer from ROM (eg it's a bus busy stall, not a hard chip stall.) That'll greatly change how I handle the waiting. Also, the OSS driver now supports Audio::Latency. Sound should be even lower latency now. On FreeBSD when set to 0ms, it's absolutely incredible. Cannot detect latency whatsoever. The Mario jump sound seems to happen at the very instant I hear my cherry blue keyswitch activate.
2016-08-15 04:56:38 +00:00
int cooked = 1;
ioctl(_fd, SNDCTL_DSP_COOKEDMODE, &cooked);
Update to v101r07 release. byuu says: Added VDP sprite rendering. Can't get any games far enough in to see if it actually works. So in other words, it doesn't work at all and is 100% completely broken. Also added 68K exceptions and interrupts. So far only the VDP interrupt is present. It definitely seems to be firing in commercial games, so that's promising. But the implementation is almost certainly completely wrong. There is fuck all of nothing for documentation on how interrupts actually work. I had to find out the interrupt vector numbers from reading the comments from the Sonic the Hedgehog disassembly. I have literally no fucking clue what I0-I2 (3-bit integer priority value in the status register) is supposed to do. I know that Vblank=6, Hblank=4, Ext(gamepad)=2. I know that at reset, SR.I=7. I don't know if I'm supposed to block interrupts when I is >, >=, <, <= to the interrupt level. I don't know what level CPU exceptions are supposed to be. Also implemented VDP regular DMA. No idea if it works correctly since none of the commercial games run far enough to use it. So again, it's horribly broken for usre. Also improved VDP fill mode. But I don't understand how it takes byte-lengths when the bus is 16-bit. The transfer times indicate it's actually transferring at the same speed as the 68K->VDP copy, strongly suggesting it's actually doing 16-bit transfers at a time. In which case, what happens when you set an odd transfer length? Also, both DMA modes can now target VRAM, VSRAM, CRAM. Supposedly there's all kinds of weird shit going on when you target VSRAM, CRAM with VDP fill/copy modes, but whatever. Get to that later. Also implemented a very lazy preliminary wait mechanism to to stall out a processor while another processor exerts control over the bus. This one's going to be a major work in progress. For one, it totally breaks the model I use to do save states with libco. For another, I don't know if a 68K->VDP DMA instantly locks the CPU, or if it the CPU could actually keep running if it was executing out of RAM when it started the DMA transfer from ROM (eg it's a bus busy stall, not a hard chip stall.) That'll greatly change how I handle the waiting. Also, the OSS driver now supports Audio::Latency. Sound should be even lower latency now. On FreeBSD when set to 0ms, it's absolutely incredible. Cannot detect latency whatsoever. The Mario jump sound seems to happen at the very instant I hear my cherry blue keyswitch activate.
2016-08-15 04:56:38 +00:00
//policy: 0 = minimum latency (higher CPU usage); 10 = maximum latency (lower CPU usage)
int policy = min(10, _latency);
ioctl(_fd, SNDCTL_DSP_POLICY, &policy);
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
int channels = _channels;
ioctl(_fd, SNDCTL_DSP_CHANNELS, &channels);
ioctl(_fd, SNDCTL_DSP_SETFMT, &_format);
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
int frequency = _frequency;
ioctl(_fd, SNDCTL_DSP_SPEED, &frequency);
updateBlocking();
return _ready = true;
}
auto terminate() -> void {
_ready = false;
if(_fd < 0) return;
close(_fd);
_fd = -1;
}
auto updateBlocking() -> void {
if(!_ready) return;
auto flags = fcntl(_fd, F_GETFL);
if(flags < 0) return;
_blocking ? flags &=~ O_NONBLOCK : flags |= O_NONBLOCK;
fcntl(_fd, F_SETFL, flags);
}
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
string _device;
bool _blocking = 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
uint _channels = 2;
double _frequency = 48000.0;
uint _latency = 2;
int _fd = -1;
int _format = AFMT_S16_LE;
};