On April 18, 2004 05:28 pm, John Saeger wrote:
> On Sun, 2004-04-18 at 05:43, Stephen Anthony wrote:
> > OK, I update the TIA registers with 'Update_tia_sound' whenever
> > they change. Then, once per frame, I make sure the internal queue
> > is full by using 'Tia_process' with the appropriate amount of data.
> > Finally, during the SDL audio callback, it reads out of the queue
> > and plays it.
>
> This is O.K. in principle. By only putting out sound once per frame
> you are less responsive to changes in the tia registers though.
I did have the sound queue being updated per scanline, but it made no
difference in sound. That alone proves that there's something I'm not
taking into account.
> > Now, after looking at your tiasnd.asm, soundq.asm, and tialine.asm,
> > that seems to be what you do.
>
> Appearances can be deceiving. I don't remember the details, but what
> we do on a frame by frame basis with sound depends on how the game is
> being synchronized.
I figured as much. As I mentioned above, there's something that's not
being done. And it sort of makes sense, because there's actually no
synchronization at all. If I make the buffers small enough, then it
sounds as if everything is fine. But that's not a solution, only a
fluke.
> > But it only works if the fragment buffer is
> > 512 bytes. Any larger than that, and the sound goes off. Since
> > you use a frag size of 1536 bytes (or more), I can't figure out
> > what's going on.
>
> If you are doing anything substantial during the callback routine
> like copying a buffer, this may be causing problems. Forgive me if
> my memory is bad, I haven't looked at the code for nearly two years,
> but I think we just pass a buffer pointer and a size during the
> callback routine. I think of the callback routine as being like an
> interrupt handler, and it's not a good idea to spend a lot of time in
> an interrupt handler.
I do some mixing so that I can change the volume. I'll try without the
mixing and see what happens. But I don't think that's the problem.
> > Also, if I initialize the TIA sound registers with a sample rate of
> > anything other than 31400, again the sound goes off. But according
> > to the comments from Ron Fries, that shouldn't happen. So either
> > I'm reading the comments incorrectly, or something is screwy in the
> > TIA sound routines.
>
> I don't know about this. But for us, the Ron Fries code basically
> bit the dust a long time ago. If nothing else, our version is
> currently all in asm. But by now, our concept of things is different
> than how he thought about things. We think in bytes, he thinks in
> buffers. We do no sample rate conversions. Thats up to hardware or
> SDL. But I leave in the comments because we did start with it.
Yes, I've known ever since I started seriously working on Stella (a few
years ago) that the TIA sound code would have to be rewritten. I just
put it off because (a) I don't know much about sound programming, and
(b) I absolutely hate it.
> Actually I was just kidding about not looking at Stella since version
> 0.2. I ran 0.7 on DOS quite a bit back in the early days, and I ran
> a version of CyberStella when I was working on the Windows port.
> CyberStella has some bugs in the Direct-X stuff but the sound wasn't
> that bad. If it were me, I might have just gone ahead and fixed the
> bugs, because by having direct access to Direct-X, I think it's
> possible to do sound with much lower latency. I've never liked the
The problem is that we have only one developer ATM (me), and I was
splitting my time between adding features to Cyberstella, the DirectX
code, the SDL and X11 ports for Linux, the DOS port, and KStella.
Obviously, I couldn't do it all. And since I'm a lot more proficient
in SDL than DirectX, the choice was easy. And though having the Linux
port working was/is my biggest priority, I didn't want to leave out
Windows users. So given the choice of fully abandoning the DirectX
port, or porting the SDL version to Windows, I chose the latter.
> fact that in Windows I need such a big buffer to keep things running
> smoothly. I don't like the lag. I even thought about *borrowing*
> some code from CyberStella to get things running under Windows. But
> for me, it looked easier to do SDL from scratch than to move the
> massive amount of Direct-X code. And there is such a thing as *good
> enough* I guess. Plus there's the portability thing. But SDL is just
> a layer trying to make things that may be very different underneath
> look the same. I guess I'm not too surprised that things work a
> little differently on the different operating systems.
Actually, I only need a big buffer in Windows. In Linux, I can specify
a fragment size of 256 bytes and buffer/queue size of 1024 bytes and
everything sounds fine (with kernel 2.6 and low-latency enabled).
Windows just can't keep up.
> So... Yeah, if you want to add z26 support to KStella, that would be
> great, if it's not too much work, but there will probably be other
> front ends as well. Choice is good. Someday we might build
> something in, but that's not anywhere near the top of our list.
Obviously this isn't at the top of my list ATM either. First thing
would be to get the sound working and get a new release done. And I'd
still like to add support for some more illegal opcodes, cartridge
types, etc. And of course, add the features (like an in-game GUI) that
I really signed on for in the first place ...
Steve
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
