JStella - Pitfall II sound is scratchy, but I don't know why

Java Sound & OpenAL
#1

Hey folks,
I doubt anyone can easily answer this question, but just in case someone wants an in-depth mystery to solve, I’ll ask anyway:
I manage the JStella Atari 2600 emulator project at SourceForge. It is a translation of Stella, which is open source C++ software. The sound class is only a loose translation…I sort of had to do the main framework myself, learning about Java Sound as I went.

Problem : Pitfall II has very scratchy sound, especially jumping, but Stella (its C++ parent) has decent sounds. I can’t figure out why…this may be a fault with another part of the emulator, but I figure the scratchy quality is indicative of some common phenomenon.

If anyone wants to hear the scratchy sound, visit http://www.ataritimes.com/jstella/index.php and select Pitfall II. (Click on applet, then hit F1 to flip RESET switch).
Source code can be found by browsing CVS at https://sourceforge.net/projects/jstella.

Thanks,
JLA

#2

I haven’t tried it yet (I’m still at work), but scratchy sound usually means buffer underflows.
Preventing this can be tricky.
What I did in JEmu2 is to measure the time between frames, and generate the correct amount of samples based on both the frame time, and how much the buffer is filled (if the buffer gets too empty, generate more samples to keep the buffer sufficiently filled; if the buffer is getting too full, generate less samples otherwise JavaSound will block).

In case of JStella, maybe you don’t really need to measure the time between frames and just assume it will run at the correct speed, preventing you to depend on accurate timing.

But as I said, I’m haven’t tried the sound in JStella yet so I don’t know if you actually have buffer underflows.
In any case, I’ll have a look when I get home.

#3

I just tried it out, but it’s definitely not buffer underruns. Maybe it’s just 8bit quantization noise I’m hearing?
I’m not sure yet how Atari 2600 sound really works, but it sounds like it could also be some timing error in the sound generation, resulting in the noise. Anyway, I’ll do some experimenting…

As an aside, isn’t it just totally mindblowing how they could get a game like Pitfall II on the humble Atari 2600? :slight_smile:

#4

Just tried it on the original Stella, but there it sounds about the same… So maybe the noise is just the limition of the original machine?

#5

(Yeah, Pitfall II was the coolest game when it came out…so much better than the first.)

On the original (C++) Stella (ver 2.4.1) on my computer, the jumping sound is clear, while on JStella, it is very scratchy. (JStella standalone has an option to use stereo, where the jumping and sound effects are separate from the music–the sound effects channel is scratchy as a whole). Moreover, Pitfall 1 sounds are fine…on most ROMs, the sound is great. A lot of people assumed Java couldn’t do this type of sound, and I was skeptical as well, but it overall sounds very good (that is, sounds like the Atari sounded). Except for this game…

Also, occasionally the emulator will play static/pops from manipulating the menu bar, etc. I’ve tried to turn off the sound whenever it’s paused to prevent this stuff, but I was curious if there was another way.
Thanks,
JLA

#6

I wonder if it has anything to do with “base amplitude”, that is, the number I add to every sample value to prevent popping (or so I’ve been told).

#7

Ok, now I noticed the problem with the jump sound.
If the original code emulates unsigned 8-bit samples, then I think you did it right (if you mean by the ‘base amplitude’ the -128 you do there).
I’m not sure yet what is causing the difference in sound, but I don’t think it has anything to do with JavaSound but it must be a problem in the emulation code itself. Maybe you can do a trace; somehow isolate the jump sound (patch out the music code in the rom?) and compare the generated samples from JStella with Stella. I’m not very good at 6502 code, so maybe you are more qualified to that :slight_smile:

#8

Thanks.
Off the subject, how does your Sega Master System emulator work without OpenGL / native add-ons / etc.?

#9

I’m rendering to an int[] array, which is drawn to screen using ImageProducer (MemoryImageSource is an ImageProducer) in the applet. This is really an old legacy method for rendering, but it works pretty well except that scaling the Image to a bigger size is slow.

#10

So you did not use the MediaTracker and the ImageObserver, did you? Hence it is true that MediaTracker brings faster results out of serveral ImageObserver’s. ImageObserver’s use the same ImageProducer <-> ImageConsumer relationship to download pictures. They’re faster because they download on seperate Threads. So did I understand… Well, the Sound support might be impl. in MediaTracker with one new MediaTracker.SoundMediaEntry (quoting the MediaTracker JDK src). ::slight_smile:
As a consequence, buffering data processes might be slightly modified in the way that they use no DataBuffer’s but Reference instead. So that might change the whole rendering process. But I can assume that your JStella is quite fast enough, even though Amiga (is that the correct emulated system ?) gets older and older…

#11

Emulation is about real time rendering the emulated video and audio outputs, not image/audio loading, so there’s no use for MediaTracker.
JStella emulates Atari VCS 2600 console, not the Amiga.

#12

sorry, I’m confusing in the emulatiion universe. ::)Is the amiga older though?

#13

No, I think the VCS is older…the VCS (2600) to my knowledge was 99.9% games. it was born around the same time as Star Wars, and it was popular until NES & SMS came along in the mid 80s.
Hmmm…what about an open-source combined 1980s console emulator in Java? This would treat the VCS as an 80s machine, but the Sega Genesis as a 90s machine…of course, there would need to be a NES component (and possibly the various other machines), which would be work, but at least there is plenty of available C++ code to port.