diff options
Diffstat (limited to 'src/emu')
-rw-r--r-- | src/emu/disound.h | 2 | ||||
-rw-r--r-- | src/emu/sound.cpp | 2 | ||||
-rw-r--r-- | src/emu/sound.h | 86 |
3 files changed, 47 insertions, 43 deletions
diff --git a/src/emu/disound.h b/src/emu/disound.h index d6135123ddb..db6456dfc9a 100644 --- a/src/emu/disound.h +++ b/src/emu/disound.h @@ -138,7 +138,7 @@ protected: // internal state u8 m_outputs; // number of outputs std::vector<u8> m_outputmap; // map of inputs to outputs - std::vector<bool> m_output_clear; // flag for tracking cleared buffers + std::vector<bool> m_output_clear; // flag for tracking cleared buffers sound_stream *m_mixer_stream; // mixing stream }; diff --git a/src/emu/sound.cpp b/src/emu/sound.cpp index 1bb5ce0c40b..1c33166524f 100644 --- a/src/emu/sound.cpp +++ b/src/emu/sound.cpp @@ -393,7 +393,7 @@ void sound_stream_output::init(sound_stream &stream, u32 index, char const *tag) #if (LOG_OUTPUT_WAV) std::string filename = stream.device().machine().basename(); - filename += stream.device().tag(); + filename += stream.device().tag(); for (int index = 0; index < filename.size(); index++) if (filename[index] == ':') filename[index] = '_'; diff --git a/src/emu/sound.h b/src/emu/sound.h index 03c5ccb335e..f592c0f9f3c 100644 --- a/src/emu/sound.h +++ b/src/emu/sound.h @@ -8,47 +8,47 @@ **************************************************************************** - In MAME, sound is represented as a graph of sound "streams". Each - stream has a fixed number of inputs and outputs, and is responsible - for producing sound on demand. - - The graph is driven from the outputs, which are speaker devices. - These devices are updated on a regular basis (~50 times per second), - and when an update occurs, the graph is walked from the speaker - through each input, until all connected streams are up to date. - - Individual streams can also be updated manually. This is important - for sound chips and CPU-driven devices, who should force any - affected streams to update prior to making changes. - - Sound streams are *not* part of the device execution model. This is - very important to understand. If the process of producing the ouput - stream affects state that might be consumed by an executing device - (e.g., a CPU), then care must be taken to ensure that the stream is - updated frequently enough - - The model for timing sound samples is very important and explained - here. Each stream source has a clock (aka sample rate). Each clock - edge represents a sample that is held for the duration of one clock - period. This model has interesting effects: - - For example, if you have a 10Hz clock, and call stream.update() at - t=0.91, it will compute 10 samples (for clock edges 0.0, 0.1, 0.2, - ..., 0.7, 0.8, and 0.9). And then if you ask the stream what its - current end time is (via stream.sample_time()), it will say t=1.0, - which is in the future, because it knows it will hold that last - sample until 1.0s. - - Sound generation callbacks are presented with a std::vector of inputs - and outputs. The vectors contain objects of read_stream_view and - write_stream_view respectively, which wrap access to a circular buffer - of samples. Sound generation callbacks are expected to fill all the - samples described by the outputs' write_stream_view objects. At the - moment, all outputs have the same sample rate, so the number of samples - that need to be generated will be consistent across all outputs. - - By default, the inputs will have been resampled to match the output - sample rate, unless otherwise specified. + In MAME, sound is represented as a graph of sound "streams". Each + stream has a fixed number of inputs and outputs, and is responsible + for producing sound on demand. + + The graph is driven from the outputs, which are speaker devices. + These devices are updated on a regular basis (~50 times per second), + and when an update occurs, the graph is walked from the speaker + through each input, until all connected streams are up to date. + + Individual streams can also be updated manually. This is important + for sound chips and CPU-driven devices, who should force any + affected streams to update prior to making changes. + + Sound streams are *not* part of the device execution model. This is + very important to understand. If the process of producing the ouput + stream affects state that might be consumed by an executing device + (e.g., a CPU), then care must be taken to ensure that the stream is + updated frequently enough + + The model for timing sound samples is very important and explained + here. Each stream source has a clock (aka sample rate). Each clock + edge represents a sample that is held for the duration of one clock + period. This model has interesting effects: + + For example, if you have a 10Hz clock, and call stream.update() at + t=0.91, it will compute 10 samples (for clock edges 0.0, 0.1, 0.2, + ..., 0.7, 0.8, and 0.9). And then if you ask the stream what its + current end time is (via stream.sample_time()), it will say t=1.0, + which is in the future, because it knows it will hold that last + sample until 1.0s. + + Sound generation callbacks are presented with a std::vector of inputs + and outputs. The vectors contain objects of read_stream_view and + write_stream_view respectively, which wrap access to a circular buffer + of samples. Sound generation callbacks are expected to fill all the + samples described by the outputs' write_stream_view objects. At the + moment, all outputs have the same sample rate, so the number of samples + that need to be generated will be consistent across all outputs. + + By default, the inputs will have been resampled to match the output + sample rate, unless otherwise specified. ***************************************************************************/ @@ -81,7 +81,11 @@ constexpr u32 SAMPLE_RATE_MINIMUM = 50; //************************************************************************** // turn this on to enable aggressive assertions and other checks +#ifdef MAME_DEBUG #define SOUND_DEBUG (1) +#else +#define SOUND_DEBUG (0) +#endif // if SOUND_DEBUG is on, make assertions fire regardless of MAME_DEBUG #if (SOUND_DEBUG) |