New sound system development discussion

[cuavas]

A place to discuss development issues with the new sound system, and hopefully get the attention of @galibert.

[cuavas]

After a great deal of frustration, I discovered that the sound manager ignores microphones with position { 0.0, 0.0, 0.0 } (i.e. colocated with listener) which I’d been using for “unknown position”. As a workaround, I changed it to treat anything unknown as { 0.0, 0.0, 1.0 } front centre. Is there a reason for this? In my mind it makes sense for a microphone/speaker we have no direction information for.

[galibert]

That's fixed now.

[cuavas]

Already mentioned this to @galibert, but it would be nice to decouple display names from configuration strings. On Windows, display names can be changed easily, but endpoint IDs are fairly stable. Display names look like Speakers (Audioengine D1 ) while endpoint IDs look like {0.0.0.00000000}.{ab41b287-bcf2-4c33-8126-e51ecf62b950}. Obviously you don’t want to show the endpoint IDs to the user in the UI.

[galibert]

Shouldn't be too bad to add, just need a m_display_name to use in the audiomix menu.

[galibert]

As you noticed, it's done.

[cuavas]

Is there going to be a way to tell MAME the frequency range that speakers are expected to have? Windows lets you know which channel is the low-frequency effects output (if any) and which channels the user has indicated are “full range” speakers (i.e. having full bass, mid and treble reproduction capabilities, while speakers that are not “full range” can be expected to lack bass response).

[galibert]

Is there any sense given modern setups to have any other cases than "normal" and "LFE"?

[cuavas]

Not really. “Modern” setups (e.g. home theatre systems) tend to have setups like:

• Full range front left
• Full range front right
• Mid only centre (mostly for placing dialog)
• Mid/high only back left
• Mid/high only back right
• Low-frequency effects

Cheaper home theatre setups (which is a lot of them in terms of proportion of sales) don’t even have full range front left and front right (mid/high only).

Can we get some kind of flag fields or something for indicating characteristics of speakers (and/or microphones) if we can nail down a list of flags that would be useful?

[galibert]

What I wonder if whether we need flags (which we can have, mind you), or if we can consider LFE a special position (like 0,0,11) with special handling and that would be enough? LFE is not supposed to be in any specific place in the room in any case.

[cuavas]

Is there going to be a way to help the OSD synchronise audio across streams? For example, XAudio2 makes it easy to synchronise streams for a single output device, but MAME doesn’t really tell you timing information about updates. I could do something hacky, like after a stream is created, flush all existing streams on the device, then atomically start them on the next update. But that feels dirty.

[galibert]

I'm not sure what you're aiming at. In the real world, speaker placement gives you variable latencies. In the emulated world, the resampling adds latencies that depend on the source and target frequencies and the resampler type. Outside of keeping the linked channels in sync (e.g. left and right in a stereo output) which we do by sending the data interleaved, I'm not sure where we could do better or how it would make sense. Take an atari st with a mv16 dac cartridge, you have three independant (=non synchronized) speakers. The mv16 you tend to hear on headphones, the usual sound on the tv and the floppy is on the right in the box. Those have very different latencies no matter what. Unless we go play with spatial positioning of the three speakers to send to a 5.1 environment (which would then be synchronized, because interleaved), I don't see what you're looking for.

[cuavas]

I just want sample-accurate synchronisation between channels on an output device where possible. If just the part where samples are pushed to the OSD is bracketed with begin_update()/end_update() (i.e. no opening/closing streams between the calls, no other expensive operations, calls guaranteed to be balanced), I can achieve that with XAudio2 at least.

[galibert]

I don't see the point (because channels on an output device are already in sync given what is sent to you is interleaved channels) but it's trivial enough too add, so it's done.

[cuavas]

Channels on a single stream are inherently in sync due to being interleaved. Channels on multiple streams on the same device are not. Without the bracketing, the OSD module doesn’t know which stream updates logically happen at the same time.

[galibert]

Sure, but they're going to be coming from different emulated speakers, and those are not significantly synchronized.

[Robbbert]

Not sure if I am permitted to talk here, but I investigated why xaudio2 crashes MAME when Shift F3 is pressed.

in emu/sound.cpp, there's a sub-function called find_node_info, which tries to find the node which matches the number passed in. If it fails, then nullptr is returned, and then the caller crashes. (line 2006)

I added printfs to find out what node number is passed, and what node numbers exist, both before and after the Shift F3.

