> Yes (even in auto-init I think, my docs are incomplete > though), but how > to stop block DMA xfer when TC is not yet? I mean I can issue > a "Pause" > command to DSP at any moment, and what DSP can do? Buffer the end > of the block?
Yes, that would be a sensible thing to do (buffer the end of the block) provided that buffering existed on pre-SB16 machines (of which I am not very sure, i.e. I don't think buffering existed). So it would just "lose" data and produce silence/garbage/repeat, depending on the internal implementation of the SB. :) > I think (again, only my internal feeling:) that DSP simply asserts DRQ > with frequency equal to its sampling rate, so buffering is > not necessary I agree with you (at least on pre-SB16 models). Block transfers would not be feasible (I mean you could program the DMAC for block transfer, but pre-SB16 -- and even SB16's, if the block is very large -- would screw up, or maybe even lock up depending on how well they were designed). > > or it's doing 10-byte long transfers between IRQs :) > ... which is exactly what it does:) Oh... :) > > I'be been hacking away at NTVDM.EXE for quite a while. > Hmm... Do you have a sources for it or whatever?? Not quite... but MS was, well, how should I put this, "kind" enough to provide the symbols, he he he... ;) > > I grab data every T milliseconds, where T self-adjusts between > > user-define bounds (default 5 and 15ms). > I would expect this T to actually depend of a sampling rate:) Yes, it partially depends on the sampling rate. Also the module responsible for the output (disk or sound) sends a feedback value that shapes the DMA traffic depending on the data needs (e.g. if the sound buffer is too full then it will tell the DMAC thread to slow down, and if the buffer is below a certain threshold then it will speed up the xfer; this adjustment is made on top of the "ideal" rate which is a function of the sample rate). > And how many data you are transferring at once? > OSS manual recommends to transfer a one full fragment per one write() > call, so I am very limited here... I am ignoring this > recommendation, of > course, but this makes some drivers to work unreliably:( I always round up to 1 or 2 samples, depending on whether it's mono or stereo sound. That's about the only limitation, though. > I wonder if I can steal some OPL code from your emulator? > Does it produce > a digital sound, or it uses a midi capabilities for output? Produces digital sound. Go ahead and steal it, it actually was in turn "stolen" from MAME (GPL'd as well). I may look into making further modifications for OPL3, but that remains to be seen (time is a very sought after commodity). :) You will need to mix the sounds though (DSP+OPL), and moreover you may find it difficult to do in a single-threaded app. (i.e. the end reult may sound weird, with a broken tempo) :( V. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
