DMA-Sound support in dosemu
Vlad Romascanu (LMC)
> > terminal-count if DREQ is deasserted, no?
> From manual:
> "The difference between Block and Demand is that once a Block transfer
> is started, it runs until the transfer count reaches zero. DRQ only
> needs to be asserted until -DACK is asserted."
I have the DMAC .pdf at home so I can check more thoroughly later, but
correct me if I'm wrong: you (the SB) can always deassert DRQ and the DMAC
will actually check DRQ when reaching terminal-count, no?
> So I don't think DSP have something to stop it. But also I am not sure
> whether it is possible to use block mode for sound transfers at all:
> how then DSP can control a transfer speed (sampling rate)?
> So, if it is not possible, then pausing DRQ == pausing DMA.
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. I do not know how large their internal buffer is, probably less than
64k :) but still I'd expect a few kB (so it may not be able to buffer an
entire "block" transfer). Of course, all this assuming that pre-SB16 cards
did have buffering (which is not so obvious).
> > Seriously, though -- trackers will want 16-bit stereo sound.
> Is this why FastTracker2 plays twice as slow with my code? How good
> does it work with yours?
Doesn't play at all IIRC. Again, I suspect Windows.
Is it attempting to play stereo by any chance (see mixer command to switch
from mono to stereo and back on SB-Pros)?
> > 16-bit DMA is very easy to implement.
> I don't know exactly how easy it is to implement, but I
> suspect this will
> require an implementation of DMAC cascading/cascade mode, which
> what I don't currently know how it works (probably in need of
> a good specs).
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.
> Because int is mostly an async event. Yes, you can pause DMA and
> safely leave the handler, but how can you know *where* will you be
> after iret? Where is to put an unpause?
No, you pause DMA, do all the time-consuming double-buffer memory xfer, then
resume DMA and IRET. Once the memory xfer is done (i.e. DMA has been
resumed), the ISR doesn't really care about re-entrance anymore unless it
runs out of stack, which is impossible unless your CPU is reeeeeeeeeeeelly
slow or it's doing 10-byte long transfers between IRQs :)
> >> ST3 sets a transfer with disabled speaker.
> >> This produces an interrupt.
> > One moment -- "Disable Speaker" (0xD3) is not supposed to generate
> > IRQs, no?
> I didn't say that. "ST3 *sets a transfer* with disabled
> speaker" is what I
> said. Interrupt is produced by the transfer (when it is
> over), not by the
> disabling speaker, of course.
> > It theoretically only acts as a "mute" (and, according to
> my docs, it
> Maybe. But I have a feeling that when you do a transfer with a speaker
> being disabled, DSP keeps DRQ asserted during the whole transfer,
> ignoring the sampling rate. So it is possible that the
> transfer with the
> disabled speaker is going much faster than with enabled. But this is
> nothing more than my internal feeling:) There is nothing in my docs
> about it.
Sounds like a good argument. The "reasonable" explanation for Disable
Speaker would be, of course, to "mute" the annoying pop that would occur
after a 4-byte transfer (especially since many apps don't even bother to
transfer 4 0-bytes, but transfer 4 random bytes). I would expect the SB to
maintain timing, though, even if the speaker is muted (especially since on
SB16s apparently Disable Speaker does not mute, so you'd expect to hear the
sound, which in terms of backwards compatibility would mean that the timing
*was* right all the time since SB1.x). So I don't really know what to say
-- I can try to test it at some point in the future (my old SB-16 equipped
machine does not have a display and there is no VNC for DOS ;)... I still
have a SB-Pro equipped machine pretty functional, though).
> This is exactly what I have with IPlay (Inertia Player), but
> fortunately
> it is clever enough to not set such a short transfers from within an
> inthandler so no problems with it.
:)
> I wonder if it is possible to figure out under NT is the
> process currently
> inside an inthandler or not?
Big pain. I'be been hacking away at NTVDM.EXE for quite a while. Of
course, all the v86 core is buried deep inside the kernel (and not
NTVDM.EXE). I would have expected the "emulated" machine to be just another
thread, switching between v86 and p-mode depending on whether a real-mode or
a p-mode DOS app was running (would have been great for trapping faults and
doing custom processing on stuff like STI/CLI's), but it doesn't look that
simple. Still hacking, though. :)
> This means that you are doing a smoother transfers, probably you even
> have another thread for DMA?
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? It's been one year
since I peeked at DosEmu, I guess many things have changed in that interval
too. :)
I grab data every T milliseconds, where T self-adjusts between user-define
bounds (default 5 and 15ms).
> But ST3 doesn't use DPMI! Dosemu have a global variable in_dpmi that
> allows to figure out easily are we using dpmi or not. From
> outside dosemu
> you can do a log to find out whether the prog uses DPMI. I
> wonder if it
> is a problem to figure out under NT whether an app uses DPMI
> or not? NT
> is known for a poor logging (and poor DPMI) though:)
Ooops, I must have been too rash there with blaming DPMI. Actually I have a
way of not loading the DPMI host, so I can check that. But I wouldn't be
surprised if it were yet another Windows bug, since a commercial SB emulator
has the exact same trouble with ST3 (and FT2 for that matter).
V.
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Vlad Romascanu (LMC)
> 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) :(