• For dsound, only no.1 exists, both before and after the reset, so no problem.
• For portaudio, no.1,2,3,4 exist, both before and after - again no problem.
• For wasapi, first time the numbers are 1,2,3 but after the reset it's now 5,6,7. However the wanted number changes from 3 to 7, so although odd, it still would work.
• For xaudio2, first time numbers are 1,2,3 but after the reset it's now 4,5,6. The issue is that the wanted number is 3 both times, so it fails after the reset.

This shows that each sound choice (not sure what they should collectively be called) has its own way of deciding node numbers. Some consistency would probably be a good idea.

Hopefully this should help in tracking down the crash bug in xaudio2.

[cuavas]

The node numbers need to change every time it wants to force the sound manager to recreate streams (e.g. on getting a fatal engine error). It’s normal for them to increase.

[galibert]

Not after a shift-F3, no, since the sound engine is destroyed and recreated.

Number 3 wanted makes me think you have the wrong default sink node number in there somehow.

[cuavas]

The OSD module isn’t actually recreated though – it calls exit() then init() again. It’s just continuing the numbering.

[Robbbert]

Thanks for fixing -sound xaudio2.

[cuavas]

DirectSound is completely stupid. Since Vista, it’s always emulated on top of WASAPI (Vista no longer supports native DirectSound drivers). The emulation doesn’t give accurate play cursor positions, and subscribing to notifications when specific positions in the buffer are reached is completely broken. It seems to be far worse in Windows 10 than it was in Vista, too. Can we just ditch it at this point?

[cuavas]

Also, they’ve removed all the DirectSound code samples from the SDK, and every documentation page has this scary warning at the top now:

[The feature associated with this page, DirectSound, is a legacy feature. It has been superseded by XAudio2 and Audio Graphs. These newer frameworks have been optimized for Windows 10 and Windows 11. Microsoft strongly recommends that new code use XAudio2 and Audio Graphs instead of DirectSound, when possible. Microsoft suggests that existing code that uses the legacy APIs be rewritten to use the new APIs if possible.]

The really don’t seem to want people using it any more.

[rb6502]

MS told registered developers to stop using DirectSound even before Vista shipped. It's basically at the same status as OpenGL on macOS/iOS where it's emulated on top of the newer stuff and it'll likely continue working indefinitely, but it's unsupported.

Which is a verbose way of saying "yes, ditch it". XAudio2 should be more than fine as the safe default/fallback that DSound used to be.

[happppp]

MAME's minimum supported xaudio2 version is 2,8, so it won't work on Windows <= 7.
The new default is WASAPI, but apparently it doesn't work for everyone? eg. Haze, Robbbert (and I doubt these are the only 2 people on earth where MAME WASAPI fails ;) )

Is portaudio a safe default? It has latency and crackling issues with abuffer though (WASAPI as well). Ideally for the crackling issue that'd need yet another resampler instead of cutting off samples.

[galibert]

Portaudio is a pile of shit, if you use that as a default I'll start to wonder why I bother.

[Robbbert]

Bug with portaudio. If portaudio is used, with any choice, it's fine. But if Shift F3 is pressed, then the volume increases dramatically to the point of being overdriven and grossly distorted. Doesn't happen with all games, but it does happen with yosakdon and pacman. There's no problem with eightman though.

[galibert]

Feels like a portaudio bug when doing multiple cycles of terminate/initialize in one session...

[happppp]

It is already distorted in the buffer from stream_sink_update, so no it doesn't seem like a bug in the portaudio library. Perhaps a bug with the audio mixer. I have no idea why other sound backends aren't affected for me.
sample 0 = ok
sample 1 until last = higher volume.

eg. if you have a 1-bit dac, write 1 at reset, output value is constant 8191.
disable high pass filter first!

boot game -> samples = 8191
shift f3 -> samples = 16383
shift f3 -> samples = 24000 or something..
shift f3 -> samples = 32767
shift f3 -> overflow

FYI -wavwrite is ok

[happppp]

Here's my test:

