Jepael wrote:A latch is not needed on a plain old regular "Covox", because the LPT port data pins are already latched. Therefore if you do have two LPT ports, it's easier to have two Covoxes for stereo output.
Yes, but are they latched in a way that we want for a Covox? I mean, the use-case for LPT is to only latch the data pins as long as it takes for the data to transfer.
But for a Covox, we are not actually transferring data. We are feeding the data signals directly into a DAC.
So I have this 'region of uncertainty'...
What happens when you send a new command to the LPT? Will it retain the latched values up to the moment that the new data is latched (the behaviour we want)? Or will it drop the current values immediately, and how long will it take for the new data to arrive? There could be minuscule glitching involved here.
Jepael wrote:But as always, simply using a proper DAC instead of resistor ladder might be better anyway so buffer is not needed.
Yes, I suppose a DAC IC would already have some kind of latch/buffer internally, and also 'cleans up' the signal? Because it is safe to assume that it sees its input strictly as 'data', and not as an audio-quality conditioned 'analog' signal?
It might also take care of the 'transition' mentioned above, because it may only read a new byte from the input based on some kind of clock or other signal. So 'invalid' input while there is no signal for 'new data' would get ignored.
Jepael wrote:But the fact is that 8-bit audio with some timing jitter is not that great anyway, so the random 1% resistors are just as good.
Yup, so a FIFO-based solution like the Disney Sound Source would be even more interesting. You remove the timing jitter from the input that way.
I wonder if there's a way to make it compatible with Covox. DSS was fixed at 7 kHz... Covox can be any sample rate. I guess it would be difficult to sample the strobe signal to get an approximate sampling rate. I mean, doing that is one part of the job (you can average it over a given period of time). But then you'd have to be able to generate a reliable clock signal at arbitrary speed. I think that may be the real problem.
Perhaps with a PIT-like circuit? From a clock of 1.19 MHz you can divide reasonably accurately to a wide range of clockspeeds, good enough for sample playback anyway.
Yea, that might actually work... You'd need to have a circuit that counts and averages strobe pulses at the input, and that 'smoothed out' count has to be translated to a counter value and fed to the PIT, which generates pulses for when to output a new byte to the DAC.
I don't know how difficult that would be in discrete logic, but being a software-guy, I can see this working with two microcontrollers (you could do it with one, but then you'd need to handle two interrupts: one for the strobes, and one for the PIT interrupts... that would probably cause jitter as well in some cases... although, the rates will never be far apart, so if you get the interrupts to fire in discrete time windows far enough apart, and the microcontroller is fast enough, it may just work... except for extreme cases where the samplerate changes... but that is generally only during init/deinit, and is acceptable).
Overkill probably
