can you get some pin of the board to wiggle with your own software.
and then do that 44khz.
while taking as input whatever hz the wav says.
a bit of fixpoint addressing an array, done.
now i've altered cas2wav i could, in theory, get it to output a very basic binary file i.e. a stream of 1s and 0s, and then get the arduino to alter a pin at either 1200hz, 2400hz, or 4800hz depending on the mode,
mhm wait a minute.
it is the replay lib that can't go below 11025khz.
I heard it can do 20khz.
the whole thing more and more smells like the soundblaster case.
replay at high khz and make a resampler from low hz wav to that khz.
the library can run up to 32khz, but anything above 16khz and you get clicks in the audio due to buffer underrun. It's designed for audio not data, so when you play music through it you don't really notice the clicks, but with the sensitive timing of the data any clicks kill the data stream.
This is why we use 14400, it's the highest sample rate we can use that is still gives us an exact number of data points per cycle.
After 3 weeks of trying to make this work, i think we've exhausted all possibilities with altering the sample rate.
ok maybe it is the right thing for this board.
and now I feel the urge to stress that all the "14400 is better than 9600" was solely about the board. while for replay on PC, 9600hz is better.
The 44khz wav cannot be better because the 9600hz wav contains 100% information.
Whenever I said 9600hz, I was assuming 2400 baud.
The deal is not a hz, the deal is that the wav contains one sample per one pin state.
It looks like a pin timing diagram. I like to give it the nickname "TTL wav".
It is the minimum size wav.
To replay at 3000 baud, write 12000hz into the wav header, done!
The wav size does not change.
Another example for "the deal is not a particular hz figure".
I can see what you're getting at, but it's not going to happen like that without a complete redesign of the circuit, so why continue to argue?
In fact the absolute best way to do it would be to convert the case file (either on the fly or preprocess) into a bit stream and just flip a pin at the right frequency depending on the current bit, but again not going to happen with out a complete redesign so there is no point continually arguing the case and giving us useless comments....
