-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CTC topology #8840
CTC topology #8840
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eddy1021 I assume this PR will just squash into the main CTC PR ?
fe8cb8f
to
56bcfa2
Compare
@eddy1021 any updates or ETA ? do you think this will land in v2.10 ? |
We are blocked on internal build problems, I wouldnt expect it to be resolved for at least another 2 weeks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
468fc65
to
7a72198
Compare
# | ||
# Where N is the unique instance number for the parent object. | ||
|
||
Class.Widget."ctc" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lgirdwood @ranj063 is there a way to set a min/max channel in widgets? I don't see anything in widget common. Might be useful for validation when pipelines define channels outside the range their components support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding @singalsu too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PCM has channels_min and channels_max but I don't know if it would here. In my experience when channels count can be other than default 2, it's better to list for the instances explicitly the in and out formats with possible channels counts (and all rates if non-48 kHz is possible). There's an arrays combiner than can help when there's many combinations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense but is there a way to define that at the widget level.
E.g. dev A makes comp 1
Dev B makes pipeline with comp 1
Dev B fails to notice restrictions on formats
If format restrictions were part of the widget definition then it would be easy to identify if all widget formats were a superset of the pipelines set of supported formats. If they were a subset then the build would fail. Just a thought on finding bugs before runtime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cujomalainey audio formats are always part of individual widgets. A pipeline does not define a superset of audio formats at all. But its an interesting idea to identify discrepancies in audio formats across widgets within the same pipeline and fail during topology build. Let me give it a thought.
tools/topology/topology2/include/pipelines/cavs/mixout-gain-ctc-dai-copier-playback.conf
Show resolved
Hide resolved
Add topology in development to test CTC. Signed-off-by: Eddy Hsu <eddyhsu@google.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for using the new feature @eddy1021. LGTM
according to #9354 toolchain has been updated, merging this now |
Add topology for Google CTC component