Home Page Forums MAME MAME es550x generate_pcm function: there's a bug?

I'm looking into the es550x_device::generate_pcm function in the es5506.cpp file, and i'm unsure if there's a tiny bug or it is just me not understanding what happens.

The function gets two samples of the current ROM wave to interpolates them, and then (after filters and volume) outputs the result.

What i'm asking is if, in the case of a ROM wave with an odd samples count, when val1 is the last sample, val2 will get a value which is not part of the ROM wave, 'cause accum update and check_for_end_forward happens only at the end, instead of between the two read_sample calls.

Or am i missing how get_integer_addr(accum, 1)) works, and this is fine as it is?

It does look like it may end up grabbing one sample past the end of the current sample, so you may have hit on a bug here.

That said, this sounds like the XY problem. What is the issue in particular that you're trying to solve?

Follow-up: There are 3 places in the ES5506 device where it looks like, as you suggest, it can end up trying to interpolate against one sample past the end of the specific voice.

I have a potential fix, but I'm uncomfortable with the fix. In all likelihood, Ensoniq wouldn't have bothered taking up the silicon to have limit checks to compare against the end of a particular voice when interpolating its samples.

I suspect that what looks like a bug to both you and me is probably actual hardware behavior. Developers would have been aware of this behavior and most likely would have padded the voice ROMs by one additional sample per voice in order to account for it.

It's a really good catch - thanks for that, I liked having something to dig into on a lazy Sunday afternoon - but I think you don't need to worry about it.

Nothing
TL:DR: i'm reverse-engineering how the ROM sounds are stored and played.

Long read:
I'm trying to get a decent set of samples to convert in wavetables and to be used in modern VTSs to "emulate" (and reproduce) the sounds of my loved SQ1. So i'm just messing with the code saving already interpolated wavs and looking at how the "transwaves" works by printing out the "accum" address to see what part of the sound ROM is being played.
So i noticed that sometime the address goes over the voice->end, and started to look at it.

I'm not so sure; this image shows the waveform (directly from ROM data):

that "spike" is between two different "waves", and it is present between almost all of them. I think that it is not planned to be read and played.

I would like to see it, if you're willing to share it. I'll try it in the intimacy of my PC along with all the mess (pun unintended ) i'm doing to get my print and samples

The technical manual has this to say about it when the accumulator address equals loop end:
"If this occurs, on the next sample OTTO will fetch the data at locations Loop End and Loop End +1. This possibility requires that the Loop End +1 data be set equal to the Loop Start data."

Try this patch, let me know if it solves anything. Or even if it doesn't. https://gist.github.com/MooglyGuy/3f2499059e2b06a8e6a7b46d9514fe4b

Ohh, this is interesting.
DO i break some rule if i ask where could i read that manual?

Thanks, i'll do it ASAP... but i want to look closer to what hap has posted.

Ok, google for "es5506.pdf", it's the first link.

Yeah, so the emulation is correct then, as JD thought.

EDIT
Ok, all loopable samples have an additional "plausible" sample (not equal, but near) after the end, so it is true (or can be considered true) also for the es5505.
Thank you.

Could it be true only for the es5506?

From the SQ1 (es5505) it does not seems true:

The picture shows the end of a sample with odd sample lenght and the beginning of the next one. The first value after is not equal.