bsnes/higan/audio/stream.cpp

89 lines
3.0 KiB
C++
Raw Normal View History

Update to v098r14 release. byuu says: Changelog: - improved attenuation of biquad filter by computing butterworth Q coefficients correctly (instead of using the same constant) - adding 1e-25 to each input sample into the biquad filters to try and prevent denormalization - updated normalization from [0.0 to 1.0] to [-1.0 to +1.0]; volume/reverb happen in floating-point mode now - good amount of work to make the base Emulator::Audio support any number of output channels - so that we don't have to do separate work on left/right channels; and can instead share the code for each channel - Emulator::Interface::audioSample(int16 left, int16 right); changed to: - Emulator::Interface::audioSample(double* samples, uint channels); - samples are normalized [-1.0 to +1.0] - for now at least, channels will be the value given to Emulator::Audio::reset() - fixed GUI crash on startup when audio driver is set to None I'm probably going to be updating ruby to accept normalized doubles as well; but I'm not sure if I will try and support anything other 2-channel audio output. It'll depend on how easy it is to do so; perhaps it'll be a per-driver setting. The denormalization thing is fierce. If that happens, it drops the emulator framerate from 220fps to about 20fps for Game Boy emulation. And that happens basically whenever audio output is silent. I'm probably also going to make a nall/denormal.hpp file at some point with platform-specific functionality to set the CPU state to "denormals as zero" where applicable. I'll still add the 1e-25 offset (inaudible) as another fallback.
2016-06-01 11:23:22 +00:00
auto Stream::reset(uint channels_, double inputFrequency, double outputFrequency) -> void {
Update to v102r16 release. byuu says: Changelog: - Emulator::Stream now allows adding low-pass and high-pass filters dynamically - also accepts a pass# count; each pass is a second-order biquad butterworth IIR filter - Emulator::Stream no longer automatically filters out >20KHz frequencies for all streams - FC: added 20Hz high-pass filter; 20KHz low-pass filter - GB: removed simple 'magic constant' high-pass filter of unknown cutoff frequency (missed this one in the last WIP) - GB,SGB,GBC: added 20Hz high-pass filter; 20KHz low-pass filter - MS,GG,MD/PSG: added 20Hz high-pass filter; 20KHz low-pass filter - MD: added save state support (but it's completely broken for now; sorry) - MD/YM2612: fixed Voice#3 per-operator pitch support (fixes sound effects in Streets of Rage, etc) - PCE: added 20Hz high-pass filter; 20KHz low-pass filter - WS,WSC: added 20Hz high-pass filter; 20KHz low-pass filter So, the point of the low-pass filters is to remove frequencies above human hearing. If we don't do this, then resampling will introduce aliasing that results in sounds that are audible to the human ear. Which basically an annoying buzzing sound. You'll definitely hear the improvement from these in games like Mega Man 2 on the NES. Of course, these already existed before, so this WIP won't sound better than previous WIPs. The high-pass filters are a little more complicated. Their main role is to remove DC bias and help to center the audio stream. I don't understand how they do this at all, but ... that's what everyone who knows what they're talking about says, thus ... so be it. I have set all of the high-pass filters to 20Hz, which is below the limit of human hearing. Now this is where it gets really interesting ... technically, some of these systems actually cut off a lot of range. For instance, the GBA should technically use an 800Hz high-pass filter when output is done through the system's speakers. But of course, if you plug in headphones, you can hear the lower frequencies. Now 800Hz ... you definitely can hear. At that level, nearly all of the bass is stripped out and the audio is very tinny. Just like the real system. But for now, I don't want to emulate the audio being crushed that badly. I'm sticking with 20Hz everywhere since it won't negatively affect audio quality. In fact, you should not be able to hear any difference between this WIP and the previous WIP. But theoretically, DC bias should mostly be removed as a result of these new filters. It may be that we need to raise the values on some cores in the future, but I don't want to do that until we know for certain that we have to. What I can say is that compared to even older WIPs than r15 ... the removal of the simple one-pole low-pass and high-pass filters with the newer three-pass, second-order filters should result in much better attenuation (less distortion of audible frequencies.) Probably not enough to be noticeable in a blind test, though.
2017-03-08 20:20:40 +00:00
this->inputFrequency = inputFrequency;
this->outputFrequency = outputFrequency;
Update to v098r14 release. byuu says: Changelog: - improved attenuation of biquad filter by computing butterworth Q coefficients correctly (instead of using the same constant) - adding 1e-25 to each input sample into the biquad filters to try and prevent denormalization - updated normalization from [0.0 to 1.0] to [-1.0 to +1.0]; volume/reverb happen in floating-point mode now - good amount of work to make the base Emulator::Audio support any number of output channels - so that we don't have to do separate work on left/right channels; and can instead share the code for each channel - Emulator::Interface::audioSample(int16 left, int16 right); changed to: - Emulator::Interface::audioSample(double* samples, uint channels); - samples are normalized [-1.0 to +1.0] - for now at least, channels will be the value given to Emulator::Audio::reset() - fixed GUI crash on startup when audio driver is set to None I'm probably going to be updating ruby to accept normalized doubles as well; but I'm not sure if I will try and support anything other 2-channel audio output. It'll depend on how easy it is to do so; perhaps it'll be a per-driver setting. The denormalization thing is fierce. If that happens, it drops the emulator framerate from 220fps to about 20fps for Game Boy emulation. And that happens basically whenever audio output is silent. I'm probably also going to make a nall/denormal.hpp file at some point with platform-specific functionality to set the CPU state to "denormals as zero" where applicable. I'll still add the 1e-25 offset (inaudible) as another fallback.
2016-06-01 11:23:22 +00:00
channels.reset();
channels.resize(channels_);
for(auto& channel : channels) {
Update to v102r16 release. byuu says: Changelog: - Emulator::Stream now allows adding low-pass and high-pass filters dynamically - also accepts a pass# count; each pass is a second-order biquad butterworth IIR filter - Emulator::Stream no longer automatically filters out >20KHz frequencies for all streams - FC: added 20Hz high-pass filter; 20KHz low-pass filter - GB: removed simple 'magic constant' high-pass filter of unknown cutoff frequency (missed this one in the last WIP) - GB,SGB,GBC: added 20Hz high-pass filter; 20KHz low-pass filter - MS,GG,MD/PSG: added 20Hz high-pass filter; 20KHz low-pass filter - MD: added save state support (but it's completely broken for now; sorry) - MD/YM2612: fixed Voice#3 per-operator pitch support (fixes sound effects in Streets of Rage, etc) - PCE: added 20Hz high-pass filter; 20KHz low-pass filter - WS,WSC: added 20Hz high-pass filter; 20KHz low-pass filter So, the point of the low-pass filters is to remove frequencies above human hearing. If we don't do this, then resampling will introduce aliasing that results in sounds that are audible to the human ear. Which basically an annoying buzzing sound. You'll definitely hear the improvement from these in games like Mega Man 2 on the NES. Of course, these already existed before, so this WIP won't sound better than previous WIPs. The high-pass filters are a little more complicated. Their main role is to remove DC bias and help to center the audio stream. I don't understand how they do this at all, but ... that's what everyone who knows what they're talking about says, thus ... so be it. I have set all of the high-pass filters to 20Hz, which is below the limit of human hearing. Now this is where it gets really interesting ... technically, some of these systems actually cut off a lot of range. For instance, the GBA should technically use an 800Hz high-pass filter when output is done through the system's speakers. But of course, if you plug in headphones, you can hear the lower frequencies. Now 800Hz ... you definitely can hear. At that level, nearly all of the bass is stripped out and the audio is very tinny. Just like the real system. But for now, I don't want to emulate the audio being crushed that badly. I'm sticking with 20Hz everywhere since it won't negatively affect audio quality. In fact, you should not be able to hear any difference between this WIP and the previous WIP. But theoretically, DC bias should mostly be removed as a result of these new filters. It may be that we need to raise the values on some cores in the future, but I don't want to do that until we know for certain that we have to. What I can say is that compared to even older WIPs than r15 ... the removal of the simple one-pole low-pass and high-pass filters with the newer three-pass, second-order filters should result in much better attenuation (less distortion of audible frequencies.) Probably not enough to be noticeable in a blind test, though.
2017-03-08 20:20:40 +00:00
channel.filters.reset();
channel.resampler.reset(inputFrequency, outputFrequency);
}
}
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 Stream::setFrequency(double inputFrequency, maybe<double> outputFrequency) -> void {
this->inputFrequency = inputFrequency;
if(outputFrequency) this->outputFrequency = outputFrequency();
for(auto& channel : channels) {
Update to v106r50 release. byuu says: Changelog: - emulator/video,audio: various cleanups - emulator/audio: removed reverb effect (it breaks very badly on high-frequency systems) - emulator/audio: the Nyquist anti-aliasing lowpass filter is now generated automatically instead of set per-core - at 44.1KHz output, it's set to 22KHz; at 48KHz, it's set to 22KHz; at 96KHz, it's set to 25KHz - this filter now takes the bsnes emulation speed setting into account - all system/video.cpp files removed; inlined in System::power() and Interface::set() instead - sfc/cpu: pre-compute `HTIME` as `HTIME+1<<2` for faster comparisons of HIRQs - sfc/cpu: re-add check to block IRQs on the last dot of each frame (minor speed hit) - hiro/gtk3: fixed headers for Linux compilation finally - hiro/gtk,qt: fixed settings.cpp logic so initial values are used when no settings.bml file exists - hiro/gtk: started a minor experiment to specify theming information in settings.bml files - nall/dsp: allow the precision type (double) to be overridden (to float) - nall: add some helpers for generating pre-compiled headers - it was a failure to try using them for higan, however ... - nall: add some helpers for reading fallback values from empty `Markup::Node[search]` statements Todo: - CRITICAL: a lot of my IRQ/NMI/HDMA timing tests are failing with the fast PPU ... need to figure out why - space between Emulator::video functions and Emulator::audio functions in gb/system/system.cpp - remove Audio/Reverb/Enable from settings.bml in target-bsnes
2018-07-21 11:06:40 +00:00
channel.nyquist.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
channel.resampler.reset(this->inputFrequency, this->outputFrequency);
}
Update to v106r50 release. byuu says: Changelog: - emulator/video,audio: various cleanups - emulator/audio: removed reverb effect (it breaks very badly on high-frequency systems) - emulator/audio: the Nyquist anti-aliasing lowpass filter is now generated automatically instead of set per-core - at 44.1KHz output, it's set to 22KHz; at 48KHz, it's set to 22KHz; at 96KHz, it's set to 25KHz - this filter now takes the bsnes emulation speed setting into account - all system/video.cpp files removed; inlined in System::power() and Interface::set() instead - sfc/cpu: pre-compute `HTIME` as `HTIME+1<<2` for faster comparisons of HIRQs - sfc/cpu: re-add check to block IRQs on the last dot of each frame (minor speed hit) - hiro/gtk3: fixed headers for Linux compilation finally - hiro/gtk,qt: fixed settings.cpp logic so initial values are used when no settings.bml file exists - hiro/gtk: started a minor experiment to specify theming information in settings.bml files - nall/dsp: allow the precision type (double) to be overridden (to float) - nall: add some helpers for generating pre-compiled headers - it was a failure to try using them for higan, however ... - nall: add some helpers for reading fallback values from empty `Markup::Node[search]` statements Todo: - CRITICAL: a lot of my IRQ/NMI/HDMA timing tests are failing with the fast PPU ... need to figure out why - space between Emulator::video functions and Emulator::audio functions in gb/system/system.cpp - remove Audio/Reverb/Enable from settings.bml in target-bsnes
2018-07-21 11:06:40 +00:00
if(this->inputFrequency >= this->outputFrequency * 2) {
//add a low-pass filter to prevent aliasing during resampling
double cutoffFrequency = min(25000.0, this->outputFrequency / 2.0 - 2000.0);
for(auto& channel : channels) {
uint passes = 3;
for(uint pass : range(passes)) {
DSP::IIR::Biquad filter;
double q = DSP::IIR::Biquad::butterworth(passes * 2, pass);
filter.reset(DSP::IIR::Biquad::Type::LowPass, cutoffFrequency, this->inputFrequency, q);
channel.nyquist.append(filter);
}
}
}
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 v103r01 release. byuu says: Changelog: - nall/dsp: improve one pole coefficient calculations [Fatbag] - higan/audio: reworked filters to support selection of either one pole (first-order) or biquad (second-order) filters - note: the design is not stable yet; so forks should not put too much effort into synchronizing with this change yet - fc: added first-order filters as per NESdev wiki (90hz lowpass + 440hz lowpass + 14khz highpass) - fc: created separate NTSC-J and NTSC-U regions - NESdev wiki says the Japanese Famicom uses a separate audio filtering strategy, but details are fuzzy - there's also cartridge audio output being disabled on NES units; and differences with controllers - this stuff will be supported in the future, just adding the support for it now - gba: corrected serious bugs in PSG wave channel emulation [Cydrak] - note that if there are still bugs here, it's my fault - md/psg,ym2612: added first-order low-pass 2840hz filter to match VA3-VA6 Mega Drives - md/psg: lowered volume relative to the YM2612 - using 0x1400; multiple people agreed it was the closest to the hardware recordings against a VA6 - ms,md/psg: don't serialize the volume levels array - md/vdp: Hblank bit acts the same during Vblank as outside of it (it isn't always set during Vblank) - md/vdp: return isPAL in bit 0 of control port reads - tomoko: change command-line option separator from : to | - [Editor's note: This change was present in the public v103, but it's in this changelog because it was made after the v103 WIP] - higan/all: change the 20hz high-pass filters from second-order three-pass to first-order one-pass - these filters are meant to remove DC bias, but I honestly can't hear a difference with or without them - so there's really no sense wasting CPU power with an extremely powerful filter here Things I did not do: - change icarus install rule - work on 8-bit Mega Drive SRAM - work on Famicom or Mega Drive region detection heuristics in icarus My long-term dream plan is to devise a special user-configurable filtering system where you can set relative volumes and create your own list of filters (any number of them in any order at any frequency), that way people can make the systems sound however they want. Right now, the sanest place to put this information is inside the $system.sys/manifest.bml files. But that's not very user friendly, and upgrading to new versions will lose these changes if you don't copy them over manually. Of course, cluttering the GUI with a fancy filter editor is probably supreme overkill for 99% of users, so maybe that's fine.
2017-06-26 01:41:58 +00:00
auto Stream::addFilter(Filter::Order order, Filter::Type type, double cutoffFrequency, uint passes) -> void {
Update to v102r16 release. byuu says: Changelog: - Emulator::Stream now allows adding low-pass and high-pass filters dynamically - also accepts a pass# count; each pass is a second-order biquad butterworth IIR filter - Emulator::Stream no longer automatically filters out >20KHz frequencies for all streams - FC: added 20Hz high-pass filter; 20KHz low-pass filter - GB: removed simple 'magic constant' high-pass filter of unknown cutoff frequency (missed this one in the last WIP) - GB,SGB,GBC: added 20Hz high-pass filter; 20KHz low-pass filter - MS,GG,MD/PSG: added 20Hz high-pass filter; 20KHz low-pass filter - MD: added save state support (but it's completely broken for now; sorry) - MD/YM2612: fixed Voice#3 per-operator pitch support (fixes sound effects in Streets of Rage, etc) - PCE: added 20Hz high-pass filter; 20KHz low-pass filter - WS,WSC: added 20Hz high-pass filter; 20KHz low-pass filter So, the point of the low-pass filters is to remove frequencies above human hearing. If we don't do this, then resampling will introduce aliasing that results in sounds that are audible to the human ear. Which basically an annoying buzzing sound. You'll definitely hear the improvement from these in games like Mega Man 2 on the NES. Of course, these already existed before, so this WIP won't sound better than previous WIPs. The high-pass filters are a little more complicated. Their main role is to remove DC bias and help to center the audio stream. I don't understand how they do this at all, but ... that's what everyone who knows what they're talking about says, thus ... so be it. I have set all of the high-pass filters to 20Hz, which is below the limit of human hearing. Now this is where it gets really interesting ... technically, some of these systems actually cut off a lot of range. For instance, the GBA should technically use an 800Hz high-pass filter when output is done through the system's speakers. But of course, if you plug in headphones, you can hear the lower frequencies. Now 800Hz ... you definitely can hear. At that level, nearly all of the bass is stripped out and the audio is very tinny. Just like the real system. But for now, I don't want to emulate the audio being crushed that badly. I'm sticking with 20Hz everywhere since it won't negatively affect audio quality. In fact, you should not be able to hear any difference between this WIP and the previous WIP. But theoretically, DC bias should mostly be removed as a result of these new filters. It may be that we need to raise the values on some cores in the future, but I don't want to do that until we know for certain that we have to. What I can say is that compared to even older WIPs than r15 ... the removal of the simple one-pole low-pass and high-pass filters with the newer three-pass, second-order filters should result in much better attenuation (less distortion of audible frequencies.) Probably not enough to be noticeable in a blind test, though.
2017-03-08 20:20:40 +00:00
for(auto& channel : channels) {
Update to v106r50 release. byuu says: Changelog: - emulator/video,audio: various cleanups - emulator/audio: removed reverb effect (it breaks very badly on high-frequency systems) - emulator/audio: the Nyquist anti-aliasing lowpass filter is now generated automatically instead of set per-core - at 44.1KHz output, it's set to 22KHz; at 48KHz, it's set to 22KHz; at 96KHz, it's set to 25KHz - this filter now takes the bsnes emulation speed setting into account - all system/video.cpp files removed; inlined in System::power() and Interface::set() instead - sfc/cpu: pre-compute `HTIME` as `HTIME+1<<2` for faster comparisons of HIRQs - sfc/cpu: re-add check to block IRQs on the last dot of each frame (minor speed hit) - hiro/gtk3: fixed headers for Linux compilation finally - hiro/gtk,qt: fixed settings.cpp logic so initial values are used when no settings.bml file exists - hiro/gtk: started a minor experiment to specify theming information in settings.bml files - nall/dsp: allow the precision type (double) to be overridden (to float) - nall: add some helpers for generating pre-compiled headers - it was a failure to try using them for higan, however ... - nall: add some helpers for reading fallback values from empty `Markup::Node[search]` statements Todo: - CRITICAL: a lot of my IRQ/NMI/HDMA timing tests are failing with the fast PPU ... need to figure out why - space between Emulator::video functions and Emulator::audio functions in gb/system/system.cpp - remove Audio/Reverb/Enable from settings.bml in target-bsnes
2018-07-21 11:06:40 +00:00
for(uint pass : range(passes)) {
Update to v103r01 release. byuu says: Changelog: - nall/dsp: improve one pole coefficient calculations [Fatbag] - higan/audio: reworked filters to support selection of either one pole (first-order) or biquad (second-order) filters - note: the design is not stable yet; so forks should not put too much effort into synchronizing with this change yet - fc: added first-order filters as per NESdev wiki (90hz lowpass + 440hz lowpass + 14khz highpass) - fc: created separate NTSC-J and NTSC-U regions - NESdev wiki says the Japanese Famicom uses a separate audio filtering strategy, but details are fuzzy - there's also cartridge audio output being disabled on NES units; and differences with controllers - this stuff will be supported in the future, just adding the support for it now - gba: corrected serious bugs in PSG wave channel emulation [Cydrak] - note that if there are still bugs here, it's my fault - md/psg,ym2612: added first-order low-pass 2840hz filter to match VA3-VA6 Mega Drives - md/psg: lowered volume relative to the YM2612 - using 0x1400; multiple people agreed it was the closest to the hardware recordings against a VA6 - ms,md/psg: don't serialize the volume levels array - md/vdp: Hblank bit acts the same during Vblank as outside of it (it isn't always set during Vblank) - md/vdp: return isPAL in bit 0 of control port reads - tomoko: change command-line option separator from : to | - [Editor's note: This change was present in the public v103, but it's in this changelog because it was made after the v103 WIP] - higan/all: change the 20hz high-pass filters from second-order three-pass to first-order one-pass - these filters are meant to remove DC bias, but I honestly can't hear a difference with or without them - so there's really no sense wasting CPU power with an extremely powerful filter here Things I did not do: - change icarus install rule - work on 8-bit Mega Drive SRAM - work on Famicom or Mega Drive region detection heuristics in icarus My long-term dream plan is to devise a special user-configurable filtering system where you can set relative volumes and create your own list of filters (any number of them in any order at any frequency), that way people can make the systems sound however they want. Right now, the sanest place to put this information is inside the $system.sys/manifest.bml files. But that's not very user friendly, and upgrading to new versions will lose these changes if you don't copy them over manually. Of course, cluttering the GUI with a fancy filter editor is probably supreme overkill for 99% of users, so maybe that's fine.
2017-06-26 01:41:58 +00:00
Filter filter{order};
if(order == Filter::Order::First) {
DSP::IIR::OnePole::Type _type;
if(type == Filter::Type::LowPass) _type = DSP::IIR::OnePole::Type::LowPass;
if(type == Filter::Type::HighPass) _type = DSP::IIR::OnePole::Type::HighPass;
filter.onePole.reset(_type, cutoffFrequency, inputFrequency);
}
if(order == Filter::Order::Second) {
DSP::IIR::Biquad::Type _type;
if(type == Filter::Type::LowPass) _type = DSP::IIR::Biquad::Type::LowPass;
if(type == Filter::Type::HighPass) _type = DSP::IIR::Biquad::Type::HighPass;
double q = DSP::IIR::Biquad::butterworth(passes * 2, pass);
filter.biquad.reset(_type, cutoffFrequency, inputFrequency, q);
}
channel.filters.append(filter);
Update to v102r16 release. byuu says: Changelog: - Emulator::Stream now allows adding low-pass and high-pass filters dynamically - also accepts a pass# count; each pass is a second-order biquad butterworth IIR filter - Emulator::Stream no longer automatically filters out >20KHz frequencies for all streams - FC: added 20Hz high-pass filter; 20KHz low-pass filter - GB: removed simple 'magic constant' high-pass filter of unknown cutoff frequency (missed this one in the last WIP) - GB,SGB,GBC: added 20Hz high-pass filter; 20KHz low-pass filter - MS,GG,MD/PSG: added 20Hz high-pass filter; 20KHz low-pass filter - MD: added save state support (but it's completely broken for now; sorry) - MD/YM2612: fixed Voice#3 per-operator pitch support (fixes sound effects in Streets of Rage, etc) - PCE: added 20Hz high-pass filter; 20KHz low-pass filter - WS,WSC: added 20Hz high-pass filter; 20KHz low-pass filter So, the point of the low-pass filters is to remove frequencies above human hearing. If we don't do this, then resampling will introduce aliasing that results in sounds that are audible to the human ear. Which basically an annoying buzzing sound. You'll definitely hear the improvement from these in games like Mega Man 2 on the NES. Of course, these already existed before, so this WIP won't sound better than previous WIPs. The high-pass filters are a little more complicated. Their main role is to remove DC bias and help to center the audio stream. I don't understand how they do this at all, but ... that's what everyone who knows what they're talking about says, thus ... so be it. I have set all of the high-pass filters to 20Hz, which is below the limit of human hearing. Now this is where it gets really interesting ... technically, some of these systems actually cut off a lot of range. For instance, the GBA should technically use an 800Hz high-pass filter when output is done through the system's speakers. But of course, if you plug in headphones, you can hear the lower frequencies. Now 800Hz ... you definitely can hear. At that level, nearly all of the bass is stripped out and the audio is very tinny. Just like the real system. But for now, I don't want to emulate the audio being crushed that badly. I'm sticking with 20Hz everywhere since it won't negatively affect audio quality. In fact, you should not be able to hear any difference between this WIP and the previous WIP. But theoretically, DC bias should mostly be removed as a result of these new filters. It may be that we need to raise the values on some cores in the future, but I don't want to do that until we know for certain that we have to. What I can say is that compared to even older WIPs than r15 ... the removal of the simple one-pole low-pass and high-pass filters with the newer three-pass, second-order filters should result in much better attenuation (less distortion of audible frequencies.) Probably not enough to be noticeable in a blind test, though.
2017-03-08 20:20:40 +00:00
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
}
}
auto Stream::pending() const -> bool {
Update to v098r14 release. byuu says: Changelog: - improved attenuation of biquad filter by computing butterworth Q coefficients correctly (instead of using the same constant) - adding 1e-25 to each input sample into the biquad filters to try and prevent denormalization - updated normalization from [0.0 to 1.0] to [-1.0 to +1.0]; volume/reverb happen in floating-point mode now - good amount of work to make the base Emulator::Audio support any number of output channels - so that we don't have to do separate work on left/right channels; and can instead share the code for each channel - Emulator::Interface::audioSample(int16 left, int16 right); changed to: - Emulator::Interface::audioSample(double* samples, uint channels); - samples are normalized [-1.0 to +1.0] - for now at least, channels will be the value given to Emulator::Audio::reset() - fixed GUI crash on startup when audio driver is set to None I'm probably going to be updating ruby to accept normalized doubles as well; but I'm not sure if I will try and support anything other 2-channel audio output. It'll depend on how easy it is to do so; perhaps it'll be a per-driver setting. The denormalization thing is fierce. If that happens, it drops the emulator framerate from 220fps to about 20fps for Game Boy emulation. And that happens basically whenever audio output is silent. I'm probably also going to make a nall/denormal.hpp file at some point with platform-specific functionality to set the CPU state to "denormals as zero" where applicable. I'll still add the 1e-25 offset (inaudible) as another fallback.
2016-06-01 11:23:22 +00:00
return channels && channels[0].resampler.pending();
}
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 Stream::read(double samples[]) -> uint {
Update to 20180728 release. byuu says: Sigh, I seem to be spiraling a bit here ... but the work is very important. Hopefully I can get a solid WIP together soon. But for now... I've integrated dynamic rate control into ruby::Audio via setDynamic(bool) for now. It's very demanding, as you would expect. When it's not in use, I realized the OSS driver's performance was pretty bad due to calling write() for every sample for every channel. I implemented a tiny 256-sample buffer and bsnes went from 290fps to 330fps on my FreeBSD desktop. It may be possible to do the same buffering with DRC, but for now, I'm not doing so, and adjusting the audio input frequency on every sample. I also added ruby::Video::setFlush(bool), which is available only in the OpenGL drivers, and this causes glFinish() to be called after swapping display buffers. I really couldn't think of a good name for this, "hard GPU sync" sounds kind of silly. In my view, flush is what commits queued events. Eg fflush(). OpenGL of course treats glFlush differently (I really don't even know what the point of it is even after reading the manual ...), and then has glFinish ... meh, whatever. It's setFlush(bool) until I come up with something better. Also as expected, this one's a big hit to performance. To implement the DRC, I started putting helper functions into the ruby video/audio/input core classes. And then the XVideo driver started crashing. It took hours and hours and hours to track down the problem: you have to clear XSetWindowAttributes to zero before calling XCreateWindow. No amount of `--sync`, `gdb break gdk_x_error`, `-Og`, etc will make Xlib be even remotely helpful in debugging errors like this. The GLX, GLX2, and XVideo drivers basically worked by chance before. If the stack frame had the right memory cleared, it worked. Otherwise it'd crash with BadValue, and my changing things broke that condition on the XVideo driver. So this has been fixed in all three now. Once XVideo was running again, I realized that non-power of two video sizes were completely broken for the YUV formats. It took a while, but I managed to fix all of that as well. At this point, most of ruby is going to be broken outside of FreeBSD, as I still need to finish updating all the drivers.
2018-07-28 11:21:39 +00:00
for(uint c : range(channels.size())) samples[c] = channels[c].resampler.read();
Update to v098r14 release. byuu says: Changelog: - improved attenuation of biquad filter by computing butterworth Q coefficients correctly (instead of using the same constant) - adding 1e-25 to each input sample into the biquad filters to try and prevent denormalization - updated normalization from [0.0 to 1.0] to [-1.0 to +1.0]; volume/reverb happen in floating-point mode now - good amount of work to make the base Emulator::Audio support any number of output channels - so that we don't have to do separate work on left/right channels; and can instead share the code for each channel - Emulator::Interface::audioSample(int16 left, int16 right); changed to: - Emulator::Interface::audioSample(double* samples, uint channels); - samples are normalized [-1.0 to +1.0] - for now at least, channels will be the value given to Emulator::Audio::reset() - fixed GUI crash on startup when audio driver is set to None I'm probably going to be updating ruby to accept normalized doubles as well; but I'm not sure if I will try and support anything other 2-channel audio output. It'll depend on how easy it is to do so; perhaps it'll be a per-driver setting. The denormalization thing is fierce. If that happens, it drops the emulator framerate from 220fps to about 20fps for Game Boy emulation. And that happens basically whenever audio output is silent. I'm probably also going to make a nall/denormal.hpp file at some point with platform-specific functionality to set the CPU state to "denormals as zero" where applicable. I'll still add the 1e-25 offset (inaudible) as another fallback.
2016-06-01 11:23:22 +00:00
return channels.size();
}
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 Stream::write(const double samples[]) -> void {
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
for(auto c : range(channels.size())) {
Update to v098r14 release. byuu says: Changelog: - improved attenuation of biquad filter by computing butterworth Q coefficients correctly (instead of using the same constant) - adding 1e-25 to each input sample into the biquad filters to try and prevent denormalization - updated normalization from [0.0 to 1.0] to [-1.0 to +1.0]; volume/reverb happen in floating-point mode now - good amount of work to make the base Emulator::Audio support any number of output channels - so that we don't have to do separate work on left/right channels; and can instead share the code for each channel - Emulator::Interface::audioSample(int16 left, int16 right); changed to: - Emulator::Interface::audioSample(double* samples, uint channels); - samples are normalized [-1.0 to +1.0] - for now at least, channels will be the value given to Emulator::Audio::reset() - fixed GUI crash on startup when audio driver is set to None I'm probably going to be updating ruby to accept normalized doubles as well; but I'm not sure if I will try and support anything other 2-channel audio output. It'll depend on how easy it is to do so; perhaps it'll be a per-driver setting. The denormalization thing is fierce. If that happens, it drops the emulator framerate from 220fps to about 20fps for Game Boy emulation. And that happens basically whenever audio output is silent. I'm probably also going to make a nall/denormal.hpp file at some point with platform-specific functionality to set the CPU state to "denormals as zero" where applicable. I'll still add the 1e-25 offset (inaudible) as another fallback.
2016-06-01 11:23:22 +00:00
double sample = samples[c] + 1e-25; //constant offset used to suppress denormals
Update to v103r01 release. byuu says: Changelog: - nall/dsp: improve one pole coefficient calculations [Fatbag] - higan/audio: reworked filters to support selection of either one pole (first-order) or biquad (second-order) filters - note: the design is not stable yet; so forks should not put too much effort into synchronizing with this change yet - fc: added first-order filters as per NESdev wiki (90hz lowpass + 440hz lowpass + 14khz highpass) - fc: created separate NTSC-J and NTSC-U regions - NESdev wiki says the Japanese Famicom uses a separate audio filtering strategy, but details are fuzzy - there's also cartridge audio output being disabled on NES units; and differences with controllers - this stuff will be supported in the future, just adding the support for it now - gba: corrected serious bugs in PSG wave channel emulation [Cydrak] - note that if there are still bugs here, it's my fault - md/psg,ym2612: added first-order low-pass 2840hz filter to match VA3-VA6 Mega Drives - md/psg: lowered volume relative to the YM2612 - using 0x1400; multiple people agreed it was the closest to the hardware recordings against a VA6 - ms,md/psg: don't serialize the volume levels array - md/vdp: Hblank bit acts the same during Vblank as outside of it (it isn't always set during Vblank) - md/vdp: return isPAL in bit 0 of control port reads - tomoko: change command-line option separator from : to | - [Editor's note: This change was present in the public v103, but it's in this changelog because it was made after the v103 WIP] - higan/all: change the 20hz high-pass filters from second-order three-pass to first-order one-pass - these filters are meant to remove DC bias, but I honestly can't hear a difference with or without them - so there's really no sense wasting CPU power with an extremely powerful filter here Things I did not do: - change icarus install rule - work on 8-bit Mega Drive SRAM - work on Famicom or Mega Drive region detection heuristics in icarus My long-term dream plan is to devise a special user-configurable filtering system where you can set relative volumes and create your own list of filters (any number of them in any order at any frequency), that way people can make the systems sound however they want. Right now, the sanest place to put this information is inside the $system.sys/manifest.bml files. But that's not very user friendly, and upgrading to new versions will lose these changes if you don't copy them over manually. Of course, cluttering the GUI with a fancy filter editor is probably supreme overkill for 99% of users, so maybe that's fine.
2017-06-26 01:41:58 +00:00
for(auto& filter : channels[c].filters) {
switch(filter.order) {
case Filter::Order::First: sample = filter.onePole.process(sample); break;
case Filter::Order::Second: sample = filter.biquad.process(sample); break;
}
}
Update to v106r50 release. byuu says: Changelog: - emulator/video,audio: various cleanups - emulator/audio: removed reverb effect (it breaks very badly on high-frequency systems) - emulator/audio: the Nyquist anti-aliasing lowpass filter is now generated automatically instead of set per-core - at 44.1KHz output, it's set to 22KHz; at 48KHz, it's set to 22KHz; at 96KHz, it's set to 25KHz - this filter now takes the bsnes emulation speed setting into account - all system/video.cpp files removed; inlined in System::power() and Interface::set() instead - sfc/cpu: pre-compute `HTIME` as `HTIME+1<<2` for faster comparisons of HIRQs - sfc/cpu: re-add check to block IRQs on the last dot of each frame (minor speed hit) - hiro/gtk3: fixed headers for Linux compilation finally - hiro/gtk,qt: fixed settings.cpp logic so initial values are used when no settings.bml file exists - hiro/gtk: started a minor experiment to specify theming information in settings.bml files - nall/dsp: allow the precision type (double) to be overridden (to float) - nall: add some helpers for generating pre-compiled headers - it was a failure to try using them for higan, however ... - nall: add some helpers for reading fallback values from empty `Markup::Node[search]` statements Todo: - CRITICAL: a lot of my IRQ/NMI/HDMA timing tests are failing with the fast PPU ... need to figure out why - space between Emulator::video functions and Emulator::audio functions in gb/system/system.cpp - remove Audio/Reverb/Enable from settings.bml in target-bsnes
2018-07-21 11:06:40 +00:00
for(auto& filter : channels[c].nyquist) {
sample = filter.process(sample);
}
Update to v098r14 release. byuu says: Changelog: - improved attenuation of biquad filter by computing butterworth Q coefficients correctly (instead of using the same constant) - adding 1e-25 to each input sample into the biquad filters to try and prevent denormalization - updated normalization from [0.0 to 1.0] to [-1.0 to +1.0]; volume/reverb happen in floating-point mode now - good amount of work to make the base Emulator::Audio support any number of output channels - so that we don't have to do separate work on left/right channels; and can instead share the code for each channel - Emulator::Interface::audioSample(int16 left, int16 right); changed to: - Emulator::Interface::audioSample(double* samples, uint channels); - samples are normalized [-1.0 to +1.0] - for now at least, channels will be the value given to Emulator::Audio::reset() - fixed GUI crash on startup when audio driver is set to None I'm probably going to be updating ruby to accept normalized doubles as well; but I'm not sure if I will try and support anything other 2-channel audio output. It'll depend on how easy it is to do so; perhaps it'll be a per-driver setting. The denormalization thing is fierce. If that happens, it drops the emulator framerate from 220fps to about 20fps for Game Boy emulation. And that happens basically whenever audio output is silent. I'm probably also going to make a nall/denormal.hpp file at some point with platform-specific functionality to set the CPU state to "denormals as zero" where applicable. I'll still add the 1e-25 offset (inaudible) as another fallback.
2016-06-01 11:23:22 +00:00
channels[c].resampler.write(sample);
}
Update to v098r14 release. byuu says: Changelog: - improved attenuation of biquad filter by computing butterworth Q coefficients correctly (instead of using the same constant) - adding 1e-25 to each input sample into the biquad filters to try and prevent denormalization - updated normalization from [0.0 to 1.0] to [-1.0 to +1.0]; volume/reverb happen in floating-point mode now - good amount of work to make the base Emulator::Audio support any number of output channels - so that we don't have to do separate work on left/right channels; and can instead share the code for each channel - Emulator::Interface::audioSample(int16 left, int16 right); changed to: - Emulator::Interface::audioSample(double* samples, uint channels); - samples are normalized [-1.0 to +1.0] - for now at least, channels will be the value given to Emulator::Audio::reset() - fixed GUI crash on startup when audio driver is set to None I'm probably going to be updating ruby to accept normalized doubles as well; but I'm not sure if I will try and support anything other 2-channel audio output. It'll depend on how easy it is to do so; perhaps it'll be a per-driver setting. The denormalization thing is fierce. If that happens, it drops the emulator framerate from 220fps to about 20fps for Game Boy emulation. And that happens basically whenever audio output is silent. I'm probably also going to make a nall/denormal.hpp file at some point with platform-specific functionality to set the CPU state to "denormals as zero" where applicable. I'll still add the 1e-25 offset (inaudible) as another fallback.
2016-06-01 11:23:22 +00:00
audio.process();
}