Hi,
Recently I captured data using the TriggeredFileSink while running an AWE model in real-time on my PC. I'm now trying to use the data I captured to recreate the system off-line via Matlab and process.m. From my understanding of AWE, I should theoretically get the same results since I'm running on the same target. One difference to note is that in the real-time simulation I grab the signal a few blocks before it hits the SYS_out pin. The red circle below indicates where the signal is captured:
Is there anything that's done by the Interleave/TypeConversion/SYS_out blocks that might explain this? From my understanding of the Interleave block, it really shouldn't affect the signal traveling through it at all beyond rearranging how they're organized in the AWE model. The TypeConversion and SYS_out might cause some distortion from quantization, but that I'd expect that to be pretty minimal. If this is correct then I need to go back and check the input signals I'm feeding through the system.
Also, is there a way to grab the data on the wires in between each call to process.m? It would be a lot easier to debug and understand the system if I didn't have to write out the signals via a FileSink each time.
Thanks,
Graham
9:13pm
Hello Graham,
If my understanding is correct, you are grabbing the audio signal before the interleave module with the TriggeredFileSink module? If you have 2 separate channels, for instance Left and Right channel, the interleave module takes those audio inputs and produces a single output, where the input signals are interleaved together. In other words the audio signal will most likely be different between your two scenarios. I would suggest you try placing the TriggeredFileSink after the interleave module.
Regarding wire information, in Designer you can view wire info by clicking "View" in the toolbar, and then click/check "Wire Info". In Matlab, you can use the target_profile.m function to view profiling information. For more information on this function, you can refer to section 4.4.5. in our Audio Weaver MATLAB Scripting API guide by clicking "Developer" on the top right menu, and then "Documents" from the drop down menu.
Thanks,
Kevin
10:32am
I should have specified that the signal appearing at both inputs of the interleave block is the same. It's only used as the hardware has two output channels and I wasn't aware of a way to change the number of channels on an output pin. When running process() is there anything that happens to the data at the I/O pins or they just essentially define the parameters for the arguments which process() can take?
Also, is it possible to get the actual audio data on each wire after a call to process()? It would be handy to take a look at the intermediary signals to get a better sense of what's going on within the system.
8:13pm
Hello Graham,
It is possible to change the number of channels in an output pin, but only indirectly. The output pin will have however many channels the wire connected to it provides. If you wanted, you could remove the interleave module, wire directly to the type converter, click the 'propagate changes' button, and your output pin would read 1 channel (2 if you fed it stereo).
Regarding your real time output data type vs Matlab output, I overlooked that you are grabbing data before the 'TypeConvert' module. The TypeConvert module changes the samples from float to fract32, so the values at your marked node and output pin, will not be the same. Furthermore, if you're trying to compare signals running on the Native target (actual C code processing with real time audio), to the offline processing model typically used for regressions (process.m), the processing can differ, because it's different code.
Regarding reading audio data after calls to process(), you can read or write any wire in a layout from Matlab, but it requires some custom Matlab code beyond the scope of the Matlab Scripting API guide.
Thanks,
Kevin
9:58am
Hi Kevin,
Thanks for the insight. What would you recommend as the easiest way to read the intermediate signal values after calls to process()?
Also, I keep getting the following error:
Upon inspecting the output pin, I get the following output:
I've been able to mitigate it with the following code, overwriting the input pin values just in case:
However this seems like a very ham-fisted approach. Is there a way to get these values to be saved into the model itself?
Thanks,
Graham