We can share our rpmsg based topology implementation as reference which:
1.About 2500 lines(much less than SOF)
2.Support pcm and compress playback/capture
3.No any vendor dependence(thanks for rpmsg/remoteproc)
Sure. Where's the code? What's the license?
The code is base on 4.19 kernel, I could upstream the code basing on
the latest kernel in the next couple days for reference.
the license is GPL, of course.
I'll be looking forward to the code. My turn to provide comments :-)
Most of the SOF code is really in hardware-specific .ops callbacks and
topology handling, the generic IPC layer is only ~800 lines of code.
rpmsg would allow for easier portability but a significant reduction of
the code size is unlikely.
The reduce come from:
1.Move firmware load and dsp start/stop to remoteproc layer.
2.Move IPC buffer/mailbox to rpmsg layer.
You are not going to see a lot of code reduction here, at the end of the
day most of the code comes from hardware-specific register access...
3.Reuse ASoC topology parser to generate the audio graph.
4.Reuse ASoC DAMP to control the graph node state change(run/stop/pause/resume).
5.Use the general machine driver glue all individual components
the last 3 points are already how SOF works, wondering if there is a
misunderstanding... We are using topology/DAPM directly without any
reinvention or duplication, as measured by the multiple fixes we
provided to the frameworks in the last few weeks. Also when
dedicated/custom topology tokens are needed, you still need code to deal
with them and send the relevant configuration to firmware, whatever the
transport format might be.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel