Following is a discussion of the changes/additions from past audio libraries.
There are 2 types of players in the audio library. One is a sequence player which performs the MIDI sequences, and the other is a sound player which replays the sound effects. In the previous audio library, the application could have any number of players, regardless of types.
In n_audio library, the game application is limited to having 2 sequence players and 1 sound player active (registered in the synthesizer driver) at any one time. Therefore, audio processing is simplified and sped up by changing the process from indirect reference to direct reference.
Past audio libraries used an exponential function for the envelope. This was changed to a linear function in n_audio, thereby minimizing the processing required by the audio driver, and speeding up audio processing.
In the former audio library, the RSP could create the maximum number (160) of sample data at one time. (We will call the unit that the RSP processes at one time (160 samples) "1 sub-frame".) However, as shown in the Example 29-1, the audio command list is split and the RSP cannot create the maximum number (160) of sample data at one time. Therefore, the whole processing rate deteriorates.
Therefore, in n_audio, we set up the minimum unit used by the audio process so that the audio command list is not split. Also, we fixed this minimum unit to the maximum number of sample data that RSP can process at one time.
If the maximum number of sample data is 160 (the same number as past libraries), the envelope change of Example 29-1 is processed as in Example 29-2.
Therefore, the audio command list is not split and processing for the CPU and RSP are sped up.
In this way, we have set the minimum unit for the audio process and fixed this value in n_audio.
When each player is used, the most common playback frequency is 32kHz.
When the playback frequency is 32kHz, the required number of sample data for 1 frame becomes
32000 / 60 = 533.33333 = 533
samples using past libraries. The maximum number of RSP sample data is 160 using past libraries. So, 533 samples are split into 4 sub-frames as illustrated in the Figure 29-2.
In this case, the last sub-frame needs to create only 53 samples.
On the other hand, in n_audio, we fixed the minimum unit of the audio process to the maximum number of sample data that the RSP could process at one time. Therefore, we must set the data number created in 1 frame to a multiple integer of the maximum data number of the RSP in n_audio. If the maximum data number is 160 (which is the same number as past libraries), n_audio must create
160 * 4 = 640
samples for 1 frame, as illustrated in Figure 29-3.
At this moment, the sample data
160 - 53 = 107
is carried over to the next frame as the surplus sample data of this frame. To adjust for this surplus data, you would prepare frames as in Figure 29-4.
If you use Frame A and Frame B as in Figure 29-5, as time passes it is possible to adjust the previous surplus data.
The total output sample data of these 3 frames is
160 * 4 + 160 * 3 + 160 * 3 = 1600
The actual required number of sample data among 3 frames is
533 * 3 = 1599
Thus, with this calculation it becomes possible to adjust the surplus data of the entire application by using the previous 3 frames repeatedly. For example, we can make a table of the time frame, the number of samples, and the number of surplus samples shown in Table 29-1.
At time "160" in the table above, the application uses frame A if following the original order. However, because 1 surplus sample is produced by each frame A - frame B - frame B sequence, it uses frame B at time "160" to use the accumulated surplus samples.
This adjustment for the number of created data must be provided on the application side. Also, Table 29-1 has been created using theoretical data. The actual adjustment for surplus data does not always work exactly as represented here.
In Frame A above, you must create 107 more data than the original required number of sample data for 1 frame. Therefore, the processing time for Frame A increases. Though it depends on each case, it is possible for Frame A only, that the increased processing time due to the required processing data, will exceed the processing time allowed by "n_audio."
This problem is avoided as follows.
The maximum number of sample data that the RSP can process at one time is 178.
(32000 / 60) / 3 = 177.77777 = 178
Using this value, the number of surplus data which is produced at each frame is minimized. However, the maximum number of sample data needs to be a multiple of 8 for convenience of the RSP process. Therefore, we increased the maximum number of sample data from 160 to 184 in n_audio.
At this time, the previous frame A becomes like Figure 29-6.
The number of output data in Frame A becomes:
184 * 3 = 552
Thus, in Frame A:
552 - 533 = 19
surplus samples are produced for 1 frame. To adjust these surplus samples for example, we prepare Frame B like Figure 29-7.
Addtionally, it is possible to adjust the surplus data by combining Frame A and Frame B as time passes like Figure 29-8.
The total of output sample data of these 10 frames is
184 * 3 * 9 + 184 * 2 = 5336
and the actual number of required sample data among 10 frames is
533 * 10 = 5330
Thus, it becomes possible to adjust the surplus data of the whole application by using the 10 frames above repeatedly (see Figure 29-8).
Please refer to the sample program (playseq.naudio) for an example of the method used to adjust surplus sample data. In the sample program, the application decides the frame to use dynamically, so it uses Frame B if the number of surplus sample data becomes the data number for 1 sub-frame (184) or more.
In this way, we changed the maximum number of sample data that the RSP can process at one time from 160 to 184 in n_audio, so that the minimum unit of the audio process is effective at a frequency of 32kHz.