Eivind wrote on 2024-04-25, 19:42:

(I assume 18-bit samples from ROM, shifted up by 14 to fill 32 bits to increase precision in processing)

18bit is from the DAC, not the size of the samples stored wave form

Eivind wrote on 2024-04-25, 19:42:

Falcosoft wrote on 2024-04-25, 15:32:

It does not depend on what you use the emulator for (games/Midi files). With the current implementation FLOAT32 doubles dynamic range/sample resolution. More precisely in order to prevent clipping the INT16 output path halves sample resolution in the last step currently. It can be heard in case of any Midi titles since the overall volume of INT16 is halved. And in case of low volume Midi files the noise is also more audible if you want to get the same audio output level.
BTW, on Windows seemingly FLOAT32 has no such negative effect. You can use the same buffer sizes as with INT16. Maybe it's because the native format of shared mode WASAPI (that SDL2 uses on Win Vista+) is 32-bit float.

I apologize in advance if this is a stupid question, but if you don't ask, you don't learn! 😁
Please help me understand why we'd need to right-shift the 32-bit integer samples coming from pcm.cpp by 15 instead of 14 (I assume 18-bit samples from ROM, shifted up by 14 to fill 32 bits to increase precision in processing)? I'm sure I'm missing something essential here, but why would the right-shifted-by-14 value be clipping at all? Because of the implementation details of the audio processing in pcm.cpp? In my (I'm sure naive) thinking, the original hardware wouldn't produce 18-bit output samples that clipped?

Unfortunately I do not know the exact whys either. I can only tell/describe what is happening with the current implementation. If you only right shift by 14 you clearly can get samples in case of high volume Midi files that are clipped (they are bigger than 32767 or smaller than -32768 that are the maximum and minimum values that fit into 16-bit signed integer). But even the loudest samples are only out of range by about 50% (this is just a practical observation). With the current implementation at least 17-bit would be necessary to represent all discrete sample values produced by the emulation. The point is that you actually get hard clipping in case of 14-bit right shifts that are clearly audible. In case of 15-bit right shifts the clipping is completely gone since even the loudest samples are only about 50% higher/lower than the halved range (max/min values are about at +/- 25000). So they perfectly fit into the range provided by 16-bit integer . But this way you actually halve the resolution (values 3 and 2 both become 1; 32767 and 32766 both become 16383 and so on).
24-bit integer would be more than enough to represent the full sample range of the emulator but SDL2 seemingly has no such type for audio output:
https://github.com/libsdl-org/SDL/issues/5885
So we only have 32-bit float or 32-bit integer to solve this problem. But 32-bit float has the advantage that normalized values (from -1.0f to + 1.0f) are only "soft" limits. Values above or below the normalized range are not lost as in case of integer types (even for 32-bit integer). There is no hard clipping in the traditional sense in case of floating point audio.
In case of Windows an additional advantage of 32-bit float is that shared mode WASAPI also uses 32-bit float as native audio format.

Falcosoft wrote on 2024-04-25, 16:56:

512/4 compared to 512:32 (default) does not alter the Midi precision/timing at all it only decreases the audio latency. The console only shows the pageSize changes (pageSize /4 exactly as B=xxx).

Good, thanks.

Falcosoft wrote on 2024-04-25, 21:47:

Unfortunately I do not know the exact whys either. I can only tell/describe what is happening with the current implementation. I […]
Show full quote

Unfortunately I do not know the exact whys either. I can only tell/describe what is happening with the current implementation. If you only right shift by 14 you clearly can get samples in case of high volume Midi files that are clipped (they are bigger than 32767 or smaller than -32768 that are the maximum and minimum values that fit into 16-bit signed integer). But even the loudest samples are only out of range by about 50% (this is just a practical observation). With the current implementation at least 17-bit would be necessary to represent all discrete sample values produced by the emulation. The point is that you actually get hard clipping in case of 14-bit right shifts that are clearly audible. In case of 15-bit right shifts the clipping is completely gone since even the loudest samples are only about 50% higher/lower than the halved range (max/min values are about at +/- 25000). So they perfectly fit into the range provided by 16-bit integer . But this way you actually halve the resolution (values 3 and 2 both become 1; 32767 and 32766 both become 16383 and so on).
24-bit integer would be more than enough to represent the full sample range of the emulator but SDL2 seemingly has no such type for audio output:
https://github.com/libsdl-org/SDL/issues/5885
So we only have 32-bit float or 32-bit integer to solve this problem. But 32-bit float has the advantage that normalized values (from -1.0f to + 1.0f) are only "soft" limits. Values above or below the normalized range are not lost as in case of integer types (even for 32-bit integer). There is no hard clipping in the traditional sense in case of floating point audio.
In case of Windows an additional advantage of 32-bit float is that shared mode WASAPI also uses 32-bit float as native audio format.

