I've had a quick browse of the assembler and C++ code. I must say, it's all
a lot simpler than I expected. That is, there's really not THAT much to
emulating '2600 sound. Sound has always been my weakness; this makes me
wonder why I haven't dabbled before. OK, first things first -- I know how
sweeping generalities like "it's not that hard" can be EXTREMELY annoying
especially after you've worked long and hard at something. I've been
getting that at work recently. So take everything I say with a grain of
salt.
> > > Yes, both are GPL. But right now, z26 is in x86 assembly, and
> > > Stella is in C++. I don't know enough ASM to do the conversion.
> > > Besides, it's not just the sound code itself, but timing and
> > > resampling issues.
Are you sure? The code itself doesn't appear to be resampling. Of course,
the Z26 authors would be better at answering this one! All the soundq code
appears to do is maintain a simple queueing system -- essentially filling a
sound buffer when required, and maintaining a queue of bytes to do this
from, topping up the bytes in the queue as required (making sure it's always
half full which appears to be arbitrary and just a performance issue, I
would guess). It's interesting that there are two sound bytes queued to the
buffer per scanline. What I gather happens is that regular calls to
QueueSoundBytes every scanline will fill the internal queue with bytes and
at some indeterminate (system dependant) point, there will be a call to
Tia_process which is expected to copy bytes from the sound queue into a dma
buffer used by the system for sound transfer to hardware. The system
ensures that the dma buffer is completely filled before returning -- by
adding more queued bytes to the queue until it is. The idea being, I think,
that the two bytes added per scanline is assumed to be roughly enough so
that when the system kicks in and requests the DMA buffer to be filled,
there are essentially enough bytes on the sound queue to just do a straight
copy. But if there aren't it will queue more bytes, as stated (but this
will take longer to do, and degrade system performance and possibly even
cause sound stutter if it took too long).
> > > Heck, even if someone took a look at the current way of doing it
> > > and made some recommendations, that could help. I could probably
> > > do the actual coding; it's just the underlying timing/resampling
> > > *algorithm* that's eluded me.
I don't know a thing about actual sound. But it seems to me that the code
you present is emulating various waveforms (tiasnd.asm) at a preset
(hardwired) sample frequency which must (and here I'm in assumption mode)
correspond to the frequency chosen for the DMA 'direct sound' mode. That
is, the frequency of the DMA samples corresponds to the frequencies
generated by the sound waveform emulators. Since one call per byte is made,
you can't change the DMA sample frequency without also changing the actual
waveform generating code. There's a 1:1 correspondence, in other words.
Please note: assumptions, and I'm just trying to help.
> The main problem I'm having is that (1) not enough samples are being
> produced per frame to account for Pitfall2 and Quadrun (digital sound),
> and (2) in Windows, the sound is dropping out because the buffer size I
> use, and If I use a larger buffer size, the sound changes pitch.
My earlier comments about the buffer size may apply here. It seems to me
that you should ensure that you are making enough calls to
QueueSoundBytes -- or more particular, that the queue that the sound system
is sufficiently full when your DMA request comes in. If it's not full, then
you spend time filling it up, and your DMA may stutter (drop out). This
could be especially evident with small buffers which were not being filled
or with queue code which was perhaps a bit buggy. As to changing pitch
because of a larger buffer size -- I can't see how that can happen, other
than you have a bug in the code which is placing data in the buffer itself.
Both symptoms point to this scenario, actually.
> Any help is appreciated. I can try to provide more info if required.
Hard to diagnose this sort of problem when it's not my field of expertise.
Hope my comments may help in some way.
Cheers
A
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
