EmperorGrieferus wrote on 2024-05-14, 19:43:

Falcosoft wrote on 2024-05-14, 18:41:

Can you share an example of such clipping? Actually clipping in the traditional sense should not happen even in the 16-bit int […]
Show full quote

EmperorGrieferus wrote on 2024-05-14, 17:10:

Maybe it's my fault, but even with 32-bit output there's some audible clipping.

Can you share an example of such clipping?
Actually clipping in the traditional sense should not happen even in the 16-bit integer/master version since version 0.1.1.
https://github.com/nukeykt/Nuked-SC55/commit/ … 4f3447972317948

This is small selection from Descent 2 credits theme. I know, I could've mute drums so I wouldn't need to cut this part out, but hey.

Sounds like aliasing but it's way too short a sample. Please include the whole track for proper analysis, with a gap at the start and end.

Spikey wrote on 2024-05-15, 06:15:

EmperorGrieferus wrote on 2024-05-14, 19:43:

Falcosoft wrote on 2024-05-14, 18:41:

Can you share an example of such clipping?
Actually clipping in the traditional sense should not happen even in the 16-bit integer/master version since version 0.1.1.
https://github.com/nukeykt/Nuked-SC55/commit/ … 4f3447972317948

This is small selection from Descent 2 credits theme. I know, I could've mute drums so I wouldn't need to cut this part out, but hey.

Sounds like aliasing but it's way too short a sample. Please include the whole track for proper analysis, with a gap at the start and end.

For the sake of discussion but also an eagerness to learn. Why do you (generally?) want a gap at the beginning and end?

Karmeck wrote on 2024-05-15, 11:04:

...
For the sake of discussion but also an eagerness to learn. Why do you (generally?) want a gap at the beginning and end?

I think because it's not always obvious if a click/crack/pop at the very beginning is caused by a sudden cut of a previous sample (or other recording related artifact) or genuinely generated this way by the emulator.

Falcosoft wrote on 2024-05-14, 20:34:

It does not sound and does not look like clipping. There is a glitch-like problem at the very beginning of the right channel but […]
Show full quote

EmperorGrieferus wrote on 2024-05-14, 19:43:

Falcosoft wrote on 2024-05-14, 18:41:

Can you share an example of such clipping?
Actually clipping in the traditional sense should not happen even in the 16-bit integer/master version since version 0.1.1.
https://github.com/nukeykt/Nuked-SC55/commit/ … 4f3447972317948

This is small selection from Descent 2 credits theme. I know, I could've mute drums so I wouldn't need to cut this part out, but hey.

It does not sound and does not look like clipping. There is a glitch-like problem at the very beginning of the right channel but it's not because of sample overflow/clipping (the amplitude at the glitch is about -5 dBFS). There are louder problem free samples in the recording. Maybe a buffer underrun or another bug?
Just to be clear: You also hear it real-time from the synth not just on the recordings, don't you?
glitch.png

Yeah, real-time as well.

Spikey wrote on 2024-05-15, 06:15:

EmperorGrieferus wrote on 2024-05-14, 19:43:

Falcosoft wrote on 2024-05-14, 18:41:

Can you share an example of such clipping?
Actually clipping in the traditional sense should not happen even in the 16-bit integer/master version since version 0.1.1.
https://github.com/nukeykt/Nuked-SC55/commit/ … 4f3447972317948

This is small selection from Descent 2 credits theme. I know, I could've mute drums so I wouldn't need to cut this part out, but hey.

Sounds like aliasing but it's way too short a sample. Please include the whole track for proper analysis, with a gap at the start and end.

Here's the longer version. The clipping-like effect is best heard in uncompressed version, but it's still pretty audible here.
Link to an uncompressed version: https://drive.google.com/file/d/1PmI_hy0kxihy … iew?usp=sharing

Maybe asking about somthing obvious here, but. Why do we need a recording, from anyone?

Everyone has access to what is tested, and the files needed to conduct their own test. If errors occur that no one can reproduce, other than the person having them, it's fair to call for bad hardware or even user error (no disrespect).

At the same time, I do see, the satisfaction, in squishing a rare bug.