fidelity/sc9.cpp where it writes to the dac, do write(1);
Set backend to portaudio, set portaudio device to whatever works, go to audio effects and disable filter (just so it won't filter out dc offset).

sound.cpp line 1087:

		// Send the result to the osd
		for(auto &stream : m_osd_output_streams)
			if(stream.m_samples)
			{
				for (int i=0;i<16;i++)
					printf("%d ",stream.m_buffer.data()[i*2]);
				printf("\n");

				machine().osd().sound_stream_sink_update(stream.m_id, stream.m_buffer.data(), stream.m_samples);
			}

result after each shift+f3 (including 1st boot without having hard reset):

8191 8191 8192 8191 8191 8191 8191 8191 8191 8191 8192 8192 8192 8192 8191 8192
8192 16383 16384 16383 16383 16383 16383 16383 16383 16383 16384 16384 16384 16384 16383 16384
8192 16383 24575 24575 24575 24575 24575 24575 24575 24575 24576 24576 24576 24576 24576 24576
8191 16383 24576 32767 32767 32767 32767 32767 32767 32767 -32768 -32768 -32768 -32768 32767 -32768
8192 16383 24576 32767 -24577 -24577 -24577 -24577 -24577 -24577 -24576 -24576 -24576 -24576 -24577 -24576
8192 16383 24576 32767 -24577 -16385 -16385 -16385 -16385 -16385 -16384 -16384 -16384 -16384 -16385 -16384
8191 16383 24576 32767 -24577 -16385 -8193 -8193 -8193 -8193 -8192 -8192 -8192 -8192 -8193 -8192
8191 16383 24576 32767 -24577 -16385 -8193 -1 8190 8190 8192 8191 8191 8191 8190 8191
8192 16383 24576 32767 -24577 -16385 -8193 -1 8191 16382 16384 16383 16383 16383 16382 16383
8192 16383 24576 32767 -24577 -16385 -8193 -1 8191 16382 24576 24575 24575 24575 24574 24575
8192 16383 24576 32767 -24577 -16385 -8193 -1 8191 16382 24576 32767 32767 32767 32766 32767
8192 16383 24576 32767 -24577 -16385 -8193 -1 8191 16382 24576 32767 -24577 -24577 -24578 -24577
8192 16383 24576 32767 -24577 -16385 -8193 -1 8191 16382 24576 32767 -24577 -16385 -16386 -16385
8192 16383 24576 32767 -24577 -16385 -8193 -1 8191 16382 24576 32766 -24578 -16385 -8194 -8193
8192 16383 24576 32767 -24577 -16385 -8193 -1 8191 16382 24576 32766 -24578 -16385 -8194 -1

[galibert]

Fixed now. It was extending m_port_positions past the number of channels, and that messed up sound_manager::find_channel_mapping.

[Robbbert]

Thanks for fixing -sound portaudio.

[rb6502]

The change to the meaning of audio_latency causes a terrible user experience that we're going to spend the rest of the year explaining to users. If the value is integer, it should compute what that means in the new units and use that. And then print a friendlier warning that tells what it was changed to and suggest running with -cc to make the new units permanent.

[happppp]

Yes abuffer has sync issues.

Sound updates were 20ms after Aaron's sound.cpp overhaul a few years ago.
Before that? probably what you said.

[cuavas]

Sound "frames" have been fixed 20ms for over a decade. It was Aaron who did it, but it was long before he changed to floating-point samples. It might have been when -nosound was removed because not emulating sound chips broke so many things. IIRC it wasn't documented, but you learned pretty quickly when you wrote a sound module.

[happppp]

So, what do you think audio_latency should be? Something better than a fixed time duration value that doesn't break existing mame.ini config? The previous setting wasn't good, especially with dsound/xaudio with its 100ms steps (and no in-between values allowed..)

If it's similar to before, something like:

• coreaudio: 25ms steps (as before)
• xaudio2: 100ms steps (as before)
• wasapi: 20ms steps
• portaudio: 20ms steps (as before)

(+ don't enforce integers, but allow in-between values as well)
How is a per-api modifier like that a good uX?

I don't think RB's suggestion with integer latency in number of video frames is doable. It'd also be troublesome if an emulated game changes refresh rate on the fly.

[cuavas]

I still think the old approach with arbitrary integers ranging from “aggressively short” to “comfortably long” where that was supposed to be calibrated to what each sound module could tolerate in a typical host system confguration.

DirectSound was just plain bad. DirectSound driver quality was always very inconsistent, it never tolerated low latency well, and in its original form it was supposed to handle a ’90s “multimedia PC” with poor timer resolution, poor primary interrupt latency, severely limited DMA bandwidth and limited processing power. The range of latency settings it supported is a more of a reflection on DirectSound itself than anything else.

The buffer submission code in the currently released version of the XAudio2 module is overly convoluted and doesn’t really make much sense. It also isn’t really relevant.

With the current situation, the latency value means different things to different sound modules:

• For CoreAudio, it more or less controls how much audio it will buffer after an underrun before it starts feeding it to the host sound engine. Larger values make it more tolerant of jitter in the audio frame rate. (Because audio frames aren’t the same length as video frames and MAME only synchronises with the wall clock on video updates, if the emulated system can run much faster than 100% speed, you’ll basically get one or two video frame intervals between audio frame updates. Other factors can also cause jitter.)
• WASAPI is using the abuffer class (from @galibert) and basically feeding the host sound engine as quickly as it can. The audio latency setting controls the maximum amount of sound data it will keep in the host sound engine buffer.
• XAudio2 also basically feeds the sound engine as quickly as it can (although in this case it’s one in-process XAudio2 engine per output endpoint which mixes the streams before feeding them to WASAPI). It tries to keep about 24 ms of audio queued in the XAudio2 engine. The audio latency setting controls how much audio it will buffer itself before it treats it as an overrun and starts dropping blocks.

As I already said, I need to revisit the buffer management code for WASAPI and XAudio2. WASAPI in particular doesn’t deal with frame interval jitter very well at the moment. I want to make XAudio2 give sample-accurate synchronisation where possible.

But anyway, increasing the precision of the audio latency setting doesn’t really gain you much. The audio frame rate is always 50 Hz (20 ms interval), so increasing the precision past that doesn’t help much.

[happppp]

Alright I'll change it again, to audio frames granularity, so it should be pretty close to what it before. Just with the freedom of setting in-between values.
Before you removed dsound, which was the default, this was not possible. Since the old default latency value of 2 (40ms) was too short.

So:
xaudio: old steps = 100ms (way too coarse), new = 20ms
portaudio: 20ms, same as before
wasapi: i picked 20ms
coreaudio: did not modify, leave it up to RB. If he wants to force integers 1-5 as before and give it a different meaning he can do std::clamp(int(options.audio_latency()), 1, 5)

[rb6502]

Somewhere in the last week MAME started ignoring the node names I pass back in get_information(), so my choices in the mixer are now [default], , , and , which is no fun. Yes I've verified the names are still being passed back correctly. Portaudio and SDL work fine, so something changed and it's not documented.

If m_generation is ever anything other than 1 MAME locks up when you enter the mixer and try to change anything.

The resampling to run devices at their nominal rate works great. I ran mu50 and played an entire song on my phone next to a microphone and it all came through fine.

[cuavas]

You need to set m_display_name now. You use m_name for the stable configuration name (not necessarily human-readable). WASAPI and XAudio2 use the endpoint instance ID for m_name and the friendly name property for m_display_name.

[cuavas]

I just tested doing something that causes the generation to get bumped and streams to be destroyed. MAME recreates the streams like it’s supposed to, and the mixer menu still works.

I found I can get MAME to lock up with with the following conditions:

• WASAPI sound module selected
• Route to device other than “[default]”
• Mixer menu open
• Do something that bumps the generation and destroys the streams

However given it doesn’t happen with XAudio2, it’s quite possibly an issue with the WASAPI module itself.

[galibert]

I had pipewire drop all streams every second, and drop all streams + renumber all nodes every second, and you couldn't even hear it. So I think it's reasonably solid at this point.

[cuavas]

The comments in SDL2/SDL_audio.h suggest capture is supported starting in 2.0.5, contradicting the comment in sound/sdl_sound.cpp. I know the docs for SDL are pretty dreadful, but it may be possible to get input working with SDL.

[galibert]

Note that audio capture support is not implemented as of SDL 2.0.4, so the iscapture parameter is for future expansion and should always be zero for now.

From the SDL_GetNumAudioDevices documentation. Dreadful it is.

[cuavas]

Yes, but look at the documentation for SDL_OpenAudioDevice: https://github.com/libsdl-org/SDL/blob/release-2.24.x/include/SDL_audio.h#L558

 * Please note that SDL 2.0 before 2.0.5 did not support recording; as such,
 * this function would fail if `iscapture` was not zero. Starting with SDL
 * 2.0.5, recording is implemented and this value can be non-zero.

While it's true that capture was not implemented in 2.0.4, it was implemented in 2.0.5 and the documentation for SDL_GetNumAudioDevices was never updated.

[galibert]

Oh agreed. Dreadful, like you said.

[rb6502]

One of the new features listed for SDL 3 is "Extremely good documentation". We will see about that :-)

[galibert]

UI question: MG would really like to be able to record the sound post-effects. It's kinda complicated but heh, why not. But where should the option be reachable?

[cuavas]

I found another crash apparently caused by something in the new sound system changes.

Run mame vgmplay and then use the File Manager to load a Neo Geo VGM. It crashes somewhere inside the sound stream update:

#0  0x00007ffea4634733 in msvcrt!memset () from C:\WINDOWS\System32\msvcrt.dll
#1  0x00007ff7e432c880 in emu::detail::output_buffer_flat<float>::prepare_space(unsigned int) ()
#2  0x00007ff7e431ab16 in sound_stream::do_update() ()
#3  0x00007ff7e431adce in sound_stream::update() [clone .part.0] ()
#4  0x00007ff7e3cfd068 in device_sound_interface::set_output_gain(int, float) ()
#5  0x00007ff7e37a9e3c in vgmplay_state::load_file[abi:cxx11](snapshot_image_device&)::{lambda(device_t&, int, vgm_chip, unsigned int, unsigned int)#1}::operator()(device_t&, int, vgm_chip, unsigned int, unsigned int) const ()
#6  0x00007ff7e37c5990 in vgmplay_state::load_file[abi:cxx11](snapshot_image_device&) ()
#7  0x00007ff7e3e26147 in snapshot_image_device::process_snapshot_or_quickload(int) ()
#8  0x00007ff7e3c81914 in device_scheduler::timeslice() ()
#9  0x00007ff7e3c7dce6 in running_machine::run(bool) ()
#10 0x00007ff7e755ceab in mame_machine_manager::execute() ()
#11 0x00007ff7eb698a39 in cli_frontend::start_execution(mame_machine_manager*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) ()
#12 0x00007ff7eb698fed in cli_frontend::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ()
#13 0x00007ff7e7559049 in emulator_info::start_frontend(emu_options&, osd_interface&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ()
#14 0x00007ff7ed5a7a6c in main ()

It doesn’t crash like this if you start it with the VGM, only if you start it with no VGM then try to load one using the File Manager menu.

[cuavas]

valgrind output up to the point where heap corruption causes it to blow up completely:
grind.log.gz

[ajrhacker]

I recompiled with SYMBOLS=1 and SANITIZE=address, and got the following crash report when trying to load a vgmplay softlist item from the UI:

=================================================================
==917808==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x711c36dcd600 at pc 0x5d764ffe867c bp 0x7ffce86b7c10 sp 0x7ffce86b73e0
WRITE of size 3337004 at 0x711c36dcd600 thread T0
    #0 0x5d764ffe867b in __asan_memset (/home/ajrhacker/Documents/mame/mamed+0x128b867b) (BuildId: 9e907492533ee83281e9e75dc6ed5ba44e6814d8)
    #1 0x5d766e82d981 in __fill_a1<float *, double> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_algobase.h:922:11
    #2 0x5d766e82d981 in __fill_a1<float *, std::vector<float, std::allocator<float> >, double> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_algobase.h:951:7
    #3 0x5d766e82d981 in __fill_a<__gnu_cxx::__normal_iterator<float *, std::vector<float, std::allocator<float> > >, double> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_algobase.h:968:7
    #4 0x5d766e82d981 in fill<__gnu_cxx::__normal_iterator<float *, std::vector<float, std::allocator<float> > >, double> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_algobase.h:998:7
    #5 0x5d766e82d981 in prepare_space /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/sound.cpp:173:3
    #6 0x5d766e82d981 in sound_stream::do_update() /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/sound.cpp:624:18
    #7 0x5d766e82b20e in sound_stream::update() /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/sound.cpp:536:3
    #8 0x5d766a8d3bc8 in set_output_gain /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/sound.h:238:54
    #9 0x5d766a8d3bc8 in device_sound_interface::set_output_gain(int, float) /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/disound.cpp:228:13
    #10 0x5d7659ea8ff3 in operator() /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/mame/virtual/vgmplay.cpp
    #11 0x5d7659ea8ff3 in vgmplay_state::load_file[abi:cxx11](snapshot_image_device&) /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/mame/virtual/vgmplay.cpp:2925:6
    #12 0x5d765f51b526 in operator() /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/lib/util/delegate.h:765:11
    #13 0x5d765f51b526 in snapshot_image_device::process_snapshot_or_quickload(int) /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/devices/imagedev/snapquik.cpp:57:24
    #14 0x5d766e7c4420 in operator() /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/lib/util/delegate.h:765:11
    #15 0x5d766e7c4420 in device_scheduler::execute_timers() /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/schedule.cpp:959:5
    #16 0x5d766e7bdce4 in device_scheduler::timeslice() /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/schedule.cpp:505:2
    #17 0x5d766e6302eb in running_machine::run(bool) /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/machine.cpp:347:17
    #18 0x5d767193cfa1 in mame_machine_manager::execute() /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/frontend/mame/mame.cpp:288:19
    #19 0x5d7671b5b84d in cli_frontend::start_execution(mame_machine_manager*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/frontend/mame/clifront.cpp:277:22
    #20 0x5d7671b5febd in cli_frontend::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/frontend/mame/clifront.cpp:293:3
    #21 0x5d7671940f6f in emulator_info::start_frontend(emu_options&, osd_interface&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/frontend/mame/mame.cpp:453:18
    #22 0x5d766ea91c53 in main /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/osd/sdl/sdlmain.cpp:100:9
    #23 0x711c6bc29d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #24 0x711c6bc29e3f in __libc_start_main csu/../csu/libc-start.c:392:3
    #25 0x5d764ff66204 in _start (/home/ajrhacker/Documents/mame/mamed+0x12836204) (BuildId: 9e907492533ee83281e9e75dc6ed5ba44e6814d8)

0x711c36dcd600 is located 0 bytes to the right of 192000-byte region [0x711c36d9e800,0x711c36dcd600)
allocated by thread T0 here:
    #0 0x5d7650023e1d in operator new(unsigned long) (/home/ajrhacker/Documents/mame/mamed+0x128f3e1d) (BuildId: 9e907492533ee83281e9e75dc6ed5ba44e6814d8)
    #1 0x5d766e87d2db in allocate /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/new_allocator.h:137:27
    #2 0x5d766e87d2db in allocate /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/alloc_traits.h:464:20
    #3 0x5d766e87d2db in _M_allocate /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_vector.h:378:20
    #4 0x5d766e87d2db in std::vector<float, std::allocator<float> >::_M_fill_insert(__gnu_cxx::__normal_iterator<float*, std::vector<float, std::allocator<float> > >, unsigned long, float const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/vector.tcc:581:34
    #5 0x5d766e82c45d in resize /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_vector.h:1032:4
    #6 0x5d766e82c45d in set_buffer_size /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/sound.cpp:150:5
    #7 0x5d766e82c45d in sound_stream::init() /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/sound.cpp:506:18
    #8 0x5d766e838ec2 in sound_manager::after_devices_init() /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/sound.cpp:779:11
    #9 0x5d766e62c61f in running_machine::start() /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/machine.cpp:217:11
    #10 0x5d766e62f8bd in running_machine::run(bool) /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/emu/machine.cpp:301:3
    #11 0x5d767193cfa1 in mame_machine_manager::execute() /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/frontend/mame/mame.cpp:288:19
    #12 0x5d7671b5b84d in cli_frontend::start_execution(mame_machine_manager*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/frontend/mame/clifront.cpp:277:22
    #13 0x5d7671b5febd in cli_frontend::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/frontend/mame/clifront.cpp:293:3
    #14 0x5d7671940f6f in emulator_info::start_frontend(emu_options&, osd_interface&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/frontend/mame/mame.cpp:453:18
    #15 0x5d766ea91c53 in main /home/ajrhacker/Documents/mame/build/projects/sdl/mame/gmake-linux-clang/../../../../../src/osd/sdl/sdlmain.cpp:100:9
    #16 0x711c6bc29d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16

SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/ajrhacker/Documents/mame/mamed+0x128b867b) (BuildId: 9e907492533ee83281e9e75dc6ed5ba44e6814d8) in __asan_memset
Shadow bytes around the buggy address:
  0x0e2406db1a70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0e2406db1a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0e2406db1a90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0e2406db1aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0e2406db1ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0e2406db1ac0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0e2406db1ad0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0e2406db1ae0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0e2406db1af0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0e2406db1b00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0e2406db1b10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==917808==ABORTING

