-
Notifications
You must be signed in to change notification settings - Fork 45
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
[FEATURE] implement sof-test case that override nocodec with nocodec-bt and runs playback tests #1013
Comments
There are some focused exceptions but kernel modules are typically not reloaded from one test to the next in a test suite. So I don't think such a default topology override should belong to any particular test case. I rather think we should add the ability in the existing Then you run any test plan of your choice. |
sof-insert.sh does not necessarily reload all intermediate modules, only top-level ones such as codecs and PCI. We couldn't e.g. add parameters to snd_sof_intel_hda_common. Somehow we have an interesting exception to the rule (maybe due to history), we do have "insert_module snd_sof_pci # ipc_type=1 # sof_pci_debug=1 ...", so that would solve the problem of loading an alternate topology is desired. |
We could dynamically create a one-line file in |
Summarizing a discussion today: this feature is about the convenience and flexibility to override the default topology. |
Is your feature request related to a problem? Please describe.
Implement a test-case where an alternative nocodec topology (in this case for bt-offload) is loaded as part of the test case execution instead of nocodec topology. This allows to test features that are not described in the default nocodec topology and reuse same test content that is used for other topologies.
Describe the solution you'd like
Sof-test case that uses kernel module parameter to load an altenrative topology file, and an existing test case .
Describe alternatives you've considered
Merging BT to existing nocodec topology.
BT requires configuration of alternative sampling rate and formats that are in conflict with typical requirements for nocodec testing.
Additional context
This approach could be used to other features (like smart-amp, wake-on-voice, muxes) that do not depend on specific audio peripherals, but are too complex to integrate to nocodec topology.
cc:
The text was updated successfully, but these errors were encountered: