Hello. "Vlad Romascanu (LMC)" wrote: > you (the SB) can always deassert DRQ and the DMAC > will actually check DRQ when reaching terminal-count, no? 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?
> So even if you are in auto-init, the SB would still be able to "insert" > transfer pauses (until its internal buffer is almost empty) during > auto-init DMA. > Of course, all this assuming that pre-SB16 > cards did have buffering (which is not so obvious). I think (again, only my internal feeling:) that DSP simply asserts DRQ with frequency equal to its sampling rate, so buffering is not necessary (8-bit DMA transfers 1byte/request). That is why I assume that block mode transfers are not possible here - DRQ freq doesn't matter in this case and buffering the entire block is not possible as you already mentioned. > I have a good data-sheet from Intel from the DMAC -- I think I grabbed > it on ALSA (or was it Bochs?) I can also e-mail it to you if you want. This would be nice:) > No, you pause DMA, do all the time-consuming double-buffer memory xfer, > then resume DMA and IRET. But here you are probably talking about auto-init (for DSP), while ST3 uses single-cycle. > Once the memory xfer is done (i.e. DMA has been > resumed), the ISR doesn't really care about re-entrance anymore unless If we are talking about single-cycle (and atleast I am talking about it:) then DMA will not start anyway until you have done everything so what is the use of pausing it? > or it's doing 10-byte long transfers between IRQs :) ... which is exactly what it does:) > I'be been hacking away at NTVDM.EXE for quite a while. Hmm... Do you have a sources for it or whatever?? > Yes, I have another thread for DMA. > But I guess you have the advantage of being notified by the emulated > DMAC whenever data is to be transferred... or are you not? No. Emulated DMAC doesn't control the transfer at all. Transfer function is called ocasionally (on timer tick or on fault) and trying to fill up an OSS buffer. So it is Linux driver who controls the transfer. If there is some free space in linux buffer, I am transferring, if no - I am waiting (actually it is simply a non-blocking write()). > It's been one year > since I peeked at DosEmu, I guess many things have changed in that > interval too. :) The short answer is... No, not at all:( Almost nothing (except for the current devcycle). > 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:) 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 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? - 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