Thanks for the explanation! I suppose a multiplication of 5 / 4 and then >> 15 would improve the amplitude somewhat then?
In any case, since I was planning to use the Pi with an I2S DAC (the built-in, PWM one is pretty crappy), I changed the default audio output to I2S even though I hadn't hooked one of the PCM5102-based ones up yet - and wouldn't you know, now a pageSize of as low as 520 is accepted for F32LSB samples, without spitting out buffer underruns.
I'll get the hardware going tomorrow and see if this actually works.

Eivind wrote on 2024-04-25, 22:56:

I'll get the hardware going tomorrow and see if this actually works.

Yeah! Getting rock solid performance without stuck notes, tempo glitches or anything with 32-bit floats and an I2S DAC!
-ab:520:{pageNum} works fine, pageNum can also be set low, like 8 for very low latency.

Eivind wrote on 2024-04-26, 09:17:

Yeah! Getting rock solid performance without stuck notes, tempo glitches or anything with 32-bit floats and an I2S DAC! -ab:520: […]
Show full quote

Eivind wrote on 2024-04-25, 22:56:

I'll get the hardware going tomorrow and see if this actually works.

Yeah! Getting rock solid performance without stuck notes, tempo glitches or anything with 32-bit floats and an I2S DAC!
-ab:520:{pageNum} works fine, pageNum can also be set low, like 8 for very low latency.

IMG_1239.jpeg

Nice, it's good to hear it is working!

okay, we need a cool name for this now.

zaphod77 wrote on 2024-04-26, 18:28:

okay, we need a cool name for this now.

I'll give you a few:

