-
Notifications
You must be signed in to change notification settings - Fork 235
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
ucm2: Intel: avs: Add UCM files for HDA configuration #499
base: master
Are you sure you want to change the base?
ucm2: Intel: avs: Add UCM files for HDA configuration #499
Conversation
Add configs for devices using HDA codec. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
As discussed in https://bugzilla.kernel.org/show_bug.cgi?id=219654 I'm trying to enable HDA configuration for users. I'm using UCMs present in this PR. On device I'm testing at:
Controls:
UCM dump:
With spa-acp-tool:
Problem is that even though it seems that UCM was loaded, it doesn't seem to be usable from GUI, only "Dummy output" is present in settings. |
Add |
Looking at previous log I'm starting to suspect that spa-acp-tool log
|
I forgot that EDIT: And you can select card with |
Yes and call list-verbose from command line, I was just confused by it not working in interactive mode (I tried both New part of output attached, the rest is as in previous log:
I assume that: There is also:
why does it try to open device '0', when in |
Thanks.
You can ignore this warning.
It's the real error. As you can see, UCM config specifies that the playback is on device 0:
The |
Yeah, the device IDs not starting from '0' were one of the things that always bothered me a bit, but I considered them just a cosmetic nuisance not something that may cause problems. Seems like in soc_new_pcm_runtime() regardless of whether we create struct snd_soc_pcm_runtime for BE or FE the id is being raised by 1. As ASoC creates BEs first it ends up creating FEs starting from id that is not 0. With simple patch like:
it seems to create devices with IDs starting from 0. And the error also seems to be gone when loading UCMs. However there are sadly arguments against this approach:
Probably more backward compatible solution will be to add Device parameter like one HDMI has to HDA. Do you think, I should try proceeding with kernel patch or is it better to just improve UCM file to accept parameter? |
Add configs for devices using HDA codec.