| Message ID | 20180808090543.15181-1-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,01/13] conf/ucm: bytcr-rt5645: Use the generic bytcr/PlatformEnableSeq.conf | expand |
Dne 8.8.2018 v 11:05 Hans de Goede napsal(a): > Use the generic Intel SSP bytcr/PlatformEnableSeq.conf file, it is > identical to all the cset statements this commit removes. > > Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > src/conf/ucm/chtrt5645/HiFi.conf | 116 +------------------------------ > 1 file changed, 1 insertion(+), 115 deletions(-) I applied all 13 patches to the alsa-lib git tree. Thanks. Jaroslav
alsaucm -c chtrt5645 set _verb HiFi set _enadev Speaker ALSA lib conf.c:823:(get_char_skip_comments) Cannot access file bytcr/PlatformEnableSeq.conf ALSA lib conf.c:1877:(snd_config_load1) _toplevel_:17:18:Unexpected char ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/ASUSTeKCOMPUTERINC.-X205TA-1.0-X205TA/ASUSTeKCOMPUTERINC.-X205TA-1.0-X205TA.conf ALSA lib parser.c:1427:(load_master_config) error: could not parse configuration for card ASUSTeKCOMPUTERINC.-X205TA-1.0-X205TA ALSA lib conf.c:823:(get_char_skip_comments) Cannot access file bytcr/PlatformEnableSeq.conf ALSA lib conf.c:1877:(snd_config_load1) _toplevel_:17:18:Unexpected char ALSA lib utils.c:75:(uc_mgr_config_load) could not load configuration file /usr/share/alsa/ucm/chtrt5645/HiFi.conf ALSA lib parser.c:1101:(parse_verb_file) error: failed to open verb file /usr/share/alsa/ucm/chtrt5645/HiFi.conf : -2 ALSA lib main.c:946:(snd_use_case_mgr_open) error: failed to import chtrt5645 use case configuration -22 alsaucm: error failed to open sound card chtrt5645: Invalid argument
On Sun, 25 Nov 2018 12:11:29 +0100, youling257 wrote: > > alsaucm -c chtrt5645 set _verb HiFi set _enadev Speaker .... Could you explain what you want? thanks, Takashi
what you want me explain anyting ? alsaucm -c xxxx set _verb HiFi set _enadev Speaker https://www.systutorials.com/docs/linux/man/1-alsaucm/ I used alsa-utils 1.17 and alsa-lib 1.17. Takashi Iwai <tiwai@suse.de> 于 2018年11月26日周一 下午4:25写道： > On Sun, 25 Nov 2018 12:11:29 +0100, > youling257 wrote: > > > > alsaucm -c chtrt5645 set _verb HiFi set _enadev Speaker > .... > > Could you explain what you want? > > > thanks, > > Takashi >
what you want me explain anyting ? alsaucm -c xxxx set _verb HiFi set _enadev Speaker https://www.systutorials.com/docs/linux/man/1-alsaucm/ I used alsa-utils 1.17 and alsa-lib 1.17.
On Mon, 26 Nov 2018 10:49:11 +0100, youling257 wrote: > > what you want me explain anyting ? Anything more useful to understand the situation *and* your demand. The error messages (at least some of them) are known issues and I already posted the problem on alsa-devel ML. The fix should be easy but I'd like to get consensus beforehand. Other than that, I'm really not sure what you want in the previous posts; it were merely a dump from some command invocation, and that's all what you wrote. If you want us to fix something, *please* write / report more explicitly. Only pasting an error message isn't better than some bot. > alsaucm -c xxxx set _verb HiFi set _enadev Speaker > https://www.systutorials.com/docs/linux/man/1-alsaucm/ > > I used alsa-utils 1.17 and alsa-lib 1.17. Thanks, that's at least some more background for better understanding. Currently alsaucm is so-to-say broken. Just avoid using it until it gets fixed. PA shouldn't hit the problem, it seems almost only alsaucm. thanks, Takashi
Hi, On 26-11-18 11:07, Takashi Iwai wrote: > The error messages (at least some of them) are known issues and I > already posted the problem on alsa-devel ML. The fix should be easy > but I'd like to get consensus beforehand. Ah I missed that mail as I'm not subscribed to alsa-devel. Since my changes are the cause of this alsaucm command problem, let me reply here: > some of the recently added UCM profiles are the files to be included > by others, and they are not card targets. Unfortunately alsaucm > doesn't know about it, and it aborts with error, e.g. > > ==== > % alsaucm > ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/bytcr/bytcr.conf > ALSA lib parser.c:1427:(load_master_config) error: could not parse configuration for card bytcr > alsaucm: unable to obtain card list: No such file or directory > ==== > > The similar error is found in nau8824, rt5640 and rt5651. After > putting a placeholder card config file (e.g. bytcr.conf), the error is > gone. But certainly we don't want to allow user to choose this as the > proper card. > > So, I guess we need to put some flag to each such directory indicating > that it's no card config. For example, putting > /usr/share/alsa/ucm/bytcr/.nocard file or such... > > Not sure whether it's wise to have a file starting with dot, though. > Maybe clearer to be "nocard" or any other visible one? All the HiFi.conf files using the "include" snippets I added to avoid copy and pasting a lot, already need to have this at the top for this to work: <searchdir:ucm> So it might be best to move all the dirs holding include files rather then proper card configs from /usr/share/alsa/ucm to /usr/share/alsa/ucm-includes and then change the searchdir part of the configs using these to: <searchdir:ucm-includes> Regards, Hans
On Mon, 26 Nov 2018 14:40:48 +0100, Hans de Goede wrote: > > > some of the recently added UCM profiles are the files to be included > > by others, and they are not card targets. Unfortunately alsaucm > > doesn't know about it, and it aborts with error, e.g. > > > > ==== > > % alsaucm > > ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/bytcr/bytcr.conf > > ALSA lib parser.c:1427:(load_master_config) error: could not parse configuration for card bytcr > > alsaucm: unable to obtain card list: No such file or directory > > ==== > > > > The similar error is found in nau8824, rt5640 and rt5651. After > > putting a placeholder card config file (e.g. bytcr.conf), the error is > > gone. But certainly we don't want to allow user to choose this as the > > proper card. > > > > So, I guess we need to put some flag to each such directory indicating > > that it's no card config. For example, putting > > /usr/share/alsa/ucm/bytcr/.nocard file or such... > > > > Not sure whether it's wise to have a file starting with dot, though. > > Maybe clearer to be "nocard" or any other visible one? > > All the HiFi.conf files using the "include" snippets I added to avoid > copy and pasting a lot, already need to have this at the top for > this to work: > > <searchdir:ucm> > > So it might be best to move all the dirs holding include files rather > then proper card configs from /usr/share/alsa/ucm to > /usr/share/alsa/ucm-includes and then change the searchdir part of > the configs using these to: > > <searchdir:ucm-includes> This sounds like a good solution, indeed. Care to submit a fix patch? I'll apply it unless anyone objects. Thanks! Takashi
Dne 26.11.2018 v 15:18 Takashi Iwai napsal(a): > On Mon, 26 Nov 2018 14:40:48 +0100, > Hans de Goede wrote: >> >>> some of the recently added UCM profiles are the files to be included >>> by others, and they are not card targets. Unfortunately alsaucm >>> doesn't know about it, and it aborts with error, e.g. >>> >>> ==== >>> % alsaucm >>> ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/bytcr/bytcr.conf >>> ALSA lib parser.c:1427:(load_master_config) error: could not parse configuration for card bytcr >>> alsaucm: unable to obtain card list: No such file or directory >>> ==== >>> >>> The similar error is found in nau8824, rt5640 and rt5651. After >>> putting a placeholder card config file (e.g. bytcr.conf), the error is >>> gone. But certainly we don't want to allow user to choose this as the >>> proper card. >>> >>> So, I guess we need to put some flag to each such directory indicating >>> that it's no card config. For example, putting >>> /usr/share/alsa/ucm/bytcr/.nocard file or such... >>> >>> Not sure whether it's wise to have a file starting with dot, though. >>> Maybe clearer to be "nocard" or any other visible one? >> >> All the HiFi.conf files using the "include" snippets I added to avoid >> copy and pasting a lot, already need to have this at the top for >> this to work: >> >> <searchdir:ucm> >> >> So it might be best to move all the dirs holding include files rather >> then proper card configs from /usr/share/alsa/ucm to >> /usr/share/alsa/ucm-includes and then change the searchdir part of >> the configs using these to: >> >> <searchdir:ucm-includes> > > This sounds like a good solution, indeed. > Care to submit a fix patch? I'll apply it unless anyone objects. Yep, it looks like a good idea. Jaroslav
On 11/26/18 9:28 AM, Jaroslav Kysela wrote: > Dne 26.11.2018 v 15:18 Takashi Iwai napsal(a): >> On Mon, 26 Nov 2018 14:40:48 +0100, >> Hans de Goede wrote: >>>> some of the recently added UCM profiles are the files to be included >>>> by others, and they are not card targets. Unfortunately alsaucm >>>> doesn't know about it, and it aborts with error, e.g. >>>> >>>> ==== >>>> % alsaucm >>>> ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/bytcr/bytcr.conf >>>> ALSA lib parser.c:1427:(load_master_config) error: could not parse configuration for card bytcr >>>> alsaucm: unable to obtain card list: No such file or directory >>>> ==== >>>> >>>> The similar error is found in nau8824, rt5640 and rt5651. After >>>> putting a placeholder card config file (e.g. bytcr.conf), the error is >>>> gone. But certainly we don't want to allow user to choose this as the >>>> proper card. >>>> >>>> So, I guess we need to put some flag to each such directory indicating >>>> that it's no card config. For example, putting >>>> /usr/share/alsa/ucm/bytcr/.nocard file or such... >>>> >>>> Not sure whether it's wise to have a file starting with dot, though. >>>> Maybe clearer to be "nocard" or any other visible one? >>> All the HiFi.conf files using the "include" snippets I added to avoid >>> copy and pasting a lot, already need to have this at the top for >>> this to work: >>> >>> <searchdir:ucm> >>> >>> So it might be best to move all the dirs holding include files rather >>> then proper card configs from /usr/share/alsa/ucm to >>> /usr/share/alsa/ucm-includes and then change the searchdir part of >>> the configs using these to: >>> >>> <searchdir:ucm-includes> >> This sounds like a good solution, indeed. >> Care to submit a fix patch? I'll apply it unless anyone objects. > Yep, it looks like a good idea. Makes sense. We may also want to change the error message when the DMI-based configuration is not found, e.g. ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/ASUSTeKCOMPUTERINC.-X205TA-1.0-X205TA/ASUSTeKCOMPUTERINC.-X205TA-1.0-X205TA.conf ALSA lib parser.c:1427:(load_master_config) error: could not parse configuration for card ASUSTeKCOMPUTERINC.-X205TA-1.0-X205TA This is reported as an error even if there is a fallback. I remember losing a couple of hours trying to figure out what was happening when in reality there was no issue. I have two other points I need to sort out - what is the license for those UCM files? I keep getting questions and I don't have the answer. It'd be odd to have then inherit the LGPL license from alsa-lib, it's expected that people will have to do minor modifications left and right and handle a number of derivatives, e.g. because the perceived volume is too low due to some mechanics/acoustics issue and requiring them to share is a bit cumbersome. - how are we going to handle the changes for SOF, we added an "sof-" prefix to make it explicit that the platform/DSP driver side is different, but having a different board name will interfere with search and includes. Thanks -Pierre
On Mon, 26 Nov 2018 18:20:41 +0100, Pierre-Louis Bossart wrote: > > > On 11/26/18 9:28 AM, Jaroslav Kysela wrote: > > Dne 26.11.2018 v 15:18 Takashi Iwai napsal(a): > >> On Mon, 26 Nov 2018 14:40:48 +0100, > >> Hans de Goede wrote: > >>>> some of the recently added UCM profiles are the files to be included > >>>> by others, and they are not card targets. Unfortunately alsaucm > >>>> doesn't know about it, and it aborts with error, e.g. > >>>> > >>>> ==== > >>>> % alsaucm > >>>> ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/bytcr/bytcr.conf > >>>> ALSA lib parser.c:1427:(load_master_config) error: could not parse configuration for card bytcr > >>>> alsaucm: unable to obtain card list: No such file or directory > >>>> ==== > >>>> > >>>> The similar error is found in nau8824, rt5640 and rt5651. After > >>>> putting a placeholder card config file (e.g. bytcr.conf), the error is > >>>> gone. But certainly we don't want to allow user to choose this as the > >>>> proper card. > >>>> > >>>> So, I guess we need to put some flag to each such directory indicating > >>>> that it's no card config. For example, putting > >>>> /usr/share/alsa/ucm/bytcr/.nocard file or such... > >>>> > >>>> Not sure whether it's wise to have a file starting with dot, though. > >>>> Maybe clearer to be "nocard" or any other visible one? > >>> All the HiFi.conf files using the "include" snippets I added to avoid > >>> copy and pasting a lot, already need to have this at the top for > >>> this to work: > >>> > >>> <searchdir:ucm> > >>> > >>> So it might be best to move all the dirs holding include files rather > >>> then proper card configs from /usr/share/alsa/ucm to > >>> /usr/share/alsa/ucm-includes and then change the searchdir part of > >>> the configs using these to: > >>> > >>> <searchdir:ucm-includes> > >> This sounds like a good solution, indeed. > >> Care to submit a fix patch? I'll apply it unless anyone objects. > > Yep, it looks like a good idea. > > Makes sense. OK, I cooked up the patch now. Will submit soon later. > We may also want to change the error message when the DMI-based > configuration is not found, e.g. > > ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration > file > /usr/share/alsa/ucm/ASUSTeKCOMPUTERINC.-X205TA-1.0-X205TA/ASUSTeKCOMPUTERINC.-X205TA-1.0-X205TA.conf > > > ALSA lib parser.c:1427:(load_master_config) error: could not parse > configuration for card ASUSTeKCOMPUTERINC.-X205TA-1.0-X205TA > > This is reported as an error even if there is a fallback. I remember > losing a couple of hours trying to figure out what was happening when > in reality there was no issue. A good point, it should be suppressed. > I have two other points I need to sort out > > - what is the license for those UCM files? I keep getting questions > and I don't have the answer. It'd be odd to have then inherit the LGPL > license from alsa-lib, it's expected that people will have to do minor > modifications left and right and handle a number of derivatives, > e.g. because the perceived volume is too low due to some > mechanics/acoustics issue and requiring them to share is a bit > cumbersome. Unless explicitly specified, it should inherit from the whole alsa-lib license, i.e. LGPL. But I guess we have no problem for re-licensing (or dual-license) with a more relaxed one for UCM profiles, once when they are split to an individual repo. Since the whole projects were moved to github, we can do it easily, I suppose. > - how are we going to handle the changes for SOF, we added an "sof-" > prefix to make it explicit that the platform/DSP driver side is > different, but having a different board name will interfere with > search and includes. Sorry, it's not clear about the question. You need to use a different UCM profile when the device is bound with SOF, right? thanks, Takashi
>> - what is the license for those UCM files? I keep getting questions >> and I don't have the answer. It'd be odd to have then inherit the LGPL >> license from alsa-lib, it's expected that people will have to do minor >> modifications left and right and handle a number of derivatives, >> e.g. because the perceived volume is too low due to some >> mechanics/acoustics issue and requiring them to share is a bit >> cumbersome. > Unless explicitly specified, it should inherit from the whole alsa-lib > license, i.e. LGPL. But I guess we have no problem for re-licensing > (or dual-license) with a more relaxed one for UCM profiles, once when > they are split to an individual repo. > > Since the whole projects were moved to github, we can do it easily, I > suppose. I think we should have UCM and topology files in the same repo since they are related (control names, etc). BTW that's also one improvement that I forgot about. alsa-lib currently bails when it cannot find a control in an UCM file, and that's painful when control names change over time. I have e.g. older UCM profiles for Chromebooks that aren't compatible any longer with the upstream kernel for HDMI paths, but work fine with analog paths. It'd be really nice to downgrade the error to a warning. > >> - how are we going to handle the changes for SOF, we added an "sof-" >> prefix to make it explicit that the platform/DSP driver side is >> different, but having a different board name will interfere with >> search and includes. > Sorry, it's not clear about the question. You need to use a different > UCM profile when the device is bound with SOF, right? It's only different for the DSP parts, the codec settings are completely identical so I was hoping to avoid duplication of all the profiles and use some sort of run-time rule to only include the changed DSP settings. I don't have a turn-key solution to suggest, just a desire to avoid more maintenance work just because of a prefix added.
On Tue, 27 Nov 2018 18:08:30 +0100, Pierre-Louis Bossart wrote: > > > >> - what is the license for those UCM files? I keep getting questions > >> and I don't have the answer. It'd be odd to have then inherit the LGPL > >> license from alsa-lib, it's expected that people will have to do minor > >> modifications left and right and handle a number of derivatives, > >> e.g. because the perceived volume is too low due to some > >> mechanics/acoustics issue and requiring them to share is a bit > >> cumbersome. > > Unless explicitly specified, it should inherit from the whole alsa-lib > > license, i.e. LGPL. But I guess we have no problem for re-licensing > > (or dual-license) with a more relaxed one for UCM profiles, once when > > they are split to an individual repo. > > > > Since the whole projects were moved to github, we can do it easily, I > > suppose. > > I think we should have UCM and topology files in the same repo since > they are related (control names, etc). OK, makes sense. > BTW that's also one improvement that I forgot about. alsa-lib > currently bails when it cannot find a control in an UCM file, and > that's painful when control names change over time. I have e.g. older > UCM profiles for Chromebooks that aren't compatible any longer with > the upstream kernel for HDMI paths, but work fine with analog > paths. It'd be really nice to downgrade the error to a warning. Yeah, I've hit this a few times as well :) It'd be helpful to fallback or allow optional controls. > > > >> - how are we going to handle the changes for SOF, we added an "sof-" > >> prefix to make it explicit that the platform/DSP driver side is > >> different, but having a different board name will interfere with > >> search and includes. > > Sorry, it's not clear about the question. You need to use a different > > UCM profile when the device is bound with SOF, right? > > It's only different for the DSP parts, the codec settings are > completely identical so I was hoping to avoid duplication of all the > profiles and use some sort of run-time rule to only include the > changed DSP settings. I don't have a turn-key solution to suggest, > just a desire to avoid more maintenance work just because of a prefix > added. Some string manipulations should be available in the alsa-lib config syntax, so a thing like a control name might be set dynamically (hopefully). But my coverage and memory in that area are a bit vague, so let me see again once when more concrete pictures show up. thanks, Takashi
alsaucm -c chtrt5645 set _verb HiFi set _enadev Speaker ALSA lib conf.c:823:(get_char_skip_comments) Cannot access file bytcr/PlatformEnableSeq.conf ALSA lib conf.c:1877:(snd_config_load1) _toplevel_:17:18:Unexpected char speaker never work on asus x205ta. used https://github.com/plbossart/UCM/blob/master/chtrt5645/HiFi.conf file, alsaucm -c chtrt5645 set _verb HiFi set _enadev Speaker, speaker work on x205ta. what are you talk about 5651/5640/nau8824 ? help me x205ta ? Hans de Goede <hdegoede@redhat.com> 于2018年11月26日周一 下午9:40写道： > > Hi, > > On 26-11-18 11:07, Takashi Iwai wrote: > > The error messages (at least some of them) are known issues and I > > already posted the problem on alsa-devel ML. The fix should be easy > > but I'd like to get consensus beforehand. > > Ah I missed that mail as I'm not subscribed to alsa-devel. Since > my changes are the cause of this alsaucm command problem, let me > reply here: > > > some of the recently added UCM profiles are the files to be included > > by others, and they are not card targets. Unfortunately alsaucm > > doesn't know about it, and it aborts with error, e.g. > > > > ==== > > % alsaucm > > ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/bytcr/bytcr.conf > > ALSA lib parser.c:1427:(load_master_config) error: could not parse configuration for card bytcr > > alsaucm: unable to obtain card list: No such file or directory > > ==== > > > > The similar error is found in nau8824, rt5640 and rt5651. After > > putting a placeholder card config file (e.g. bytcr.conf), the error is > > gone. But certainly we don't want to allow user to choose this as the > > proper card. > > > > So, I guess we need to put some flag to each such directory indicating > > that it's no card config. For example, putting > > /usr/share/alsa/ucm/bytcr/.nocard file or such... > > > > Not sure whether it's wise to have a file starting with dot, though. > > Maybe clearer to be "nocard" or any other visible one? > > All the HiFi.conf files using the "include" snippets I added to avoid > copy and pasting a lot, already need to have this at the top for > this to work: > > <searchdir:ucm> > > So it might be best to move all the dirs holding include files rather > then proper card configs from /usr/share/alsa/ucm to > /usr/share/alsa/ucm-includes and then change the searchdir part of > the configs using these to: > > <searchdir:ucm-includes> > > Regards, > > Hans
why not i use this command, speaker also work on x205ta. alsaucm -c chtrt5645-mono-speaker-analog-mic set _verb HiFi set _enadev Speaker Hans de Goede <hdegoede@redhat.com> 于2018年11月26日周一 下午9:40写道： > > Hi, > > On 26-11-18 11:07, Takashi Iwai wrote: > > The error messages (at least some of them) are known issues and I > > already posted the problem on alsa-devel ML. The fix should be easy > > but I'd like to get consensus beforehand. > > Ah I missed that mail as I'm not subscribed to alsa-devel. Since > my changes are the cause of this alsaucm command problem, let me > reply here: > > > some of the recently added UCM profiles are the files to be included > > by others, and they are not card targets. Unfortunately alsaucm > > doesn't know about it, and it aborts with error, e.g. > > > > ==== > > % alsaucm > > ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/bytcr/bytcr.conf > > ALSA lib parser.c:1427:(load_master_config) error: could not parse configuration for card bytcr > > alsaucm: unable to obtain card list: No such file or directory > > ==== > > > > The similar error is found in nau8824, rt5640 and rt5651. After > > putting a placeholder card config file (e.g. bytcr.conf), the error is > > gone. But certainly we don't want to allow user to choose this as the > > proper card. > > > > So, I guess we need to put some flag to each such directory indicating > > that it's no card config. For example, putting > > /usr/share/alsa/ucm/bytcr/.nocard file or such... > > > > Not sure whether it's wise to have a file starting with dot, though. > > Maybe clearer to be "nocard" or any other visible one? > > All the HiFi.conf files using the "include" snippets I added to avoid > copy and pasting a lot, already need to have this at the top for > this to work: > > <searchdir:ucm> > > So it might be best to move all the dirs holding include files rather > then proper card configs from /usr/share/alsa/ucm to > /usr/share/alsa/ucm-includes and then change the searchdir part of > the configs using these to: > > <searchdir:ucm-includes> > > Regards, > > Hans
/src/conf/ucm/chtrt5645/HiFi.conf missed <searchdir:ucm>, now, should add <searchdir:ucm-includes>. Hans de Goede <hdegoede@redhat.com> 于2018年11月26日周一 下午9:40写道： > > Hi, > > On 26-11-18 11:07, Takashi Iwai wrote: > > The error messages (at least some of them) are known issues and I > > already posted the problem on alsa-devel ML. The fix should be easy > > but I'd like to get consensus beforehand. > > Ah I missed that mail as I'm not subscribed to alsa-devel. Since > my changes are the cause of this alsaucm command problem, let me > reply here: > > > some of the recently added UCM profiles are the files to be included > > by others, and they are not card targets. Unfortunately alsaucm > > doesn't know about it, and it aborts with error, e.g. > > > > ==== > > % alsaucm > > ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/bytcr/bytcr.conf > > ALSA lib parser.c:1427:(load_master_config) error: could not parse configuration for card bytcr > > alsaucm: unable to obtain card list: No such file or directory > > ==== > > > > The similar error is found in nau8824, rt5640 and rt5651. After > > putting a placeholder card config file (e.g. bytcr.conf), the error is > > gone. But certainly we don't want to allow user to choose this as the > > proper card. > > > > So, I guess we need to put some flag to each such directory indicating > > that it's no card config. For example, putting > > /usr/share/alsa/ucm/bytcr/.nocard file or such... > > > > Not sure whether it's wise to have a file starting with dot, though. > > Maybe clearer to be "nocard" or any other visible one? > > All the HiFi.conf files using the "include" snippets I added to avoid > copy and pasting a lot, already need to have this at the top for > this to work: > > <searchdir:ucm> > > So it might be best to move all the dirs holding include files rather > then proper card configs from /usr/share/alsa/ucm to > /usr/share/alsa/ucm-includes and then change the searchdir part of > the configs using these to: > > <searchdir:ucm-includes> > > Regards, > > Hans
revert "conf/ucm: bytcr-rt5645: Use the generic bytcr/PlatformEnableSeq.conf", or add missed <searchdir:ucm-includes> for chtrt5645, what do you want? Takashi Iwai <tiwai@suse.de> 于2018年11月28日周三 上午1:12写道： > > On Tue, 27 Nov 2018 18:08:30 +0100, > Pierre-Louis Bossart wrote: > > > > > > >> - what is the license for those UCM files? I keep getting questions > > >> and I don't have the answer. It'd be odd to have then inherit the LGPL > > >> license from alsa-lib, it's expected that people will have to do minor > > >> modifications left and right and handle a number of derivatives, > > >> e.g. because the perceived volume is too low due to some > > >> mechanics/acoustics issue and requiring them to share is a bit > > >> cumbersome. > > > Unless explicitly specified, it should inherit from the whole alsa-lib > > > license, i.e. LGPL. But I guess we have no problem for re-licensing > > > (or dual-license) with a more relaxed one for UCM profiles, once when > > > they are split to an individual repo. > > > > > > Since the whole projects were moved to github, we can do it easily, I > > > suppose. > > > > I think we should have UCM and topology files in the same repo since > > they are related (control names, etc). > > OK, makes sense. > > > BTW that's also one improvement that I forgot about. alsa-lib > > currently bails when it cannot find a control in an UCM file, and > > that's painful when control names change over time. I have e.g. older > > UCM profiles for Chromebooks that aren't compatible any longer with > > the upstream kernel for HDMI paths, but work fine with analog > > paths. It'd be really nice to downgrade the error to a warning. > > Yeah, I've hit this a few times as well :) > It'd be helpful to fallback or allow optional controls. > > > > > > >> - how are we going to handle the changes for SOF, we added an "sof-" > > >> prefix to make it explicit that the platform/DSP driver side is > > >> different, but having a different board name will interfere with > > >> search and includes. > > > Sorry, it's not clear about the question. You need to use a different > > > UCM profile when the device is bound with SOF, right? > > > > It's only different for the DSP parts, the codec settings are > > completely identical so I was hoping to avoid duplication of all the > > profiles and use some sort of run-time rule to only include the > > changed DSP settings. I don't have a turn-key solution to suggest, > > just a desire to avoid more maintenance work just because of a prefix > > added. > > Some string manipulations should be available in the alsa-lib config > syntax, so a thing like a control name might be set dynamically > (hopefully). > > But my coverage and memory in that area are a bit vague, so let me see > again once when more concrete pictures show up. > > > thanks, > > Takashi
On Wed, 28 Nov 2018 05:35:50 +0100, youling 257 wrote: > > revert "conf/ucm: bytcr-rt5645: Use the generic > bytcr/PlatformEnableSeq.conf", or add missed <searchdir:ucm-includes> > for chtrt5645, what do you want? Avoid top-posting and a bit more context for understanding by human beings, please :) In anyway, I see the point, my previous patch was far imperfect. The second patch will be submitted soon. thanks, Takashi > > Takashi Iwai <tiwai@suse.de> 于2018年11月28日周三 上午1:12写道： > > > > On Tue, 27 Nov 2018 18:08:30 +0100, > > Pierre-Louis Bossart wrote: > > > > > > > > > >> - what is the license for those UCM files? I keep getting questions > > > >> and I don't have the answer. It'd be odd to have then inherit the LGPL > > > >> license from alsa-lib, it's expected that people will have to do minor > > > >> modifications left and right and handle a number of derivatives, > > > >> e.g. because the perceived volume is too low due to some > > > >> mechanics/acoustics issue and requiring them to share is a bit > > > >> cumbersome. > > > > Unless explicitly specified, it should inherit from the whole alsa-lib > > > > license, i.e. LGPL. But I guess we have no problem for re-licensing > > > > (or dual-license) with a more relaxed one for UCM profiles, once when > > > > they are split to an individual repo. > > > > > > > > Since the whole projects were moved to github, we can do it easily, I > > > > suppose. > > > > > > I think we should have UCM and topology files in the same repo since > > > they are related (control names, etc). > > > > OK, makes sense. > > > > > BTW that's also one improvement that I forgot about. alsa-lib > > > currently bails when it cannot find a control in an UCM file, and > > > that's painful when control names change over time. I have e.g. older > > > UCM profiles for Chromebooks that aren't compatible any longer with > > > the upstream kernel for HDMI paths, but work fine with analog > > > paths. It'd be really nice to downgrade the error to a warning. > > > > Yeah, I've hit this a few times as well :) > > It'd be helpful to fallback or allow optional controls. > > > > > > > > > >> - how are we going to handle the changes for SOF, we added an "sof-" > > > >> prefix to make it explicit that the platform/DSP driver side is > > > >> different, but having a different board name will interfere with > > > >> search and includes. > > > > Sorry, it's not clear about the question. You need to use a different > > > > UCM profile when the device is bound with SOF, right? > > > > > > It's only different for the DSP parts, the codec settings are > > > completely identical so I was hoping to avoid duplication of all the > > > profiles and use some sort of run-time rule to only include the > > > changed DSP settings. I don't have a turn-key solution to suggest, > > > just a desire to avoid more maintenance work just because of a prefix > > > added. > > > > Some string manipulations should be available in the alsa-lib config > > syntax, so a thing like a control name might be set dynamically > > (hopefully). > > > > But my coverage and memory in that area are a bit vague, so let me see > > again once when more concrete pictures show up. > > > > > > thanks, > > > > Takashi >
diff --git a/src/conf/ucm/chtrt5645/HiFi.conf b/src/conf/ucm/chtrt5645/HiFi.conf index e81866cf..d993f6ae 100644 --- a/src/conf/ucm/chtrt5645/HiFi.conf +++ b/src/conf/ucm/chtrt5645/HiFi.conf @@ -11,121 +11,7 @@ SectionVerb { EnableSequence [ cdev "hw:chtrt5645" - # media mixer settings - # compress - cset "name='media0_in Gain 0 Switch' on" - cset "name='media0_in Gain 0 Volume' 0" - - # normal - cset "name='media1_in Gain 0 Switch' on" - cset "name='media1_in Gain 0 Volume' 0" - # swm loopback - cset "name='media2_in Gain 0 Switch' off" - cset "name='media2_in Gain 0 Volume' 0%" - # deep buffer - cset "name='media3_in Gain 0 Switch' on" - cset "name='media3_in Gain 0 Volume' 0" - - cset "name='media0_out mix 0 media0_in Switch' on" - cset "name='media0_out mix 0 media1_in Switch' on" - cset "name='media0_out mix 0 media2_in Switch' off" - cset "name='media0_out mix 0 media3_in Switch' on" - - cset "name='media1_out mix 0 media0_in Switch' off" - cset "name='media1_out mix 0 media1_in Switch' off" - cset "name='media1_out mix 0 media2_in Switch' off" - cset "name='media1_out mix 0 media3_in Switch' off" - - cset "name='pcm0_in Gain 0 Switch' on" - cset "name='pcm0_in Gain 0 Volume' 0" - - cset "name='pcm1_in Gain 0 Switch' off" - cset "name='pcm1_in Gain 0 Volume' 0%" - - # codec0_out settings (used if ssp2 is connected to aif1) - cset "name='codec_out0 mix 0 codec_in0 Switch' off" - cset "name='codec_out0 mix 0 codec_in1 Switch' off" - cset "name='codec_out0 mix 0 media_loop1_in Switch' off" - cset "name='codec_out0 mix 0 media_loop2_in Switch' off" - cset "name='codec_out0 mix 0 pcm0_in Switch' on" - cset "name='codec_out0 mix 0 pcm1_in Switch' off" - cset "name='codec_out0 mix 0 sprot_loop_in Switch' off" - cset "name='codec_out0 Gain 0 Switch' on" - cset "name='codec_out0 Gain 0 Volume' 0" - - # modem_out settings (used if ssp0 is connected to aif2) - cset "name='modem_out mix 0 codec_in0 Switch' off" - cset "name='modem_out mix 0 codec_in1 Switch' off" - cset "name='modem_out mix 0 media_loop1_in Switch' off" - cset "name='modem_out mix 0 media_loop2_in Switch' off" - cset "name='modem_out mix 0 pcm0_in Switch' on" - cset "name='modem_out mix 0 pcm1_in Switch' off" - cset "name='modem_out mix 0 sprot_loop_in Switch' off" - cset "name='modem_out Gain 0 Switch' on" - cset "name='modem_out Gain 0 Volume' 0" - - # input settings - # pcm1_out settings - - # input used when SSP2 is connected - cset "name='codec_in0 Gain 0 Switch' on" - cset "name='codec_in0 Gain 0 Volume' 0" - - # input used when SSP0 is connected - cset "name='modem_in Gain 0 Switch' on" - cset "name='modem_in Gain 0 Volume' 0" - - cset "name='pcm1_out mix 0 codec_in0 Switch' on" - cset "name='pcm1_out mix 0 modem_in Switch' on" - cset "name='pcm1_out mix 0 codec_in1 Switch' off" - cset "name='pcm1_out mix 0 media_loop1_in Switch' off" - cset "name='pcm1_out mix 0 media_loop2_in Switch' off" - cset "name='pcm1_out mix 0 pcm0_in Switch' off" - cset "name='pcm1_out mix 0 pcm1_in Switch' off" - cset "name='pcm1_out mix 0 sprot_loop_in Switch' off" - - cset "name='pcm1_out Gain 0 Switch' on" - cset "name='pcm1_out Gain 0 Volume' 0" - - # disable codec_out1 - cset "name='codec_out1 mix 0 codec_in0 Switch' off" - cset "name='codec_out1 mix 0 codec_in1 Switch' off" - cset "name='codec_out1 mix 0 media_loop1_in Switch' off" - cset "name='codec_out1 mix 0 media_loop2_in Switch' off" - cset "name='codec_out1 mix 0 pcm0_in Switch' off" - cset "name='codec_out1 mix 0 pcm1_in Switch' off" - cset "name='codec_out1 mix 0 sprot_loop_in Switch' off" - cset "name='codec_out1 Gain 0 Switch' off" - cset "name='codec_out1 Gain 0 Volume' 0%" - - # disable codec_in1 - cset "name='codec_in1 Gain 0 Switch' off" - cset "name='codec_in1 Gain 0 Volume' 0%" - - # disable all loops - cset "name='media_loop1_out mix 0 codec_in0 Switch' off" - cset "name='media_loop1_out mix 0 codec_in1 Switch' off" - cset "name='media_loop1_out mix 0 media_loop1_in Switch' off" - cset "name='media_loop1_out mix 0 media_loop2_in Switch' off" - cset "name='media_loop1_out mix 0 pcm0_in Switch' off" - cset "name='media_loop1_out mix 0 pcm1_in Switch' off" - cset "name='media_loop1_out mix 0 sprot_loop_in Switch' off" - - cset "name='media_loop2_out mix 0 codec_in0 Switch' off" - cset "name='media_loop2_out mix 0 codec_in1 Switch' off" - cset "name='media_loop2_out mix 0 media_loop1_in Switch' off" - cset "name='media_loop2_out mix 0 media_loop2_in Switch' off" - cset "name='media_loop2_out mix 0 pcm0_in Switch' off" - cset "name='media_loop2_out mix 0 pcm1_in Switch' off" - cset "name='media_loop2_out mix 0 sprot_loop_in Switch' off" - - cset "name='sprot_loop_out mix 0 codec_in0 Switch' off" - cset "name='sprot_loop_out mix 0 codec_in1 Switch' off" - cset "name='sprot_loop_out mix 0 media_loop1_in Switch' off" - cset "name='sprot_loop_out mix 0 media_loop2_in Switch' off" - cset "name='sprot_loop_out mix 0 pcm0_in Switch' off" - cset "name='sprot_loop_out mix 0 pcm1_in Switch' off" - cset "name='sprot_loop_out mix 0 sprot_loop_in Switch' off" + <bytcr/PlatformEnableSeq.conf> # Output Configuration cset "name='DAC1 L Mux' IF1 DAC"