DracoNihil wrote on 2024-05-19, 06:37:

Falcosoft wrote on 2024-05-19, 05:32:

It seems to be case 3. The introduction of oversampling was final sample mixing related: https://github.com/nukeykt/Nuked-SC55/c […]
Show full quote

Rincewind42 wrote on 2024-05-19, 00:17:

... 1. the hardware does 2x oversampling, so emulating this accurately is a must. 2. it's a Nuked-SC55 special, and the digital […]
Show full quote

...
1. the hardware does 2x oversampling, so emulating this accurately is a must.
2. it's a Nuked-SC55 special, and the digital circuit simulation is doing twice the work unnecessarily.
3. it's a Nuked-SC55 special, the digital circuit simulation runs at the correct 32k rate, then there's some extra interpolation/upsampling going on as a post-processing step.
...

It seems to be case 3. The introduction of oversampling was final sample mixing related:
https://github.com/nukeykt/Nuked-SC55/commit/ … 00df21c6036039f

It's very easy to disable oversampling by modifying 2 places in code. And it has almost zero impact on performance. You can test it:
1. in pcm.cpp disabe this code fragment:

Copy code to clipboard

1 if (pcm.config_reg_3c & 0x40) // oversampling
2        {
3            pcm.ram2[30][10] = shifter;
4
5            pcm.ram1[30][0] = pcm.accum_l & write_mask;
6            pcm.ram1[30][1] = pcm.accum_r & write_mask;
7
8
9            tt[0] = (int)((pcm.ram1[30][3] & ~write_mask) << 12);
10            tt[1] = (int)((pcm.ram1[30][5] & ~write_mask) << 12);
11
12            MCU_PostSample(tt);
13        }

2. In mcu.cpp change the line from

Copy code to clipboard

1 spec.freq = (mcu_mk1 || mcu_jv880) ? 64000 : 66207;

to

Copy code to clipboard

1 spec.freq = (mcu_mk1 || mcu_jv880) ? 32000 : 33103;

How exactly do you mean by disable that code fragment? When I try to remove that all it does is produce a emulator that immediately deadlocks to 100% CPU usage and doesn't respond to any signal other than SIGKILL.

I meant commenting out. Sorry, I have not tried it on latest master (I have tested it on a fork of mine that diverged from latest master earlier). On latest master you have to disable (I mean commenting out) also the following part in mcu.cpp (lines 1008-1010) in order no-oversampling code path to work.

1 
2      //  if (pcm.config_reg_3c & 0x40)
3      //      sample_write_ptr &= ~3;
4      //  else
5        
6        sample_write_ptr &= ~1;
7        if (sample_read_ptr == sample_write_ptr)
8        {
9            MCU_WorkThread_Unlock();
10            while (sample_read_ptr == sample_write_ptr)
11            {
12                SDL_Delay(1);
13            }
14            MCU_WorkThread_Lock();
15        }

Falcosoft wrote on 2024-05-19, 07:08:

