wraggster
March 5th, 2013, 00:33
For the last week I have been working on the Sound Blaster emulation, for both rpix86 and ax86. Last Saturday I had managed to get the simple one-shot DMA digital audio working, and I then spent both Sunday and Monday trying to get the auto-init version working. I used Doom to test that, as it uses a 4096-sample buffer with an IRQ request after every 128 samples. Since it plays audio at 11.1kHz while I mix and play the audio (in both rpix86 and ax86) at 32kHz sample rate, those 128 input samples will create around 370 output samples. As I am playing the audio using two 2048-sample buffers, I needed to split the buffer filling in my audio thread so that the game has time to handle the emulated Sound Blaster IRQ and generate new samples several times during my playing of a single 2048-sample buffer. This was pretty difficult to get working correctly, as the sample creation and playing are both very time-critical functions that need to be scheduled properly to not cause any audio dropouts.
In the end I managed to get the auto-init digital audio working using a system where I generate 256 output samples at a time, and then use usleep() in the audio thread to let the main thread generate new samples that the audio thread will then play after it wakes up from the sleep. I also tested this with both 128 samples and 512 samples instead of the 256 samples, but the first one caused even more severe performance hit to the overall emulation speed, and the latter in turn caused very noticeable intermittent audio dropouts.
On Tuesday I then began working on the ADPCM audio playing routines. To test these I used Duke Nukem 2, which is a nice test bench as it uses all three different ADPCM formats (4-bit, 2-bit and also 2.6-bit). It took me several days to get this working, as I (foolishly, it turned out) based the code on the functions I had created for the old (pre-transfer-system-change) DS2x86. When testing them I realized that the algorithm I used there was seriously incorrect. When adjusting for the sample rate differences while playing ADPCM samples, it is of course NOT correct to interpolate over the original ADPCM-encoded values! I need to decoded the ADPCM samples to a separate buffer first, and only then interpolate over these decoded samples, to not cause additional artifacts to the audio. It took me up to Saturday to get the fixed routines working.
On Saturday I also implemented a system into rpix86 to automatically download 4DOS.COM if it is missing. This will help people not familiar with my DSx86 to get started with rpix86. I can not bundle 4DOS.COM into the rpix86.zip file as I do not have the rights to distribute it. Since 4DOS.COM is freeware I think there is no problem for me to add a download feature for it into rpix86 and ax86, though.
I began my work on rpix86 today by first implementing PC Speaker audio features (which was relatively easy after figuring out the proper frequency conversion value) and then worked on the one remaining SoundBlaster audio feature, direct 8-bit DAC output. I used Jill of the Jungle (which plays direct DAC audio at 6kHz for audio effects) to test this. Currently it sort of works, but the audio quality is very poor and glitchy. Since direct DAC audio is very timing-critical (it uses a timer that generates and IRQ at over 6000 times per second, where each timer IRQ generates just a single audio sample) it is not well suited to a multitasking operating system, I doubt this type of audio will ever sound very good in rpix86 or ax86. Luckily not very many games use that technique.
Today I also worked a bit on my Raspberry Pi Store (http://store.raspberrypi.com/projects/rpix86) page for rpix86, I even tested uploading the software there (it is not yet available for download). I think I will be able to release some sort of a work-in-progress version after I just add some more configuration options and such. Currently rpix86 is hardcoded to show graphics on the HDMI display and play audio using the analog headphone output (which is my current setup). I plan to have command line parameters to show the screen on either HDMI or the analog output, and similarly to play audio either via HDMI or analog output. Then I just need to add some usage info, describe the known problems and missing features, and then rpix86 might be ready for the first release! Could be as soon as by next weekend. :-)
http://rpix86.patrickaalto.com/rblog.html
In the end I managed to get the auto-init digital audio working using a system where I generate 256 output samples at a time, and then use usleep() in the audio thread to let the main thread generate new samples that the audio thread will then play after it wakes up from the sleep. I also tested this with both 128 samples and 512 samples instead of the 256 samples, but the first one caused even more severe performance hit to the overall emulation speed, and the latter in turn caused very noticeable intermittent audio dropouts.
On Tuesday I then began working on the ADPCM audio playing routines. To test these I used Duke Nukem 2, which is a nice test bench as it uses all three different ADPCM formats (4-bit, 2-bit and also 2.6-bit). It took me several days to get this working, as I (foolishly, it turned out) based the code on the functions I had created for the old (pre-transfer-system-change) DS2x86. When testing them I realized that the algorithm I used there was seriously incorrect. When adjusting for the sample rate differences while playing ADPCM samples, it is of course NOT correct to interpolate over the original ADPCM-encoded values! I need to decoded the ADPCM samples to a separate buffer first, and only then interpolate over these decoded samples, to not cause additional artifacts to the audio. It took me up to Saturday to get the fixed routines working.
On Saturday I also implemented a system into rpix86 to automatically download 4DOS.COM if it is missing. This will help people not familiar with my DSx86 to get started with rpix86. I can not bundle 4DOS.COM into the rpix86.zip file as I do not have the rights to distribute it. Since 4DOS.COM is freeware I think there is no problem for me to add a download feature for it into rpix86 and ax86, though.
I began my work on rpix86 today by first implementing PC Speaker audio features (which was relatively easy after figuring out the proper frequency conversion value) and then worked on the one remaining SoundBlaster audio feature, direct 8-bit DAC output. I used Jill of the Jungle (which plays direct DAC audio at 6kHz for audio effects) to test this. Currently it sort of works, but the audio quality is very poor and glitchy. Since direct DAC audio is very timing-critical (it uses a timer that generates and IRQ at over 6000 times per second, where each timer IRQ generates just a single audio sample) it is not well suited to a multitasking operating system, I doubt this type of audio will ever sound very good in rpix86 or ax86. Luckily not very many games use that technique.
Today I also worked a bit on my Raspberry Pi Store (http://store.raspberrypi.com/projects/rpix86) page for rpix86, I even tested uploading the software there (it is not yet available for download). I think I will be able to release some sort of a work-in-progress version after I just add some more configuration options and such. Currently rpix86 is hardcoded to show graphics on the HDMI display and play audio using the analog headphone output (which is my current setup). I plan to have command line parameters to show the screen on either HDMI or the analog output, and similarly to play audio either via HDMI or analog output. Then I just need to add some usage info, describe the known problems and missing features, and then rpix86 might be ready for the first release! Could be as soon as by next weekend. :-)
http://rpix86.patrickaalto.com/rblog.html