On 10/07/02 at 00:41 Marcel Kilgus wrote:
>ZN wrote: >> Yes, but that is for the periodic interrupt only. Once other IO >> interrupts get going, it can get quite hectic - for instance, 16kHz >> for HD floppy access. >Hm, you're sure that's the case on PC hardware? Because then the >internal registers of my processor must be tricking me (the one that >counts interrupts at least)... according to them one can't even tell >whether a floppy disc access is currently in progress: next to no >additional interrupts. Well, there is one interrupt every sector (or even cluster, not sure) when DMA is used for FDC access, vs an interrupt on average every 8-12 bytes if PIO is used. Granted, DMA has advantages, but given a fixed number of hardware DMAs it's rather difficult to have them as a generally available system resource - the same philosophy is true for interrupts on a PC. Because DMA can be so useful, but tends to be so scarce (and if hardware is used, tends to require special connection between peripheral and DMA controller, one per peripheral!), is the reason for the 2nd CPU on GF. Essentially, when a second CPU is fitted, it really only gets the poll, level 7 and first cpu interrupts to deal with, in reality it will probably only deal with the first and very occasionally with the last. This CPU then really runs the OS, the original one, that has all the interrupts generated by IO devices routed to it, then becomes an 'IO CPU' of sorts. Making that into a sort of very intelligent DMA is just the start, but in essence, it completely unburdens the second CPU, much like DMA does. The big difference is, of course, that one may use it to, say, refresh the screen from burried windows, etc, whereas DMA is simply to primitive for this. >> Curiously, the floppy controller also alowes a so called 'tape' >> data rate od 2Mb/s (250kB/s) - what comes after ED? - which makes >> this calculation doubly worse. > >I had some QIC streamer that was attached to the floppy channel. >Didn't get anywhere near 2MB/s though ;-) That would be 2M _bits_. So, 256k bytes /s, but this depends on the tape drive and tape - they have density ratings too. Of course, since many of them can also vary the speed of the tape, one can always use lower speed and lower data rate, to maintain capacity, but slow down the whole thing (this is very often done in compression mode to keep up with the software - and most of it is really from 286 days or before that even). >> Now, you are the master of all things PC, but I have a measurement system >> here that uses it and IIRC the primary data rate of directsound is, >> whenever possible, 48kHz (there are actually good reasons for that, to do >> with sound and picture synch). > >Actually the default DirectSound data rate is (at least according to >"Inside DirectX" from MSPress) 22050Hz, stereo, 8 bit. A quick >experiment confirms this (DX3, NT). This was meant to be somewhat the >least common capabilities. Therefore most applications will try to >alter it, usually to 44100Hz, 16bit. Don't remember having a single >application that uses 48kHz. Yes, I looked it up - obviously a case of mixed up pointers in my memory :-) it is the sound chips that default to 48kHz, including AC97 codecs, software is then used to resample (badly!). >> Most current cards actually resample (badly!) from 44.1 to 48 - I >> know this precisely because I have problems with measurements, >> getting spurious harmonics from the bad conversion process. >That's an AC97 codec then, isn't it? Real sound cards shouldn't do >this ;-) No, it's a common problem. In fact, many much revered cards use a DSP front end (or application speciffic DSP) only to then drive an AC97 CODEC chip as the analog portion. In my case, it's a SB Live (granted, not the greatest, but decent), and it internally works at a fixed 48kHz. It does some fuzzy math to resample from or to 44.1 (of course, they don't call it a cheat, they call it 'proprietary technology', ha ha). To get back on topic: an AD1816 was chosen because AD knows how to do audio AD and DA. They also know how to do ASRC (asynchronous sample rate conversion) and they used to have a really high-spec chip for the PC, but that was a long time ago and it was ISA based. Needless to say, it has been obsoleted and not even the surplus people have it because it used to be high end and expensive. Funnily enough, with the proliferation of home theater and multichannel audio, the number of 'standard' sample rates has become so high that now one can get a decent ASRC chip for about $7 or so. Can't turn back the clock, unfortunately :-( >> Exclusive as the simples implementation - alowing combining of >> multiple streams would add considerable overhead. > >At least that's something QPC could do without much problems if the >device is just a wrapper for a DirectSound buffer. All done >automatically (even different sampling rates), very convenient. Yes, though as I said, it does not really get things right all the time. And it does fuzzy math to make it easyer, it's not as bad if you combine streams at related sample rates, at ones that do not relate by an integer, there are some rather odd effects... Oh, and another thing - it is not a good idea to loop the last sample on FIFO starvation, at least not on audio output. The established standard is to mute the output (clamp to 0), preferably reducing it to 0 within a couple hundred samples rather that abruptly, but abruptly works as well. The reason for this is, DC levels tend to confuse the outputs of Sigma-Delta modulators, unless they are zero or near zero. The audible artifacts after resuming with the next sample are often far worse (and can extend for thousands of samples) if a real DC level (continious non-DC sample) is maintained. Most commercial sound chips do offer a choice (hold or mute on FIFO starve) but mute is the default. Yes, it does sound horrible, but there is really nothing one can do. >> BTW did you limit the size to 128 or 256MB in the end? I'm sure you >> understand why I am asking :-) it is still somewhat unclear wether >> problems with liberated programs happen at addres bit 28 or 29, >> onwards... >QPC's config block is limited to only accept values up to 128, but the >mask I use internally is $FFFFFFF, i.e. enough to provide for 256MB >(can't try it though, not enough memory in my system, not even virtual >one and too lazy to change that fact). Of course, everything not >caught by the mask will be caught by another handler, but that one is >pretty unemployed (just checked). Good... GF is designed around a 128M limit. It would not be too difficult to expand this, up to 1G would be possible if there was no 'high address bit' issue at all. However, since it does involve physically reconnecting address lines, I'd rather know about this beforehand :-) Nasta