If no issue exist of this, issue, over at GitHub, I very much appreciated if it was crated, so it can be properly tracked. And more people can be aware of it. As I can't hear it, I can't create it my self.

EmperorGrieferus wrote on 2024-05-15, 18:20:

Spikey wrote on 2024-05-15, 06:15:

EmperorGrieferus wrote on 2024-05-14, 19:43:

This is small selection from Descent 2 credits theme. I know, I could've mute drums so I wouldn't need to cut this part out, but hey.

Sounds like aliasing but it's way too short a sample. Please include the whole track for proper analysis, with a gap at the start and end.

Here's the longer version. The clipping-like effect is best heard in uncompressed version, but it's still pretty audible here.
Link to an uncompressed version: https://drive.google.com/file/d/1PmI_hy0kxihy … iew?usp=sharing

It might be worth adjusting buffer settings as a troubleshooting step.

EmperorGrieferus wrote on 2024-05-15, 18:20:

Spikey wrote on 2024-05-15, 06:15:

EmperorGrieferus wrote on 2024-05-14, 19:43:

This is small selection from Descent 2 credits theme. I know, I could've mute drums so I wouldn't need to cut this part out, but hey.

Sounds like aliasing but it's way too short a sample. Please include the whole track for proper analysis, with a gap at the start and end.

Here's the longer version. The clipping-like effect is best heard in uncompressed version, but it's still pretty audible here.
Link to an uncompressed version: https://drive.google.com/file/d/1PmI_hy0kxihy … iew?usp=sharing

What these recordings are demonstrating isn't clipping but aliasing, assuming you mean the filter sound. Aliasing is most famously heard on the JV-80 series. It's similar to clipping in the sense that distortion is generated above a volume threshold but unlike clipping, volume doesn't have to be above 0dB for the aliasing effect to be heard.
It's typically heard in filter sweeps and resonant type sounds. And TBH, I don't always consider it a negative thing. Love it at times on my JV-90.

Aliasing is definitely typical (in certain cases) on the SC-adjacent JV-80/880/90/1000, but I don't remember it in the SC-55. Of course I haven't listened to a real SC-55 for some time.

From the Roland JV FAQ (credit to Don Solaris):
"A 32 kHz DAC can in fact produce frequencies above 16 kHz. This is considered an artifact and is known as aliasing. Back then manufacturers spent a ton of resources to suppress and remove as much of these as possible. As we can see Roland went for the simpler / cheaper option with some basic LPF filter behind the DAC, far away in specs of today’s brick wall filters. In fact service manual suggest this scenario as well. As a result of all that a lot of signal is aliased."
This was also changed in the Roland JV-1080 and beyond, which has much less of this. Both for better and worse.

Emperor, do you have a link to the specific MIDI you used so others can test the hypothesis?

For the sake of discussion but also an eagerness to learn. Why do you (generally?) want a gap at the beginning and end?

Well, it depends on the scenario. In the UltraProteus I wanted it so I could remove awful shrill noise from the recording and make it listenable!
In this case, we don't know what's going on with the user's setup - in fact everyone pretty much uses different audio devices with their Roland's etc. It's useful to hear what the background noise level is in someone's setup (sometimes that could even be the problem or exacerbating it), and also sample and remove it from the recording and see if results are different then.

And as Falcosoft mentioned, it's useful to hear things in totality. We don't know from a 7 second sample whether the track plays normally and if that was an aberration, or whether the (perceived) issue is throughout, etc etc. The beginning and end of recordings done by non-savvy people can result in distorted audio themselves.

Maybe asking about somthing obvious here, but. Why do we need a recording, from anyone?

