I"m using the RT685 EVK and am trying to export PCM16 data from the HiFi4. I have the following line:
awe_audioExportSamples(&g_AWEInstance, pIPCBufferOut, STRIDE1, CHANNEL2, Sample16bit);
This causes the DSP to go catatonic and is unresponsive via the IPC message channel. If I instead select Sample32bit then everything works fine. Is this a bug or unsupported feature? Lacking the ability to export Sample16bit, is there a function to convert PCM32 to PCM16 ?
9:26am
For the default BSP for the RT685EVK the IPC buffers are defined to be 32-bit samples. This is because this IPC is used to transport samples between the M33 and the HIFI4 cores for input to AWD signal processing models. AWDs can only operate on 32-bit samples typically in Q31 fract32 format.
12:41pm
In my case I was hoping to avoid the extra trip from the HiFi4 core output back to M33 just so I could then call awe_audioExportSamples on M33 to get Sample16bit data for a codec. This does involve 16 bit IPC for this data but the AWD processing is still 32 bit. If the HiFi4 cannot generate 16 bit data then I guess I have no choice but to add the extra no-op processing.
If I keep the 32 bit IPC is there a utility method on the M33 library to convert to 16 bit without going back in and out of AWD?
1:36pm
IPC stands for InterProcessCommunication. What you are talking about is directly accessing the 16-bit audio samples coming from various audio devices. Our RT685EVK BSP uses the M33 processor to acquire 16-bit audio samples from 8 microphones, 2 analog input channels, and 2 USB playback channels. This data is then converted to 32-bit fract32 samples and inserted in our AudioWeaver buffers on the M33. BTW, we are running AWE signal processing on both the M33 and the HIFI4 processor. The signal processing logic on the M33 processes the input samples and generates output samples. We define some M33 output channels to be IPC channels so that we can send them from the M33 processor to the HIFI4 processor. Because this IPC traffic is from/to the signal processing AWD running on the M33 connected from/to the signal processing AWD running on the HIFI4 it is in the native format used by the input and output pins of our AWDs (32-bit Q31 fract32 data).
I believe what you are attempting to do is get the audio samples directly to the HIFI4 running AWD model without having those samples first be processed by the M33 AWD model. If you look at the Audio driver code you will see buffers defined that contain the 16-bit audio samples from the audio devices. If these buffers are in a shared memory space then you can make calls to import the data directly to the Hifi4 like this call:
awe_audioImportSamples(&g_AWEInstance, &CODECBufferIn[nCODECInReadNdx], STRIDE2, CHANNEL1, Sample16bit);
To work the CODECBuffer would have to be in shared memory space.
Since the DMA complete interrupt on the M33 signals the HiFi4 Audio handler the signaling is coordinated such that the HiFi4 can directly work with these samples in exactly te same way the M3 is doing.