Other Parts Discussed in Thread: CC1312R, , CC3200, TAS5760M, TAS5805M
Hello.
I come back here to share my discoveries about this subject.
I started the issue with the original question and then went to the audio forums to ask for help about the amplifiers with this other thread.
The main problem for me was to be not sure about the capabilities of the various amplifiers, the right way to program the I2S module in CC1310 and if it would be able to fetch the audio, as the verified examples of I2S were only for the CC1312R SDK.
If you take a look into the audio thread, you will see I managed to get my audio to the amplifiers but it was full of glitches. I was pretty sure the problem was related to the amplifiers and the limited capabilities of the CC1310, but when I tested the CC3200 audio booster pack (with a AIC3254 codec inside) with the i2sEcho example and got it running without problems, I was convinced I should be doing something wrong with my code.
The main differences between my code and the i2sEcho example were:
- Buffers: I used 2 buffers of 2kB instead of the 256bytes from the i2sEcho example. I used 2kB because it is the page size of the NAND flash memory I use to store the PCM audio and so it was the easiest way to interface between them. I could only use 2 buffers because of the limited system memory of the CC1310 (the CC1312R would be a better choice, as Clement correctly pointed out), so I build the playing function with 4 I2S transactions that share the buffers: transaction 1 and 3 pointed to the buffer1 and transaction 2 and 4 to the buffer2. While transaction 2 was running I changed the buffer1 contents with new audio from the NAND flash memory and put the transaction 1 to the end of the queue. While transaction 3 was running I changed the buffer2 and put transaction 2 to the end of the queue. While transaction 4 was running I changed buffer1 again and put transaction 3 to the end. And so on.
- The params.fixedBufferLength value: I used the same value as for my buffers size: 2kB. I did this because I saw that the i2sEcho example did it the same way. And in the SimpleLink SDK documentation "Play and Stop" example is stated the following: "fixedBufferLength is the greatest common divisor of all the different buffers". And in the I2S_Params_Struct Reference is stated: "uint16_t I2S_Params_::fixedBufferLength: Number of consecutive bytes of the samples buffers. This field must be set to a value x different from 0. All the data buffers used (both for input and output) must contain N*x bytes (with N an integer verifying N>0)".
The first thing I tried was running my code with a CC1312R LaunchPad: same problems.
The second was lowering the params.fixedBufferLength value to 256 instead if 2048 to match the i2sEcho example: I got much better audio but not totally clear. And with lower sample rates I needed to lower even more the value to 64 and 32. But always the audio was not totally clear.
The third and last one was to keep params.fixedBufferLength value to 256 and remake the playing function to use 256 bytes buffers (emulating the i2sEcho example). Reading the NAND flash memory wasn't so straight forward, but with this buffer size I was able to assign 4 independent buffers: one for each transaction. And now I used 1kB (256 x 4) for buffers instead of 4kB (2kB x 2).
And that was all: it worked like a charm. The AIC3254 and TAS5805M with 44.1kHz audio in 3-wire I2S mode and the TAS5760M with 37.5kHz in 4-wire I2S mode (Clement: Finally I successfully paired CC1310 and TAS5760M ;)
I am not quite sure about what the real problem is. Perhaps limits of the driver to manage big buffers? Perhaps sharing buffers in transactions (although theoretically not changing contents in the executing transaction)? Perhaps using only 2 buffers wasn't enough to maintain the rate of the I2S driver needs?
Hope this help other users with similar needs and same noob level.
Best regards,
Juan Pablo Novo
