[Sound-open-firmware] Static pipeline and dsp only use case
Hi Liam,
We have now basic support for our i.MX8 boards in Qemu.
Do you know if we can continue development/testing having only the DSP side?
So far none of the i.MX8 have qemu support.
Looking at src/schedule/task.c I noticed that we can create a static pipeline but how do we trigger processing?
Our goal for qemu right now is to complete the DSP part and validate some processing algorithms.
Thanks for your help!
On Wed, 2020-03-18 at 10:08 +0000, Daniel Baluta wrote:
Hi Liam,
We have now basic support for our i.MX8 boards in Qemu.
Do you know if we can continue development/testing having only the DSP side?
Yes you could, the host side of qemu is really useful for integration with the driver (and driver is mature now). You could hard code your unit tests in the init sequence if needed.
If you are working on processing algos then I would recommend the testbench, sinec it can be all debugged on host (qemu is slow and does not support xtensa SIMD).
So far none of the i.MX8 have qemu support.
Looking at src/schedule/task.c I noticed that we can create a static pipeline but how do we trigger processing?
The fuzzer could be used to load a pipeline, obviously you would not want it to mangle the IPC in this case.
Our goal for qemu right now is to complete the DSP part and validate some processing algorithms.
Best to validate any processing algos that use HiFi 2,3,4 on teh DSP HW after you are happy with infrastructure on qemu and testbench.
Liam
Thanks for your help!
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Wed, Mar 18, 2020 at 10:38 PM Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Wed, 2020-03-18 at 10:08 +0000, Daniel Baluta wrote:
Hi Liam,
We have now basic support for our i.MX8 boards in Qemu.
Do you know if we can continue development/testing having only the DSP side?
Yes you could, the host side of qemu is really useful for integration with the driver (and driver is mature now). You could hard code your unit tests in the init sequence if needed.
If you are working on processing algos then I would recommend the testbench, sinec it can be all debugged on host (qemu is slow and does not support xtensa SIMD).
So far none of the i.MX8 have qemu support.
Looking at src/schedule/task.c I noticed that we can create a static pipeline but how do we trigger processing?
The fuzzer could be used to load a pipeline, obviously you would not want it to mangle the IPC in this case.
Thanks, the fuzzer like interface/utility is what we are looking for.
Our goal for qemu right now is to complete the DSP part and validate some processing algorithms.
Best to validate any processing algos that use HiFi 2,3,4 on teh DSP HW after you are happy with infrastructure on qemu and testbench.
participants (3)
-
Daniel Baluta -
Daniel Baluta -
Liam Girdwood