The objective is to determine if there IS an issue or whether this is expected behaviour (as in, the aliasing happens on real hardware, therefore it's not a bug) - or if there is an issue, whether it's on the user's side etc. Let me put this to you - without hearing what the user is hearing, how would anyone be able to test that user's claim or even know what their issue is?

Spikey wrote on 2024-05-16, 13:22:

What these recordings are demonstrating isn't clipping but aliasing, assuming you mean the filter sound. Aliasing is most famous […]
Show full quote

EmperorGrieferus wrote on 2024-05-15, 18:20:

Spikey wrote on 2024-05-15, 06:15:

Sounds like aliasing but it's way too short a sample. Please include the whole track for proper analysis, with a gap at the start and end.

Here's the longer version. The clipping-like effect is best heard in uncompressed version, but it's still pretty audible here.
Link to an uncompressed version: https://drive.google.com/file/d/1PmI_hy0kxihy … iew?usp=sharing

What these recordings are demonstrating isn't clipping but aliasing, assuming you mean the filter sound. Aliasing is most famously heard on the JV-80 series. It's similar to clipping in the sense that distortion is generated above a volume threshold but unlike clipping, volume doesn't have to be above 0dB for the aliasing effect to be heard.
It's typically heard in filter sweeps and resonant type sounds. And TBH, I don't always consider it a negative thing. Love it at times on my JV-90.

Aliasing is definitely typical (in certain cases) on the SC-adjacent JV-80/880/90/1000, but I don't remember it in the SC-55. Of course I haven't listened to a real SC-55 for some time.

From the Roland JV FAQ (credit to Don Solaris):
"A 32 kHz DAC can in fact produce frequencies above 16 kHz. This is considered an artifact and is known as aliasing. Back then manufacturers spent a ton of resources to suppress and remove as much of these as possible. As we can see Roland went for the simpler / cheaper option with some basic LPF filter behind the DAC, far away in specs of today’s brick wall filters. In fact service manual suggest this scenario as well. As a result of all that a lot of signal is aliased."
This was also changed in the Roland JV-1080 and beyond, which has much less of this. Both for better and worse.

Emperor, do you have a link to the specific MIDI you used so others can test the hypothesis?

Just call me Grieferus, since I can't really change my nickname here. Anyway, here it is: https://drive.google.com/file/d/1P_UxGggi-rqU … iew?usp=sharing
Strangely enough, aliasing isn't present in the official release versions.

Falcosoft wrote on 2024-04-21, 23:42:

The final buffer size is a product of page_size and page_count (page_size * page_count). If you want 4096 as a final buffer size […]
Show full quote

Karmeck wrote on 2024-04-21, 23:19:

Greatly appreciated and a bit overwhelming. So many new options.

What is the default buffer size? I can find the number 4096.

The final buffer size is a product of page_size and page_count (page_size * page_count). If you want 4096 as a final buffer size you can use e.g. 1024 as page_size and 4 as page count

Copy code to clipboard

1-ab:1024:4

The default buffer size of the above test release is 8192

Copy code to clipboard

1-ab:2048:4

The master version uses 16384:

Copy code to clipboard

1-ab:512:32

@Edit:
I have also made a 32-bit Win XP compatible test release. Since under Win XP SDL2 cannot use WASAPI only Directsound bigger buffer defaults are set (-ab:8192:4). In the zip the 32-bit SDL2.dll is also included.
https://github.com/Falcosoft/Nuked-SC55/relea … t_x86_winxp.zip

It works fairly well with a Core2 Duo 3.2 GHz under Win XP SP3 (30-35% CPU usage).

I've been using the Windows XP build and it works great.

Hopefully, future updates will be made for Windows XP in the future.

paxstatic wrote on 2024-05-16, 23:21:

Falcosoft wrote on 2024-04-21, 23:42:

The final buffer size is a product of page_size and page_count (page_size * page_count). If you want 4096 as a final buffer size […]
Show full quote

Karmeck wrote on 2024-04-21, 23:19:

Greatly appreciated and a bit overwhelming. So many new options.

What is the default buffer size? I can find the number 4096.

The final buffer size is a product of page_size and page_count (page_size * page_count). If you want 4096 as a final buffer size you can use e.g. 1024 as page_size and 4 as page count

Copy code to clipboard

1-ab:1024:4

The default buffer size of the above test release is 8192

Copy code to clipboard

1-ab:2048:4

The master version uses 16384:

Copy code to clipboard

1-ab:512:32

@Edit:
I have also made a 32-bit Win XP compatible test release. Since under Win XP SDL2 cannot use WASAPI only Directsound bigger buffer defaults are set (-ab:8192:4). In the zip the 32-bit SDL2.dll is also included.
https://github.com/Falcosoft/Nuked-SC55/relea … t_x86_winxp.zip

It works fairly well with a Core2 Duo 3.2 GHz under Win XP SP3 (30-35% CPU usage).

I've been using the Windows XP build and it works great.

Hopefully, future updates will be made for Windows XP in the future.

Windows xp version also made it possible for me to start the emulator on an a really old laptop. With windows 10, but one of those official lighter versions.
Ran like shit and is unusable, but it starts.

EmperorGrieferus wrote on 2024-05-16, 17:00:

....
Strangely enough, aliasing isn't present in the official release versions.

It seems this problem has nothing to do with 32-bit floating point output but the optimizitaions made by Eivind that were also included in the floating point test build.
I have made another fp32 test build based on Jcmoyer 's fork that includes the FP32 output PR among others (multiple instances, wave converter etc.). It seems the aliasing is on the same level as on master but with the advantages that fp32 output offers. The only downside is that without Eivind's optimazations the performance requirements are higher (almost twice) but it's also true for master releases.
The emulator is a little bit faster when it is used with the --no-lcd parameter.
This fork uses slightly different syntax for parameters (you have to use a space between parameter names and parameter values e.g : -p 1 -r gs):

1C:\Users\falco\Desktop\Nuked-SC55-modernize\bin\Release>nuked-sc55.exe -h
2Usage: nuked-sc55 [options]
3Options:
4  -h, --help, -?                                Display this information.
5
6  -p, --port          <port_number>             Set MIDI port.
7  -a, --audio-device  <device_number>           Set Audio Device index.
8  -b, --buffer-size   <page_size>:[page_count]  Set Audio Buffer size.
9  -f, --format        s16|f32                   Set output format.
10  -n, --instances     <count>                   Set number of emulator instances.
11  --no-lcd                                      Run without LCDs.
12
13  -d, --rom-directory <dir>                     Set directory to look for ROMs in.
14  --mk2                                         Use SC-55mk2 ROM set.
15  --st                                          Use SC-55st ROM set.
16  --mk1                                         Use SC-55mk1 ROM set.
17  --cm300                                       Use CM-300/SCC-1 ROM set.
18  --jv880                                       Use JV-880 ROM set.
19  --scb55                                       Use SCB-55 ROM set.
20  --rlp3237                                     Use RLP-3237 ROM set.
21
22  -r, --reset        gs|gm                      Reset system in GS or GM mode.

In case of the renderer input and output parameters are mandatory. Input has to be a .mid file and output a .wav file.

1C:\Users\falco\Desktop\Nuked-SC55-modernize\bin\Release>nuked-sc55-render.exe
2error: No input file specified
3Usage: nuked-sc55-render.exe <input>
4Options:
5  -h, --help                     Print this message
6  -o <filename>                  Render to filename
7  -n, --instances <instances>    Number of emulators to use (increases effective polyphony, longer to render)
8  -r, --reset gs|gm              Send GS or GM reset before rendering.
9  -d, --rom-directory <dir>      Sets the directory to load roms from.
10  -f, --format s16|f32           Set output format.

Source is at:
https://github.com/jcmoyer/Nuked-SC55/tree/modernize

64-bit Windows binaries (both the emulator and wave converter is included):

paxstatic wrote on 2024-05-16, 23:21:

...
I've been using the Windows XP build and it works great.

Hopefully, future updates will be made for Windows XP in the future.

Here is a 32-bit Win XP compatible binary package from the same source as the above package:

Be aware that the performance requirements are higher than the previous WinXP build (it's about the same as the 64-bit version).
Also be aware that SDL2 can use only Directsound under WinXP so page size has to be set higher that has negative effect on Midi timing/precision. This Win XP build uses 6144: 3 by default.

PS: 32-bit SDL.dll is NOT included. If you need the 32-bit SDL2 library you can find it in the previous Win XP package:
https://github.com/Falcosoft/Nuked-SC55/relea … t_x86_winxp.zip

Falcosoft wrote on 2024-05-18, 09:40:

Here is a 32-bit Win XP compatible binary package from the same source as the above package: nuked-sc55_jcmoyer_fp32test_WinXP. […]
Show full quote

Here is a 32-bit Win XP compatible binary package from the same source as the above package:
nuked-sc55_jcmoyer_fp32test_WinXP.zip

Be aware that the performance requirements are higher than the previous WinXP build (it's about the same as the 64-bit version).
Also be aware that SDL2 can use only Directsound under WinXP so page size has to be set higher that has negative effect on Midi timing/precision. This Win XP build uses 6144: 3 by default.

PS: 32-bit SDL.dll is NOT included. If you need the 32-bit SDL2 library you can find it in the previous Win XP package:
https://github.com/Falcosoft/Nuked-SC55/relea … t_x86_winxp.zip

Thanks.

I used the newer version and it's okay for playback, but it utilizes 80-90% of my CPU. So there's not much left over for the OS and Dosbox.

With the optimized version it's more like 55% to 65%.

I'll stick with the optimized version for now.

paxstatic wrote on 2024-05-18, 11:59:

Thanks. […]
Show full quote

Falcosoft wrote on 2024-05-18, 09:40:

Here is a 32-bit Win XP compatible binary package from the same source as the above package: nuked-sc55_jcmoyer_fp32test_WinXP. […]
Show full quote

Here is a 32-bit Win XP compatible binary package from the same source as the above package:
nuked-sc55_jcmoyer_fp32test_WinXP.zip

Be aware that the performance requirements are higher than the previous WinXP build (it's about the same as the 64-bit version).
Also be aware that SDL2 can use only Directsound under WinXP so page size has to be set higher that has negative effect on Midi timing/precision. This Win XP build uses 6144: 3 by default.

PS: 32-bit SDL.dll is NOT included. If you need the 32-bit SDL2 library you can find it in the previous Win XP package:
https://github.com/Falcosoft/Nuked-SC55/relea … t_x86_winxp.zip

Thanks.

I used the newer version and it's okay for playback, but it utilizes 80-90% of my CPU. So there's not much left over for the OS and Dosbox.

With the optimized version it's more like 55% to 65%.

I'll stick with the optimized version for now.

Update:

I made some adjustments.

In task manager, I assigned Nuked SC-55 it's own core using the Affinity option. I did the same with Dosbox. Now Dosbox and the OS don't fight for CPU resources with Nuked SC-55.

I'm now using this updated Nuked SC-55 version for all tasks.

In relation to the general performance, has anyone looked into the elephant in the room, namely the slightly weird 2x oversampling from 32,000 to 64,000 Hz? If that is not strictly necessary, and the whole digital circuit simulation (or a large portion of it) literally runs 64k times instead of just 32k times per second, getting rid of it might yield major dividends.

The best type of performance optimisation is not doing the work at all 😎

Does the hardware even do any 2x oversampling on the digital sample-generation side? Does anyone know? Or is this something that Nukey tacked on for whatever reasons? I've spent ten minutes now looking into it, but I can't tell if

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.

If case 1 is true, probably there's nothing to do.

In case 3, there's not much to be gained by not oversampling as an extra post-processing step as it's cheap. (But the 2x upsampling is still very much questionable... Why 2x? The correct way would be to render at 32k, then resample to whatever the host rate is by a high-quality resampler. Currently, resampling from 64k to the host rate is done the OS or the audio subsystem anyway, just you'll have no control over it, and you're resampling twice instead of just once.)

But in case 2 things get interesting, and there are some major potential performance improvements to be had! Ideally, in case 2 we'd want to render at 32k, true to the real hardware, then introduce a high-quality resampler library that introduces low latencies, like Speex DSP. The Speex DSP resampler has much lower latency than, say, libresample, is very good quality, and has negligible CPU overhead on modern hardware (like 1-2% of a single CPU core at high-quality settings). We use it DOSBox Staging for most resampling duties now, it's great (e.g., from the weird native OPL rate to 48k or 44.1k, to do the "brickwall filter" style resampling on the SB16, etc.)

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:

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

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

to

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

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.

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

It seems to be case 3. The introduction of oversampling was final sample mixing related:
[...]
It's very easy to disable oversampling by modifying 2 places in code. And it has almost zero impact on performance.

Thanks man, I appreciate the tip. Yeah, I suspected case 3 was the most likely scenario, but I was hopeful for case 2 😀

This will come in handy when I'll convert this thing to a CLAP plugin in a few months' time. I'm just gonna run it at the original ~32k rates and resample to the host rate via Speex.