wraggster
September 14th, 2006, 00:40
CraigT (http://speccyds.wordpress.com/)posted this news about his upcoming Spectrum emulator for the DS:
I have discovered a new definition for the word frustration. It goes by the name of a sound ring-buffer.
Driving the sound on the DS is pretty straightforward. Its simply a case of setting up a sound channel and pointing it to a buffer that holds your sound data. This works perfectly for playing pre-defined samples. However, when attempting to stream sound data by creating and playing samples continuously the DS starts struggle. This causes popping and cracking in the sound.
One method to get around this problem is the use of a ‘ring-buffer’. The theory involves creating an empty sample that is played in a continuous loop. The current play position of this empty sample is tracked using a timer. When a new section of sound data needs to be played it is mixed into the empty sample just ahead of the current play posision.
As far as the hardware is concerned, it is just playing one sample over and over again, but it means that it is posible to alter the sample with the new data being streamed in.
The theory doesn’t sound too bad. It is, however, very dependent on timing. If the new sound data is mixed in too slowly, the play position of the buffer will catch up and eventually override the newly mixed data. If the new sound data is mixed in too quickly, the mix position will wrap around the buffer and override the data currently being played.
I have had major problems getting the timing to be perfect. I must have redesigned and wrote the sound code 6 or 7 times over the last few weeks without any real success.
Anyway, on Monday I had a bit of free time so a sat down and rewrote it again from scratch. Its the closest i’ve been so far, and sounds pretty good. The mix position is still running slightly quicker than the play position, but if it runs too far forward I skip a sample until it catches up. This can cause the odd scratch in the sound, but it only appears noticable when playing a fixed tone (using the BASIC beep command for example).
This whole problem does indicate that either the CPU core is running too fast or the sound is running too slow. At the moment I think its good enough to put into the first release and am going to move back to the file browser. Once i’ve cleaned it up a bit I think we are looking good for a release of Version 0.1.
I have discovered a new definition for the word frustration. It goes by the name of a sound ring-buffer.
Driving the sound on the DS is pretty straightforward. Its simply a case of setting up a sound channel and pointing it to a buffer that holds your sound data. This works perfectly for playing pre-defined samples. However, when attempting to stream sound data by creating and playing samples continuously the DS starts struggle. This causes popping and cracking in the sound.
One method to get around this problem is the use of a ‘ring-buffer’. The theory involves creating an empty sample that is played in a continuous loop. The current play position of this empty sample is tracked using a timer. When a new section of sound data needs to be played it is mixed into the empty sample just ahead of the current play posision.
As far as the hardware is concerned, it is just playing one sample over and over again, but it means that it is posible to alter the sample with the new data being streamed in.
The theory doesn’t sound too bad. It is, however, very dependent on timing. If the new sound data is mixed in too slowly, the play position of the buffer will catch up and eventually override the newly mixed data. If the new sound data is mixed in too quickly, the mix position will wrap around the buffer and override the data currently being played.
I have had major problems getting the timing to be perfect. I must have redesigned and wrote the sound code 6 or 7 times over the last few weeks without any real success.
Anyway, on Monday I had a bit of free time so a sat down and rewrote it again from scratch. Its the closest i’ve been so far, and sounds pretty good. The mix position is still running slightly quicker than the play position, but if it runs too far forward I skip a sample until it catches up. This can cause the odd scratch in the sound, but it only appears noticable when playing a fixed tone (using the BASIC beep command for example).
This whole problem does indicate that either the CPU core is running too fast or the sound is running too slow. At the moment I think its good enough to put into the first release and am going to move back to the file browser. Once i’ve cleaned it up a bit I think we are looking good for a release of Version 0.1.