[ajrhacker]

On further examination, the problem seems to be that sound_stream::get_current_sample_index can return an extremely large number, causing sound_stream::update to request more (in fact, far more) samples than can possibly fit in the output buffer.

I'm reminded of @galibert's careless design of debug_disasm_buffer::debug_data_buffer that could cause it to unnecessarily buffer gigabytes of program memory in the worst case.

[galibert]

It's fixed.

[cuavas]

@ajrhacker since you apparently used the file manager in a Linux ASAN build, is MT09137 fixed? When you browsed for a file, did you get these kinds of errors:

==26128==ERROR: AddressSanitizer: new-delete-type-mismatch on 0x506001268180 in thread T0:
  object passed to delete has wrong type:
  size of the allocated type:   55 bytes;
  size of the deallocated type: 32 bytes.

(The “size of allocated type” would vary depending on the length of the name of whatever it was stating.)

If you didn’t see any of those errors, I can close it.

[cuavas]

@galibert is it worth keeping the code to support split_streams_per_source() returning false? None of the included sound modules do that now. Since the core now does sample rate conversion, a hypothetical ASIO, JACK or WASAPI exclusive mode sound module could do in-process mixing if someone were to implement one. XAudio2 already does in-process mixing. Can we save some complexity in the core if we get rid of that option?

