MiSTer FPGA Forum

I've noticed that many arcade cores will emit an obnoxious beep tone when they are launched, well before any ROM has bootstrapped or the resolution mode information appears on the screen. One example is Victory.

It also emits this sound even when the MiSTer audio is muted. On my system with amplified speakers connected it really is annoying.

Is this just the way the original hardware worked, or is there something that could be done to remove these?

It does seem odd that the BEEP doesn't even respect he volume or mute settings on the MiSTer.

I don't know about other cores, but that behavior is entirely consistent with a 486 PC. The beep came from the PC speaker, not the audio card. It was always piercingly loud. I recall my BIOS had an option to disable it though.

There is a lag between when a core is loaded and when the initial volume command is sent to the core.
So if a core emits sound in the very initial period, it cannot be attenuated or muted by volume setting.
I think that's why the beep sound doesn't respect volume setting.

I don't know whether the initial beep in arcade cores also occurs in real hardware, or whether it is recreated as intended.
In any case, it would be better to be fixed, imho.

Btw, at least in my environment, the initial beep on Galaxian core occurs through SPDIF output but it ​doesn't occur through HDMI audio output.
I think this is due to a delay until HDMI signal is synced to my monitor.
Maybe those who are outputting sound via HDMI have not noticed the beep.

That would make sense. I am also using SPDIF output on the analog IO board.
Hopefully this can be looked at, and is a framework fix instead of a per core one.

Lots of arcade hardware, especially the older ones with discrete sound circuits will make some form of noise on power up until the CPU gets around to setting all of the relevant ports to turn it off.

Some sort of either a delay or fade-in on core load would be nice. I think modern car stereos do this when you turn on a car, so you do not blast your eardrums out.

ash2fpga wrote: ↑Thu May 13, 2021 9:22 pm Some sort of either a delay or fade-in on core load would be nice. I think modern car stereos do this when you turn on a car, so you do not blast your eardrums out.

Yes that would work, or just disconnect the audio from the core until it has finished booting and then re-connect (about the time that the resolution displays on the screen.

So, if one wanted to open a related ticket on github, which project would this fall under?

retrodroid wrote: ↑Sat May 15, 2021 2:39 pm So, if one wanted to open a related ticket on github, which project would this fall under?

Probably just the main MiSTer project? https://github.com/MiSTer-devel/Main_MiSTer/issues

That would likely be rejected under Main_MiSTer.
It should be filed under the individual core(s) which exhibit this behaviour. Without specifics, it won't be examined.

But to be clear, you would be asking for a feature (not a bugfix) - and that may easily be rejected.

dshadoff wrote: ↑Sun May 16, 2021 12:50 pm That would likely be rejected under Main_MiSTer.
It should be filed under the individual core(s) which exhibit this behaviour. Without specifics, it won't be examined.

But to be clear, you would be asking for a feature (not a bugfix) - and that may easily be rejected.

True. Filing it under the individual cores is a better idea.

Its the behavior some of the original hardware had
You want accuracy, you get beeps at start up.

darksakul wrote: ↑Sun May 16, 2021 3:05 pm Its the behavior some of the original hardware had
You want accuracy, you get beeps at start up.

Sure, but they shouldn't exist outside of the MiSTer volume and mute controls. So I'd consider this issue a "bug" for that reason, at least.

OK, that does sound unexpected. But we still don't know which cores are affected (and thus, have nothing specific to verify/act upon).

I'll try to compile a reasonable starting list in the next week or so.

Okay, here is a nice starting list of cores that exhibit this full volume loud beep "feature":

* a.galaxn (Mr. Do’s Nightmare)
* azurian
* blkhole
* canyon (engine sound)
* Clean Sweep
* devilfsg
* kingball
* luctoday
* mars
* omegab
* phoenix (siren!)
* pleiads (siren!)
* ultratnk
* uniwars
* victory
* warofbug

In my test I have the MiSTer volume muted, and outputting sound out via the optical output on the analog IO board. These startup sounds come through at full volume.

If someone could verify if this issue exists when outputting via HDMI as well, that would be a useful datapoint.

I'm pretty sure this is just a MiSTer framework bug, it should be initializing the MiSTer audio settings before the core, so the mute is respected. Note that once the core has booted the volume is correctly muted.

The problem is changing the audio settings require the core to be loaded. The audio outputs are connected directly to the FPGA side, not the linux side. So there's no real way to initialize audio before the core 'starts'. The FPGA is programmed, immediately starts executing once it initializes and enters 'user mode', THEN the linux side/main Mister can set the volume.

The choice is either have potentially loud noises emitted at core boot, or to change SYS so the default is 'fully attenuated/mute'. The problem is that's not 'accurate' and there's no way to make it a config option.

I guess you could do some complicated solution where cores load into some sort of 'paused' state so they can be configured and then told to 'run'. That feels like it would be a lot of work and may be core-by-core specific.

edit: dumb thought, but someone more familiar with the FPGA side would have to answer if this is feasible: Could you write the volume setting/value to some known/defined place in DDR memory, load the core and then have the core initialize volume from that memory location? Would that be easy(ier) to do or is that still not going to get read in time?

Use volume control on your speakers?

Sounds like the correct repo to report this on is the Template_MiSTer one then.
https://github.com/MiSTer-devel/Template_MiSTer

Maybe the correct thing to do is to start at zero volume and keep it like that until receiving a volume setting.

Okay, I've logged a new issue for this bug: https://github.com/MiSTer-devel/Templat ... /issues/33

https://github.com/MiSTer-devel/Templat ... 5db7501589

Looks like it's done on the template side. The cores just have to have their sys updated next.

The Pleiads core is already updated. No more sirens

Do I need to find the GitHub projects for each of these cores now and open issues to have them updated, or will the authors/maintainers pick up this fix "automagically" somehow?

Alanswx, me and possibly others will work through the cores and update them - probably just those listed in the issue first.

No need to raise individual issues I dont think, frankly it won't speed up the process any

Also I'm on holiday