In Punix I've written my own interrupt handler for Int 5 to produce audio over the link port, and it seems to make sound just fine except that it
"stutters" fairly rapidly and constantly in TiEmu. I would estimate that it stutters at about 4 times per second. I'm only testing this in TiEmu
because I don't want to brick my real calculator (and frankly because I haven't seen it for about two years now
). I've adjusted playback
parameters (eg, rate of the Int 5 timer, ranging from 1024 Hz to the maximum of 8192 Hz), but nothing seems to affect the stutter speed.
My question is: is this just a limitation of TiEmu itself, perhaps because it runs slightly out of sync with the computer's audio output? Or do you think the problem is probably in my code? I can't find any bottlenecks in my code that would limit how fast it can output audio, especially if the Int 5 timer runs at a slow rate like 1024 Hz (requiring the generation of only 256 bytes per second--4 samples per byte for stereo audio). Should I be concerned with this?
For the record, the working code is in revision 110 at https://punix.svn.sourcef...net/svnroot/punix/trunk/ (specifically src/sys/sys/dev_audio.c ). If you can manage to compile Punix, you can test it in TiEmu yourself. The system runs a few various tests before it gets to the audio test, but it should be fairly self-evident when it happens. The audio test consists of a single 4-second tone. The audio data for the tone itself originates from userspace in usermain() in sys_proc.c. Let me know if you have any questions.
EDIT: I know this Int 5 handler is not at all optimized (it uses an average of about 30% cpu when it's running!), but even in the worst case, when it has to get a new byte from the audio queue, it runs in less than 60% of the time between timer interrupts at the maximum 8192 Hz (about 800 clock cycles). However, this worst case occurs 2048 times per second, so it's not likely to be the cause of the stuttering.
EDIT2: In Punix, the diamond key is the Ctrl key, and in TiEmu you can even press the diamond key by pressing Ctrl! So you can type Ctrl-D with Diamond-D. Similarly, 2nd is the Alt key in Punix, which also matches TiEmu's mapping. How nice. Also, I added tests for the left, right, and center (both) speakers in revision 111. It still stutters though...
My question is: is this just a limitation of TiEmu itself, perhaps because it runs slightly out of sync with the computer's audio output? Or do you think the problem is probably in my code? I can't find any bottlenecks in my code that would limit how fast it can output audio, especially if the Int 5 timer runs at a slow rate like 1024 Hz (requiring the generation of only 256 bytes per second--4 samples per byte for stereo audio). Should I be concerned with this?
For the record, the working code is in revision 110 at https://punix.svn.sourcef...net/svnroot/punix/trunk/ (specifically src/sys/sys/dev_audio.c ). If you can manage to compile Punix, you can test it in TiEmu yourself. The system runs a few various tests before it gets to the audio test, but it should be fairly self-evident when it happens. The audio test consists of a single 4-second tone. The audio data for the tone itself originates from userspace in usermain() in sys_proc.c. Let me know if you have any questions.
EDIT: I know this Int 5 handler is not at all optimized (it uses an average of about 30% cpu when it's running!), but even in the worst case, when it has to get a new byte from the audio queue, it runs in less than 60% of the time between timer interrupts at the maximum 8192 Hz (about 800 clock cycles). However, this worst case occurs 2048 times per second, so it's not likely to be the cause of the stuttering.
EDIT2: In Punix, the diamond key is the Ctrl key, and in TiEmu you can even press the diamond key by pressing Ctrl! So you can type Ctrl-D with Diamond-D. Similarly, 2nd is the Alt key in Punix, which also matches TiEmu's mapping. How nice. Also, I added tests for the left, right, and center (both) speakers in revision 111. It still stutters though...