[galibert]

Portaudio is lowest-common-denominator, so it aligns with alsa, which is rather bad (no mixing, no resampling). As for one stream per mixing line, it allows for pavucontrol/pwvucontrol to directly act on the volume of each individual line and mame to record it. It's rather nice. I'm surprised windows/osx don't have an equivalent.

[cuavas]

Windows does – that’s WASAPI shared mode (with software mixdown, or hardware mixdown on request if the driver and card support it). The point of WASAPI exclusive mode (and ASIO) is that you get DMA’d directly into (or out of) the hardware sound buffer. Having anything else in the path would defeat the purpose. I’m currently just using WASAPI shared mode with software mixdown provided by the OS. That’s why the WASAPI exclusive mode and ASIO sound modules are hypothetical at the moment.

[galibert]

And you have a similar external interface to manipulate mappings and volumes?

[cuavas]

You can, but it depends on the application providing logical groupings with GUIDs. The Windows mixer lets you manipulate the volume/default output device per (PID,GUID). I’m throwing the same GUID on everything at the moment, so the Windows mixer only shows a single volume control for all the audio streams.

[galibert]

Ok, that's why I pass a name when opening a stream, to make it easy for the user for the external interfaces. You may be able to GUID with the stream number in or something?

[rb6502]

The default compressor is causing some really odd transient audio breakups. One pretty simple reproduce (wear headphones):

