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. > The one problem here is the floppy controller. At ED data rates, the byte > rate is 125kB/s, which means the 16 byte FIFO would exhaust in 128uS, > corresponding to a data rate of 7812.5Hz. 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 ;-) > I think you should use the garbage in - garbage out principle here, the > best you could do is having a minimum FIFO depth before you go into a loop > buffer. Probably the best way to do it, true. > If the app is not quick enough, it will loop back into old samples - > and produce dreadful noise. But if the app is not quick enough, > there is hardly any way to avoid that in teh first place! Well, on Q40 this is no problem because when its software FIFO is empty the current output value is just held, i.e. if the software is slightly slower there's a decrease in frequency but depending on how much difference there is it might not be noticeable. The equivalent would be to always fill the whole ring buffer up with the last written value to maintain the output level. Not an idea I really like. > 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. > 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 ;-) > The software resampling is even worse, but usually not as bad as > the cheap sound chips :-) Anyone involved in audio will tell you that > resampling is no easy matter. No need to tell me that... > As someone involved in audio electronics, my advice would be to run the > system at it's default rate, whatever it is (hopefully 48k). IIRC the > resolution of the Q40/60 is 8 bits and as bad as the rate conversion may > be, essentially what you will be doing is putting the 8 bits of a sample > into the MSB of a 16 bit sample, before it gets converted. There are 8 bits > of LSB for the resample algorithm to 'muddle up' before it spoils the > original sample. The only problem is if the conversion produces harmonics > with some order to them. You can avoid this by dithering the 8-bit sampel > into 16 bits before giving it over to directsound (contact me off list for > ideas on how to do this). The whole idea behind the resampling being rather > primitive, is that most sound chips have effectively 12-13 bits of > resolution anyway. OK, I might have a look at the details when I again play around with that whole sound stuff. Personal problems and a nice commission for designing some industrial software make it hard to spent much time on it right now. > As long as the device is exclusive - or at least semi-exclusive, it > should not be a huge problem, I think. Right, probably not. Just measured that a simple device can have more than 1MB/s of throughput on my PC, so that should be ok. > 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. >> I strongly discourage any messing around with the _PAL >> palette. If Jim needs an own palette for icon drawing then there's no >> problem at all to implement this internally and use 24bit draw calls >> for it. > Realistically, how many programs rely on the asignemnts in the _PAL? None I know of. Anway the palette is only something one needs on palette based systems. All else can simply use the true colour definition and don't need to bother with the palette. > Ah, the 'since the mountain won't come to Muhammed, Mugammed has to go to > the mountain' approach... (an idiom that came into Croatian via Bosnia, via > Turkey... 500 years ago...) In Germany we know it, too, though we abstract "Muhammed" to "prophet" ;-) > 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). Marcel
