(Please visit the site to view this file)
I am having some difficulty outputting an audio signal on the OMAP-L137 EVM. While the audio output example works ok, when I adapt the program to output data that I have generated it does not appear at the output in the order in which the data was sent with SIO_issue.
Initially I noticed some discontinuities in the data that I was outputting, so I wrote a test program to try to investigate what was happening and got some very strange results. I have attached the code for the program to this post.
The idea of the test program is to output a sequence of (currently 5) square waves with increasing amplitude on one of the audio output channels (zeros are output to the other). If I make the size of the buffers passed to SIO_issue such that they contain the full pattern (ie define BUFLEN as PATTERN_LEN * 2, with the two accounting for the stereo output), this will make every buffer passed to SIO_issue contain the same data and I see the full pattern as expected at the output (well almost, it gets inverted somewhere along the line, but that is not a problem).
The problem is if I make the buffers such a size that they contain only one of the square waves (in which case each buffer passed to SIO_issue should contain different data). Now the output does not appear as expected and appears to indicate that the order of the data is mixed up and that in some cases it does not reach the output at all. In the current configuration of the attached example, the entire sequence is output in reverse order with each wave (which should appear only once per cycle) being repeated twice. Similar results occur with different configurations.
Please note that the attached example has been adapted from the audio sample application which copies audio input to audio output (and seems to work well). Some significant changes made to the program include:
- Removal of the entire RX side of the application.
- The number of buffers for the output is two instead of four. From the SIO_reclaim/SIO_issue documentation, it seems that only two should be necessary, however I have tried with four and still do not get the expected output.
- Smaller buffers. This makes the problem easier to catch on an oscilloscope, however the size of the buffer does not appear to matter.
Note also that I have looked at the sine wave example for the McASP driver. Each output buffer here contains a full sine wave period, so if there is any mix up there will be no difference in the output. Also this example uses DIT while the audio example is TDM and it is not clear if using the McAsp in DIT mode is even compatible with the audio driver. Also, since the audio example works, it seems logical that the buffers are confused in a predictable way that also applies to the input, and that it effectively cancels itself out in the example.
Is there some way to configure the program so that it works as expected, or at least a suitable workaround so that data can be output in the desired order?
Edit: I forgot to mention that I have also made an attempt with the standard streaming model (ie SIO_put), I will post another question with the problems that I had there. Also the following software versions were used:
DSP/BIOS 5.41.03.17
PSP drivers 01.30.01