• Run mame daytona
• When the game boots, hit F2 to go into the service menu.
• Use X and B to highlight Sound Test and press 1 (Start)
• Use X and B to highlight BGM1 and press 1 (Start)
• Use X and B to highlight "Sky High" and press 1 (Start) to play the song
• You will notice a series of weird single-channel cut-outs where it sounds like one channel is masking out the other or something
• Hit Tab and go to the Effects. Change the Compressor to Bypass and the problems will go away

The issues don't appear in -wavwrite with the effects on, which is what led me to find it was the compressor's fault.

This also happens in 'mame apple2gs nucleus' and 'mame macqd700' when playing an audio CD, so it's not linked to any specific driver or sound chip.

[galibert]

I'll try to see if the implementation is buggy or if the original has those issues (in which case I'll test the freeverb3 ones to see how they sound and go from there)

[happppp]

Also: psu (Playstation) bootup sound, and orunners.

[galibert]

Still true for orunners now that I separated the channels?

[happppp]

I'm at top-of-tree, if your local source changes already fixed orunners then nevermind.

[galibert]

Looks like I lost the change or something, I'll redo it.

[m1macrophage]

Reporting a possible issue in the sound manager

Under certain uncommon conditions, there can be an infinite loop in sound_manager:after_devices_init(). Specifically: http://github.com/mamedev/mame/blob/05b833f65fd156945ff42f83df1f2384b49a3f7a/src/emu/sound.cpp#L770-L777

This seems to happen when one or more streams do not have an output, though only under certain routing configurations.

Can reproduce by patching in: m1macrophage/mamefork@5462d6d

[m1macrophage]

Some more investigation, in case it helps.

For streams without an output, it is possible for frequency_is_solved() to return false even after try_solving_frequency() returns true. This can cause need_to_solve to become negative, since the condition in 773 will evaluate to true multiple times for a single stream.