wraggster
December 18th, 2011, 23:19
via http://dsx86.patrickaalto.com/DSblog.html
Since the last blog post I have focused on getting the SB digitized audio working. That has been much more difficult than I originally thought. First, it took me several days to come up with a data transfer method that might support all the features that the SB digitized audio needs. Then I began implementing the auto-init DMA version as used in Doom. It took me several days to even get any sound out of that system, and the current status is that the audio is full of clicks and pops, and severe distortion.
I think the biggest problem in getting the audio working is the timing issue. Playing audio is very time-critical, the new samples need to be in the ARM7 playing buffer some time before they are actually getting played. I can only transfer new audio data from the MIPS side to the ARM9 side when the graphics are not getting transferred, so that means I can only transfer new audio samples at about 30 times per second. Using a 512-sample FIFO transfer buffer, that would give the maximum sample rate of 15360Hz. Doom actually uses SB TIME_CONSTANT of 0xA6, which corresponds to (1000000 / (256-TIME_CONSTANT)) = 11111Hz. So, during every 1/30 transfer window I should move around 370 samples. My buffer copying works with 128-byte increments, so most of the time the transfer handles 384 samples, and occasionally only 256 samples.
Currently I use the same ring buffer on the NDS side for receiving the data from the MIPS FIFO (by the ARM9 processor), and for filling the audio playing buffer (by the ARM7 processor). I believe the clicks and pops are caused by this sharing of the buffer. The ARM9 does not know the position where the ARM7 is copying data from the buffer, so when the timing of the audio playing differs from the timing of the buffer filling (which will always happen as the ARM and MIPS have different base speeds for their timers), occasionally wrong samples are getting copied to the playing buffer.
I think I need to add a new ring buffer to the ARM9 side, and also attempt to sync the ARM7 and ARM9 buffer accesses so that I avoid accessing the same area of the ring buffer from both processors simultaneously. I am not yet sure how to avoid buffer under- or overflows when the actual audio playing speed differs from the buffer filling speed, and the audio is looping for long periods of time. I might need to do some on-the-fly adjusting of the playing frequency, or some such trickery.
All in all, this is quite a difficult challenge to get working properly. Luckily, I have a two-week Christmas vacation starting tomorrow, so besides the family- and Christmas-related things to do, I should now have more time to work on DS2x86. I still hope to get a version released during this year, although it looks like that version will not yet support all the graphics and audio features that the current DS2x86 does. But we shall see.
Since the last blog post I have focused on getting the SB digitized audio working. That has been much more difficult than I originally thought. First, it took me several days to come up with a data transfer method that might support all the features that the SB digitized audio needs. Then I began implementing the auto-init DMA version as used in Doom. It took me several days to even get any sound out of that system, and the current status is that the audio is full of clicks and pops, and severe distortion.
I think the biggest problem in getting the audio working is the timing issue. Playing audio is very time-critical, the new samples need to be in the ARM7 playing buffer some time before they are actually getting played. I can only transfer new audio data from the MIPS side to the ARM9 side when the graphics are not getting transferred, so that means I can only transfer new audio samples at about 30 times per second. Using a 512-sample FIFO transfer buffer, that would give the maximum sample rate of 15360Hz. Doom actually uses SB TIME_CONSTANT of 0xA6, which corresponds to (1000000 / (256-TIME_CONSTANT)) = 11111Hz. So, during every 1/30 transfer window I should move around 370 samples. My buffer copying works with 128-byte increments, so most of the time the transfer handles 384 samples, and occasionally only 256 samples.
Currently I use the same ring buffer on the NDS side for receiving the data from the MIPS FIFO (by the ARM9 processor), and for filling the audio playing buffer (by the ARM7 processor). I believe the clicks and pops are caused by this sharing of the buffer. The ARM9 does not know the position where the ARM7 is copying data from the buffer, so when the timing of the audio playing differs from the timing of the buffer filling (which will always happen as the ARM and MIPS have different base speeds for their timers), occasionally wrong samples are getting copied to the playing buffer.
I think I need to add a new ring buffer to the ARM9 side, and also attempt to sync the ARM7 and ARM9 buffer accesses so that I avoid accessing the same area of the ring buffer from both processors simultaneously. I am not yet sure how to avoid buffer under- or overflows when the actual audio playing speed differs from the buffer filling speed, and the audio is looping for long periods of time. I might need to do some on-the-fly adjusting of the playing frequency, or some such trickery.
All in all, this is quite a difficult challenge to get working properly. Luckily, I have a two-week Christmas vacation starting tomorrow, so besides the family- and Christmas-related things to do, I should now have more time to work on DS2x86. I still hope to get a version released during this year, although it looks like that version will not yet support all the graphics and audio features that the current DS2x86 does. But we shall see.