I meant commenting out. Sorry, I have not tried it on latest master (I have tested it on a fork of mine that diverged from lates […]
Show full quote

I meant commenting out. Sorry, I have not tried it on latest master (I have tested it on a fork of mine that diverged from latest master earlier). On latest master you have to disable (I mean commenting out) also the following part in mcu.cpp (lines 1008-1010) in order no-oversampling code path to work.

Copy code to clipboard

1 
2      //  if (pcm.config_reg_3c & 0x40)
3      //      sample_write_ptr &= ~3;
4      //  else
5        
6        sample_write_ptr &= ~1;
7        if (sample_read_ptr == sample_write_ptr)
8        {
9            MCU_WorkThread_Unlock();
10            while (sample_read_ptr == sample_write_ptr)
11            {
12                SDL_Delay(1);
13            }
14            MCU_WorkThread_Lock();
15        }

Thank you for the clarification, I got it running without the oversampling stage. PipeWire's default resampler doesn't (to my ears atleast) seem to cause the audio quality to suffer either way but the lack of the oversampling stage has made getting a proper buffer way easier.

I noticed that some of the System Shock midi tracks have issues with Nuked SC-55: SC-55mk2. For example with the THM4.XMI track (Level 5 - Flight Deck), the emulator plays "Standard" drum instead of "Power"and Nuked SC-55 returns the error "No DRUM SET" in both GM and GS modes.
Using Falcosoft MIDI Player with the "Use Patch Info fo Capital Tone Fallback" option, the track plays correctly.

Kappa971 wrote on 2024-05-20, 00:41:

I noticed that some of the System Shock midi tracks have issues with Nuked SC-55: SC-55mk2. For example with the THM4.XMI track (Level 5 - Flight Deck), the emulator plays "Standard" drum instead of "Power"and Nuked SC-55 returns the error "No DRUM SET" in both GM and GS modes.
Using Falcosoft MIDI Player with the "Use Patch Info fo Capital Tone Fallback" option, the track plays correctly.

With my layman knowledge I will try to answer this. Presuming you are using ROMs for sc-55 mkII
Capital tone fallback was not a feature of the MkII.

Somthing somthing copyright, somthing Yamaha.

It's not a bug, it's a removed feature

Not tested, but, using rom for mk1 should "solve" the issue.

Lots of info here about CTF for those interested. I mined a significant chunk of it from Vogons when putting together that ticket:

https://github.com/dosbox-staging/dosbox-staging/issues/2390

MK1 v1.21 or go home 😎

Last time there wasn't a complete set of SC-55 roms anywhere on earth, now you tell me that if I search, I'll find them? I ask to avoid wasting time looking for something that doesn't exist 😅.
With the mk2 roms, I can use Falcosoft MIDI Player as a "filter" to pass the correct instruments to the Nuked SC-55, but obviously it's not ideal because it needs two LoopMIDI ports and Falcosoft MIDI Player when playing.

One last question, how many DOS games saturate the polyphony of the original SC-55?

Kappa971 wrote on 2024-05-20, 08:24:

One last question, how many DOS games saturate the polyphony of the original SC-55?

Sandwarriors definitely does. And this is with me spacing out the "Voice Reservation" values to be "evenly distributed" amongst the 16 parts for the 28 possible voices.

Thanks @Karmek and @AppleSauce.
With mk1 roms v1.21, all instrument assignment issues are gone.

DracoNihil wrote on 2024-05-20, 08:41:

Sandwarriors definitely does. And this is with me spacing out the "Voice Reservation" values to be "evenly distributed" amongst the 16 parts for the 28 possible voices.

This game looks like it came out in 1997, so it makes sense. When (or if) this https://github.com/nukeykt/Nuked-SC55/pull/68 is merged into the main branch, I will be able to launch multiple instances of Nuked-SC55 mk1 without the need for additional software.

Rincewind42 wrote on 2024-05-20, 07:20:

Lots of info here about CTF for those interested. I mined a significant chunk of it from Vogons when putting together that ticket:

https://github.com/dosbox-staging/dosbox-staging/issues/2390

MK1 v1.21 or go home 😎

Yeah pretty much

I guess part of the problem is people want perfection , originally the sound canvas was a mishmash of rom versions and models each with their own flaws. I was already aware of the capital tone fallback issue which is why I made sure I bought a 1.21 model by checking the serial number on the listing and cross referencing it to a vogons post which listed what series of serialized models had what roms.

I bought a mk2 as well but I've just stuck to using the mk1 because most games probably work better with that.

Either way certain developers probably didn't 100% ensure everything was exactly problem free so that's how it was , although I haven't noticed a huge amount of issues while using my Sound Modules since I enjoy them as is , maybe if I paid more attention I would?

At the end of the day depends on how nitpicky people are.

If people were that annoyed by it I'm sure someone could make a fork with a hybrid mythical SC55+SC55mk2 with extended polyphony.

Kappa971 wrote on 2024-05-20, 10:48:

This game looks like it came out in 1997, so it makes sense.

Well, not only was it a late MS-DOS game the MIDI music is incredibly sparse (only three songs with huge gaps in filenames: MUS3.mid MUS4.mid MUS6.mid and most of the expected soundtrack is CD audio, but I don't stream the game with CD audio because I'm used to the two ingame MIDI tracks.

Kappa971 wrote on 2024-05-20, 10:48:

...
When (or if) this https://github.com/nukeykt/Nuked-SC55/pull/68 is merged into the main branch, I will be able to launch multiple instances of Nuked-SC55 mk1 without the need for additional software.

You can already try the multi-instance feature (binaries are attached at the end of the post):
Re: [RELEASE] Nuked-SC55, low-level Roland SC-55 series emulator announcement

However, with the SC-55 mk1 roms, some songs (maybe two) of Duke Nukem 3D don't sound right and the emulator returns the error "MIDI Buff. Full!". Try with the attached midi.
No problems with the SC-55 mk2.

Wouldn't it be possible to implement some sort of Falcosoft MIDI Player style "CTF filter" within the emulator to make Sound Canvas models without CTF support still work correctly? Some kind of workaround without the need for additional software.

at this point, for troubleshooting, used rom, rom version and which binaries were used, is needed.

Which is unfortunate but an inherent problem from all the difrent releases that exist. Even the same for real hardware.

Karmeck wrote on 2024-05-20, 12:30:

at this point, for troubleshooting, used rom, rom version and which binaries were used, is needed.

Which is unfortunate but an inherent problem from all the difrent releases that exist. Even the same for real hardware.

Nuked-SC55 from master branch, SC-55 mk1 v1.21 rom.
The problematic tracks are:
08 - Episode 1 - Ah, Geez! [Lee Jackson].mid (E1L7)
16 - Episode 2 - Plasma [Lee Jackson].mid (E2L8)

But things don't seem that simple:
- playing these two tracks with Windows Media Player or Falcosoft MIDI Player, the emulator returns the error "MIDI Buff. Full!" (although the track sounds different between WMP and FMP, even stranger);
- if I use the Rednukem source port, all tracks seem to cause the error "MIDI Buff. Full!" (silence);
- if I use DOSBox Staging with Duke Nukem 3D v1.5, the track "16 - Episode 2 - Plasma [Lee Jackson].mid" plays correctly. I can't load the E1L7 level via the cheat DNSCOTTY107 (the other levels load while this one doesn't, how lucky!), but I suspect this track would also play correctly under DOSBox.

Nuked SC-55 with mk2 roms, no problems (except CTF fixable via FMP), so if this is the hardware behavior of the mk1, I think I'll stick with the mk2.

Kappa971 wrote on 2024-05-20, 13:09:

Nuked-SC55 from master branch, SC-55 mk1 v1.21 rom. The problematic tracks are: 08 - Episode 1 - Ah, Geez! [Lee Jackson].mid (E1 […]
Show full quote

Karmeck wrote on 2024-05-20, 12:30:

at this point, for troubleshooting, used rom, rom version and which binaries were used, is needed.

Which is unfortunate but an inherent problem from all the difrent releases that exist. Even the same for real hardware.

Nuked-SC55 from master branch, SC-55 mk1 v1.21 rom.
The problematic tracks are:
08 - Episode 1 - Ah, Geez! [Lee Jackson].mid (E1L7)
16 - Episode 2 - Plasma [Lee Jackson].mid (E2L8)

But things don't seem that simple:
- playing these two tracks with Windows Media Player or Falcosoft MIDI Player, the emulator returns the error "MIDI Buff. Full!" (although the track sounds different between WMP and FMP, even stranger);
- if I use the Rednukem source port, all tracks seem to cause the error "MIDI Buff. Full!" (silence);
- if I use DOSBox Staging with Duke Nukem 3D v1.5, the track "16 - Episode 2 - Plasma [Lee Jackson].mid" plays correctly. I can't load the E1L7 level via the cheat DNSCOTTY107 (the other levels load while this one doesn't, how lucky!), but I suspect this track would also play correctly under DOSBox.

Nuked SC-55 with mk2 roms, no problems (except CTF fixable via FMP), so if this is the hardware behavior of the mk1, I think I'll stick with the mk2.

Do not compare your extracted .mid files to ingame Midi music of the same tracks since they are most likely different. E.g. the Midi file in your attached 08 - Episode 1 - Ah, Geez! [Lee Jackson].zip differs from the most used extracted rips (e.g. from mirsoft.info).

Falcosoft wrote on 2024-05-20, 13:29:

Do not compare your extracted .mid files to ingame Midi music of the same tracks since they are most likely different. E.g. the Midi file in your attached 08 - Episode 1 - Ah, Geez! [Lee Jackson].zip is definitely not from the game and it differs even from the most used extracted rips (e.g. from mirsoft.info).

Now I extracted the midi tracks from the "DUKE3D.GRP" file with SLADE. Another track has the same problem, so the tracks are:
AHGEEZ.MID (E1L7)
XPLASMA.MID (E2L8)
GLOOMY.MID (E2L10)

XPLASMA.MID and GLOOMY.MID in DOSBox plays without errors (I couldn't also test AHGEEZ.MID, but the result would probably be the same).
Also note that with Rednukem all music tracks return that error and the music is completely broken.

I attach the midi files for testing.

EDIT
Even with 86Box (Windows 95 machine with Duke Nukem 3D DOS version) the tracks are played correctly, so I think:
1. It's a bug in the SC-55 mk1 emulation
2. Windows Media Player, Falcosoft MIDI Player and Rednukem send garbage to Nuked SC-55 mk1

Kappa971 wrote on 2024-05-20, 13:49:

Now I extracted the midi tracks from the "DUKE3D.GRP" file with SLADE. Another track has the same problem, so the tracks are: AH […]
Show full quote

Falcosoft wrote on 2024-05-20, 13:29:

Do not compare your extracted .mid files to ingame Midi music of the same tracks since they are most likely different. E.g. the Midi file in your attached 08 - Episode 1 - Ah, Geez! [Lee Jackson].zip is definitely not from the game and it differs even from the most used extracted rips (e.g. from mirsoft.info).

Now I extracted the midi tracks from the "DUKE3D.GRP" file with SLADE. Another track has the same problem, so the tracks are:
AHGEEZ.MID (E1L7)
XPLASMA.MID (E2L8)
GLOOMY.MID (E2L10)

XPLASMA.MID and GLOOMY.MID in DOSBox plays without errors (I couldn't also test AHGEEZ.MID, but the result would probably be the same).
Also note that with Rednukem all music tracks return that error and the music is completely broken.

I attach the midi files for testing.

I do not know what you exactly mean by "in DOSBox plays without errors", but I get the same 'MIDI Buff. Full!' error when I play back the above Midi files in DosBox with the help of DosMid as with FSMP/WMP on Windows.
(DOSMid - an open-source MIDI player for DOS).
So yes, there are definitely Midi buffering related problems with mkI roms.
In case of 'MIDI Buff. Full' error you can get different instrument related problems even on the same player when you start an affected Midi file multiple times.

@Edit:
Van basco\Winamp\MPC-HC\GNMidi\Tom's MIDI player\MIDITrail play back the attached Midi files with the same MIDI Buff. Full error and (mostly) default instruments on all channels.
So I strongly think that theory 2. is out.

PS: As I said before do not compare Midi file players to game engines. Game engines are not generic Midi players. They can send special/modified Midi streams to output since they know the internal specifics of the game.

tested on real hardware sc-55 mk1, firmware 1.20.
emulator with 1.21 and 1.20 firmware
master build

The same file gives error using the emulator and no error on real hardware.

This should be posted to github, I believe Kappa971 "owns" this issue, therefore I wont post it.

I'm not getting a "MIDI Buff. Full!" error with AHGEEZ.MID when using the SC55 1.21 roms with the JC Moyer Windows XP build and FSMP.

However, the music doesn't play correctly unless I use 2 instances.

paxstatic wrote on 2024-05-20, 14:49:

I'm not getting a "MIDI Buff. Full!" error with AHGEEZ.MID when using the SC55 1.21 roms with the JC Moyer Windows XP build and FSMP.

However, the music doesn't play correctly unless I use 2 instances.

What kind of virtual cable are you using between FSMP and the emulator on your Win XP? Is it an earlier WinXP compatible LoopMidi or Midi-Yoke/Maple or something else?