> [...] > Just to be more specific: I am only pausing DRQs, which doesn't always > mean pausing DMA, but for single mode it does. Also we are > transferring > not a 1byte/request, but much more (up to 512bytes/request) to reduce > the overhead. This last detail seems to make pausing unavoidable.
OK. On SB-16 DMA *transfers* will pause unless (1) we are dealing with auto-init DMA and the IRQ is acknowledged by an IN from port 0x22e/0x22f, or (2) you setup a new single-cycle or auto-init transaction. I think "MPXPLAY" (MP3 player) screws up if this is not implemented, and I think "X-Com: Terror from the Deep" screws up if configured for SB-Pro but a SB16 is emulated according to the specs above. DRQ is deasserted and no bytes are transferred until the interrupt is acknowledged or a new playback/record command is sent to the DSP (independently of what the app does with the DMAC). > About SB16: it is not emulated anyway, but why pausing is > correct? I assume > that pausing DMA will result in stuttering on the real > hardware. Does not result in stuttering, neither on the real hardware nor in emulation. :) > When we > have an intermediate OSS buffer, it is OK, but is the real > DSP have some > intermediate buffering to allow DMA pauses? Yes. Actually in the "Generic DAC/ADC DMA commands", in the "Command byte", you will see there is a bit field for "FIFO" -- setting it enables internal buffering (mainly there in order to safeguard against the bus being mastered for too long by something other than the DMAC). > And what if the program > doesn't care about ACKing at all? Is this possible? It is possible -- see the "X-Com: Terror from the Deep" case described above. The game's SB-Pro drivers do not care to acknowledge at all -- the SB-16 driver doesn't either. See below for a program that *does* care about ACK'ing. > I assume > that DSP will > still assert DRQ if it is in auto-init mode, and the output > will not be stopped. > That is why when a dos program crashes, real sound card still > produces a > noice forcing to reboot the compter, I suppose. Good point about sound looping when program crashes -- I observed this behaviour on my old SB-Pro (consistent); has anyone observed this on a real SB16? I should point out, though, that even if you do observe this behaviour on a SB16 there is no guarantee that it's a counter-example -- the ISR may dutifully ACK every IRQ (thus the sound would loop on forever), but maybe the ISR does not contain the buffer setup/replenishing/muting logic, in which case if the rest of the program is dead the sound will continue to loop unaltered (e.g. some newer Sierra games with broken drivers will keep on looping the same sound until a new sound is output, even when the emulation implements the "need ACK" behaviour above). I only came about one application that actually *required* DMA to be paused until the IRQ is acknowledged -- I think it was "MPXPLAY" (not too sure about my recollection, though, it's been a long time), or maybe it was Leisure Suit Larry 6? I think it was LSL6 though, because I remember the sounds skipped a lot (did not crash right away, but it *did* freeze after a few transfers, randomly). Problems seem to have disappeared after I implemented the behaviour above. > Maybe that app just uses auto-init and doesn't ACKing? For > this I have a > work-around-the-workaround: if OSS buffer is empty, but the > INT was not > ACKed yet, I am forceing DRQ. Dunno if this works, however, > but the post- > crashing noice is in place:) I think both LSL6 and X-COM:TFTD use auto-init -- once again, I can't recall very well (it's been one year already). In any case, the problem is only relevant during auto-init transfers, since re-requesting a single-cycle transaction resets the DSP's DMA-related state. > Yes, but it is still better (much better) than nothing:) And, > as a bonus, it > allows me to control a modem's transfer speed (sound quality > depends on > the int frequency from serial ports because I use irqtune to > give a higher > priority to serial ports). So, when the sound quality is > good, I know that > modem's connection is broken and I have to reconnect:) > Anyway I am going to by an USB->ISA converter as soon as there will > be a linux drivers available. They promised it within a year. How on earth (or what with) did you manage to fill up your PCI slots? :) One video-card takes up slot 1, let's say a SCSI card takes up slot 2, USB should be built into the mobo, one modem, one network card... that should leave at least one slot empty! :) Is there such a thing as a USB<->ISA "bridge"? It sounds like such a Frankenstein -- imagine all the hacking going behind the scenes needed to trap I/O and translate IRQ's (from actual "made-for-ISA" drivers) into something that can be pushed around on a USB interface. I'd document myself very well before investing in such a thing -- its performance/latency, especially for DMA transfers, may be questionable (you may be better off just to buy an old 486, network it in, and offload all the low overhead services like modem and so on onto it). OK, enough topic-unrelated stuff. ;) BTW, about the Scream Tracker 3 problem that needs DMA to be halted during "disabled speaker" periods -- is that documented somewhere, or is it also an empirical observation? :) I only found it documented as a "SB 1.x" feature, but it was presented as if it were a SB1.x *only* feature -- I wonder if it was inherited by "later" generations (gotta love Creative for publishing their SB specs... *not*). 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