NukedPi
Pi Canvas
SC-Pi
Sound Canvas Mini
Mini-SC
Sound Canvas Classic (only if it's at a ridiculous price like the NES Classic 🤣)
Sound Canvas Micro

https://github.com/nukeykt/Nuked-SC55/releases/tag/0.3.0

JV-880 is supported now (@giulioz) SCB-55 and RLP-3237 are supported now (@matt713) More command line options: audio config, gm/ […]
Show full quote

JV-880 is supported now (@giulioz)
SCB-55 and RLP-3237 are supported now (@matt713)
More command line options: audio config, gm/gs reset (@Falcosoft, @pachuco, @UnBeatWaterGH)
CPU emulation fixes

PS - where can i find more info about command line option and which should i use for err.. daily use (mainly dosbox gaming)? 😅

KainXVIII wrote on 2024-04-26, 19:34:

https://github.com/nukeykt/Nuked-SC55/releases/tag/0.3.0

JV-880 is supported now (@giulioz) SCB-55 and RLP-3237 are supported now (@matt713) More command line options: audio config, gm/ […]
Show full quote

JV-880 is supported now (@giulioz)
SCB-55 and RLP-3237 are supported now (@matt713)
More command line options: audio config, gm/gs reset (@Falcosoft, @pachuco, @UnBeatWaterGH)
CPU emulation fixes

PS - where can i find more info about command line option and which should i use for err.. daily use (mainly dosbox gaming)? 😅

The command line options there at the end of the readme is to select what moduel to use, if you have more then one ROM set.

I don't know if the other command line options mention here is supported yet in a release version.

KainXVIII wrote on 2024-04-26, 19:34:

https://github.com/nukeykt/Nuked-SC55/releases/tag/0.3.0

JV-880 is supported now (@giulioz) SCB-55 and RLP-3237 are supported now (@matt713) More command line options: audio config, gm/ […]
Show full quote

JV-880 is supported now (@giulioz)
SCB-55 and RLP-3237 are supported now (@matt713)
More command line options: audio config, gm/gs reset (@Falcosoft, @pachuco, @UnBeatWaterGH)
CPU emulation fixes

PS - where can i find more info about command line option and which should i use for err.. daily use (mainly dosbox gaming)? 😅

It seems the -h (help) command line parameter option has been added to latest release so you should try it first.

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

KainXVIII wrote on 2024-04-26, 19:34:

https://github.com/nukeykt/Nuked-SC55/releases/tag/0.3.0

JV-880 is supported now (@giulioz) SCB-55 and RLP-3237 are supported now (@matt713) More command line options: audio config, gm/ […]
Show full quote

JV-880 is supported now (@giulioz)
SCB-55 and RLP-3237 are supported now (@matt713)
More command line options: audio config, gm/gs reset (@Falcosoft, @pachuco, @UnBeatWaterGH)
CPU emulation fixes

PS - where can i find more info about command line option and which should i use for err.. daily use (mainly dosbox gaming)? 😅

It seems the -h (help) command line parameter option has been added to latest release so you should try it first.

Silly me, i'm used to -? command line parameter and haven't tried -h!

OpenRift wrote on 2024-04-26, 19:21:

zaphod77 wrote on 2024-04-26, 18:28:

okay, we need a cool name for this now.

I'll give you a few:

how about making another thread and stop spamming here with totally unrelated Low-Performance Pi discussion. I for one have stopped to read and post here, because I am completely tired of those Pi-related posts, that from my point of view, has absolutely nothing to do with the project and its goals. every time I look this thread to read something useful and on point - it's just another Pi post - I really don't get it?!

mattw wrote on 2024-04-27, 12:56:

how about making another thread and stop spamming here with totally unrelated Low-Performance Pi discussion. I for one have stopped to read and post here, because I am completely tired of those Pi-related posts, that from my point of view, has absolutely nothing to do with the project and its goals. every time I look this thread to read something useful and on point - it's just another Pi post - I really don't get it?!

Well, it does seem clear you don't get it, so we can agree there.

That being said, most if not all of the Pi-related optimizations _directly_ benefit all other platforms, so...sorry if you have to skip a few posts that don't interest you? Sounds like maybe you should just watch the github checkins so you can mainline all the techy goodness without having to deal with pesky humans =)

I'm not fond of idea of running Nuked SC-55 on Pi either. Mostly because it will open pandora box and might cause unscrupulous people starting selling Pi-based hardware with emulated SC-55 using my code, despite it being prohibited by non-comercial license.

nukeykt wrote on 2024-04-27, 15:13:

I'm not fond of idea of running Nuked SC-55 on Pi either. Mostly because it will open pandora box and might cause unscrupulous people starting selling Pi-based hardware with emulated SC-55 using my code, despite it being prohibited by non-comercial license.

With respect, bad people are going to do bad things no matter what you say - it's unfortunate, but it's reality. I would hardly see that as impediment to encouraging accessibility, but it is your project.

First, let me say that I'm very greatful for your hard work, nukeykt - and it's not my intention to piss anyone off here.
But I have to say - trying to control or even influence what people use open sourced software for (in terms of non-commercial hobby projects) seems utterly weird to me.
The decision to use the non-commercial MAME license is your right, of course. But it does severly restrict the usefulness of the emulator for things like dosbox and mt32-pi, to name a couple.
IMHO, the goal of open source in our retro / hobby / enthusiast community should be to make it as cheap and accessible for everyone to enjoy the nostalgia of our youth as possible. To the point of both software and hardware being so easily accessible that sketchy hardware projects from "unscrupulous people" trying to make an easy buck would fail.
Think about Adlib, Sound Blaster, GUS and even Roland's own MT-32 - they're all thoroughly emulated and integrated into all sorts of projects, and I'm not aware of any cases of people trying to sell hardware using these, posing as "the real deal".

That said, I'm happy to remove all of my (admittedly small) optimizations of the emulator code (making it run perfectly on a Pi) from github, if that's what people want.

FWIW - this is aimed at no-one in particular, but in case it's not obvious, and because I get a lot of emails and messages about this, I have absolutely **no plans** to even attempt to use Nuked-SC55 within mt32-pi whilst the current license is in place.

As someone who tries to act in good faith, I will always respect the wishes of the developer(s) and the terms of their chosen license. It's not my place to debate this, and I also don't agree with any potential FOSS zealots trying to bully someone into relicensing their work.

nukeykt wrote on 2024-04-27, 15:13:

I'm not fond of idea of running Nuked SC-55 on Pi either. Mostly because it will open pandora box and might cause unscrupulous people starting selling Pi-based hardware with emulated SC-55 using my code, despite it being prohibited by non-comercial license.

Hi. A regular normie here.

First thank you for doing all this. Sharing your knowledge and creativity with the world.

Long had I searched for a soundfont to properly represent the sc-55. But, being an perfectionist, I was never truly satisfied. Which was also the reason I gave up on crt tvs, freaking convergence.

Then this came along, praised repeatedly as the true king of emulating the sound produced by the sc-55.

Once again, thank you. I can now feel inner peace.

I think I have made it quite clear in this very thread and on github, my total lack of knowledge regarding compiling and negative experience with github as a site.

I would really love for Nuked-SC55 to be on a Pi. Clearly it can be done with what is already available. But I don't know how. Maybe 000MDK on github will get thro to me one day. But I'd say it's unlikely. I'm just copying things man, I don't know what I'm doing.

I get that I don't have any right to have anything the way I like it, just because. And I get that if I want somthing done I better learn to code and do it my self. That's not really helpful to me tho.

That's why I would do it. I would pay to have someone provide me with a Pi, with an SD card, running Nuked-SC55. Because right now there is no other way for me ....however, It would probably, at that point tho, be a Pi compatible version easily available, at which point, buying a preloaded SD card would be unnecessary.

That's how you stop it, availability, no one (well some) will buy software that is easily available and free.

I know it's not your job to do it.

But alas, I don't have a pi, and it looks increasingly likely that I'm buying a real sc-55 mk1, next week.

In the end I rather have a Pi on my desk that is just as good, and smaller.

For a third time, thank you.

Nö

Karmeck wrote on 2024-04-27, 17:17:

Hi. A regular normie here. […]
Show full quote

nukeykt wrote on 2024-04-27, 15:13:

I'm not fond of idea of running Nuked SC-55 on Pi either. Mostly because it will open pandora box and might cause unscrupulous people starting selling Pi-based hardware with emulated SC-55 using my code, despite it being prohibited by non-comercial license.

Hi. A regular normie here.

First thank you for doing all this. Sharing your knowledge and creativity with the world.

Long had I searched for a soundfont to properly represent the sc-55. But, being an perfectionist, I was never truly satisfied. Which was also the reason I gave up on crt tvs, freaking convergence.

Then this came along, praised repeatedly as the true king of emulating the sound produced by the sc-55.

Once again, thank you. I can now feel inner peace.

I think I have made it quite clear in this very thread and on github, my total lack of knowledge regarding compiling and negative experience with github as a site.

I would really love for Nuked-SC55 to be on a Pi. Clearly it can be done with what is already available. But I don't know how. Maybe 000MDK on github will get thro to me one day. But I'd say it's unlikely. I'm just copying things man, I don't know what I'm doing.

I get that I don't have any right to have anything the way I like it, just because. And I get that if I want somthing done I better learn to code and do it my self. That's not really helpful to me tho.

That's why I would do it. I would pay to have someone provide me with a Pi, with an SD card, running Nuked-SC55. Because right now there is no other way for me ....however, It would probably, at that point tho, be a Pi compatible version easily available, at which point, buying a preloaded SD card would be unnecessary.

That's how you stop it, availability, no one (well some) will buy software that is easily available and free.

I know it's not your job to do it.

But alas, I don't have a pi, and it looks increasingly likely that I'm buying a real sc-55 mk1, next week.

In the end I rather have a Pi on my desk that is just as good, and smaller.

For a third time, thank you.

Nö

There are release builds so you don't technically need to compile anything unless you want the very latest updated version.