* Re: ASoC and pulseaudio [not found] ` <B51200AC81AB024499A3C2C9A1BB90A83D3AABF9@SHSMSX101.ccr.corp.intel.com> @ 2016-03-14 8:19 ` Liam Girdwood 2016-03-14 15:23 ` [alsa-devel] " Pierre-Louis Bossart 2016-03-14 16:06 ` Mark Brown 0 siblings, 2 replies; 21+ messages in thread From: Liam Girdwood @ 2016-03-14 8:19 UTC (permalink / raw) To: General PulseAudio Discussion, alsa-devel Cc: Takashi Iwai, Mark Brown, Linux Upstreaming Team, han.lu + alsa, Takashi and Mark since it's a naming convention being discussed as part of this work. On Mon, 2016-03-14 at 08:17 +0000, Lu, Han wrote: > Hi, > > > -----Original Message----- > > From: pulseaudio-discuss [mailto:pulseaudio-discuss- > > bounces@lists.freedesktop.org] On Behalf Of Liam Girdwood > > Sent: Tuesday, February 23, 2016 7:13 PM > > To: General PulseAudio Discussion <pulseaudio- > > discuss@lists.freedesktop.org> > > Cc: Linux Upstreaming Team <linux@endlessm.com>; han.lu > > <han.lu@linux.intel.com> > > Subject: Re: [pulseaudio-discuss] ASoC and pulseaudio > > > > On Sat, 2016-02-20 at 12:22 -0600, Pierre-Louis Bossart wrote: > > > r > > > On 02/17/2016 09:27 AM, Carlo Caione wrote: > > > > Hi, > > > > In our daily work we are seeing more and more laptops coming in with > > > > SoC audio (ASoC). In the most recent case, we are working with a new > > > > consumer laptop based on Intel Cherry Trail. As you probably know to > > > > have audio working on these laptops / codecs a fairly lengthy hw > > > > specific mixer configuration is needed. > > > > The problem we are facing is how to ship a single PA / ALSA package > > > > containing a working configuration for several of those laptops and > > > > we were wondering what is the most correct / upstream-friendly way > > > > to do that. > > > > > > > > I'm already excluding here some trivial workarounds like: shipping a > > > > different PA package for each hw or using an hw-tailored script to > > > > load the correct ALSA configuration. > > > > > > > > The first solution we came up with is just to write a profile-set > > > > configuration file loaded by udev for each cards / laptop with the > > > > correct mixer configuration already embedded in the path > > > > configuration files. This looks a bit like an overkill when you have > > > > to change tens of controls most of which just one time (once you > > > > have setup the codec selecting the main path is usually just matter > > > > of changing a few controls to change the output / input path). > > > > > > > > Another possibility is to use UCM and let PA create automatically > > > > from that profile and path configuration files. This looks promising > > > > but we were a bit worried about the UCM support in PA and how > > > > stable/adopted is UCM itself. > > > > Fwiw, I've not had any problems using PA and UCM together on my BDW + > > RT286 based development platforms. The problem we have atm is matching > > and quirks as Pierre describes. > > > > > > > > > > So, what is the suggested way to accomplish this and in general how > > > > PA is trying to address this problem? I expect in the future to see > > > > many more ASoC coming into the laptops world, how will the community > > > > make it so that you install a distro and then sound "just works"? > > > > > > Not an easy problem. I generated a set of UCM files for baytrail-based > > platforms and I was planning on doing the same for CHT now that there are a > > set of commercially available devices. > > > There are however a set of limitations that are known already, e.g. > > > the UCM file matches the machine driver name, so if there are any quirks > > inside the driver we'd need to add a DMI-based info to the card name and > > also build UCM files based on an include mechanism, otherwise it's going to > > be copy/paste hell Adding Liam to make sure he sees this thread. > > > > > > > Fwiw, we have been looking at providing some fixes for naming and quirks. > > We should probably schedule the work now. > > > > For naming we have the problem of duplication in the driver name e.g. > > > > cat /proc/asound/cards > > 0 [bytrt5640 ]: byt-rt5640 - byt-rt5640 > > byt-rt5640 > > > > The driver name actually has three strings iirc and we could differentiate here > > (by adding DMI name, plus any others?? ) to help UCM and PA deal with any > > quirks. > > > > UCM also does not currently support #include. The intention is to provide a > > method to define mixer settings on a codec per codec basis and the these > > could be #included into a machine UCM file. The machine UCM file would > > also define settings for any quirks and would #include any codec UCM files > > that were needed. PA would load the machine UCM file (based on > > improvements to the driver naming above) intead of the generic UCM file > > that is loaded atm. > > > > Liam > > > > We can fix this from driver level and user space level: > (1) to reporting more information from driver. > ALSA sound cards have 3 names. longname, shortname and drivername. e.g. > from soc-core.c :- > > snprintf(card->snd_card->shortname, sizeof(card->snd_card->shortname), > "%s", card->name); > snprintf(card->snd_card->longname, sizeof(card->snd_card->longname), > "%s", card->long_name ? card->long_name : card->name); > snprintf(card->snd_card->driver, sizeof(card->snd_card->driver), > "%s", card->driver_name ? card->driver_name : card->name); > > We can additionally set the long_name and driver_name in ASoC if they were not set. > > The naming scheme could be :- > > a) shortname is current machine driver name i.e. "byt-rt5640" > b) longname is DMI boardname + 1 i.e. "Minnowboard Max: byt-rt5640" > c) driver name is platform driver name i.e. "baytrail-pcm-audio" > > (2) to enable UCM to support "include" parsing, so each codec will have its own UCM file to define all the use cases for the codec only, and the codec UCM file can be included and the codec use cases can be referenced by different machine driver UCM files. > > I'll try to work out RFC patches to implement the features above. > > BR, > Han > > > > > > > > _______________________________________________ > > > pulseaudio-discuss mailing list > > > pulseaudio-discuss@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > > > > _______________________________________________ > > pulseaudio-discuss mailing list > > pulseaudio-discuss@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [alsa-devel] ASoC and pulseaudio 2016-03-14 8:19 ` ASoC and pulseaudio Liam Girdwood @ 2016-03-14 15:23 ` Pierre-Louis Bossart 2016-03-14 16:06 ` Mark Brown 1 sibling, 0 replies; 21+ messages in thread From: Pierre-Louis Bossart @ 2016-03-14 15:23 UTC (permalink / raw) To: Liam Girdwood, General PulseAudio Discussion, alsa-devel Cc: Takashi Iwai, Mark Brown, Linux Upstreaming Team, han.lu [snip] >>> UCM also does not currently support #include. The intention is to provide a >>> method to define mixer settings on a codec per codec basis and the these >>> could be #included into a machine UCM file. The machine UCM file would >>> also define settings for any quirks and would #include any codec UCM files >>> that were needed. PA would load the machine UCM file (based on >>> improvements to the driver naming above) intead of the generic UCM file >>> that is loaded atm. >>> >>> Liam >>> >> >> We can fix this from driver level and user space level: >> (1) to reporting more information from driver. >> ALSA sound cards have 3 names. longname, shortname and drivername. e.g. >> from soc-core.c :- >> >> snprintf(card->snd_card->shortname, sizeof(card->snd_card->shortname), >> "%s", card->name); >> snprintf(card->snd_card->longname, sizeof(card->snd_card->longname), >> "%s", card->long_name ? card->long_name : card->name); >> snprintf(card->snd_card->driver, sizeof(card->snd_card->driver), >> "%s", card->driver_name ? card->driver_name : card->name); >> >> We can additionally set the long_name and driver_name in ASoC if they were not set. >> >> The naming scheme could be :- >> >> a) shortname is current machine driver name i.e. "byt-rt5640" >> b) longname is DMI boardname + 1 i.e. "Minnowboard Max: byt-rt5640" >> c) driver name is platform driver name i.e. "baytrail-pcm-audio" >> >> (2) to enable UCM to support "include" parsing, so each codec will have its own UCM file to define all the use cases for the codec only, and the codec UCM file can be included and the codec use cases can be referenced by different machine driver UCM files. I don't think a single codec UCM file would work since the register settings would conflict. You will have to create different UCM snippets for specific codec configurations that are included by machine drivers, e.g. one for dmics, one for amics, one for stereo speakers, etc. _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: ASoC and pulseaudio 2016-03-14 8:19 ` ASoC and pulseaudio Liam Girdwood 2016-03-14 15:23 ` [alsa-devel] " Pierre-Louis Bossart @ 2016-03-14 16:06 ` Mark Brown 2016-03-15 6:01 ` Liam Girdwood 1 sibling, 1 reply; 21+ messages in thread From: Mark Brown @ 2016-03-14 16:06 UTC (permalink / raw) To: Liam Girdwood Cc: Takashi Iwai, alsa-devel, Linux Upstreaming Team, General PulseAudio Discussion, han.lu [-- Attachment #1.1: Type: text/plain, Size: 599 bytes --] On Mon, Mar 14, 2016 at 08:19:27AM +0000, Liam Girdwood wrote: Could people please fix their mail clients to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > On Mon, 2016-03-14 at 08:17 +0000, Lu, Han wrote: > > a) shortname is current machine driver name i.e. "byt-rt5640" > > b) longname is DMI boardname + 1 i.e. "Minnowboard Max: byt-rt5640" > > c) driver name is platform driver name i.e. "baytrail-pcm-audio" I don't understand why we wouldn't use the machine driver name as the driver name. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] [-- Attachment #2: Type: text/plain, Size: 187 bytes --] _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: ASoC and pulseaudio 2016-03-14 16:06 ` Mark Brown @ 2016-03-15 6:01 ` Liam Girdwood 2016-03-15 8:45 ` Mark Brown 0 siblings, 1 reply; 21+ messages in thread From: Liam Girdwood @ 2016-03-15 6:01 UTC (permalink / raw) To: Mark Brown Cc: Takashi Iwai, alsa-devel, Linux Upstreaming Team, General PulseAudio Discussion, han.lu On Mon, 2016-03-14 at 16:06 +0000, Mark Brown wrote: > On Mon, Mar 14, 2016 at 08:19:27AM +0000, Liam Girdwood wrote: > > > On Mon, 2016-03-14 at 08:17 +0000, Lu, Han wrote: > > > > a) shortname is current machine driver name i.e. "byt-rt5640" > > > b) longname is DMI boardname + 1 i.e. "Minnowboard Max: byt-rt5640" > > > c) driver name is platform driver name i.e. "baytrail-pcm-audio" > > I don't understand why we wouldn't use the machine driver name as the > driver name. I'm fine with that too. What about :- 1) Shortname is board/machine name. This can come from DMI or device tree. e.g. "Asus T100" 2) Long name is 1 + driver name + optional firmware name. (I've just added the FW name here too as we can have potentially > 1 FW per driver - BYT is an example) e.g. "Asus T00: byt-rt5640: IntSST1.bin". 3) Driver name is driver_name. e.g. "byt-rt5640" (The string name combinations above are not from a real machine but just for example.) Liam _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: ASoC and pulseaudio 2016-03-15 6:01 ` Liam Girdwood @ 2016-03-15 8:45 ` Mark Brown 2016-03-15 8:55 ` Takashi Iwai 0 siblings, 1 reply; 21+ messages in thread From: Mark Brown @ 2016-03-15 8:45 UTC (permalink / raw) To: Liam Girdwood Cc: Takashi Iwai, alsa-devel, Linux Upstreaming Team, General PulseAudio Discussion, han.lu [-- Attachment #1.1: Type: text/plain, Size: 611 bytes --] On Tue, Mar 15, 2016 at 06:01:28AM +0000, Liam Girdwood wrote: > 1) Shortname is board/machine name. This can come from DMI or device > tree. e.g. "Asus T100" That seems more useful for users. > 2) Long name is 1 + driver name + optional firmware name. (I've just > added the FW name here too as we can have potentially > 1 FW per driver > - BYT is an example) e.g. "Asus T00: byt-rt5640: IntSST1.bin". Shouldn't we use whatever we use to figure out which firmware to load rather than the firmware name? Someone might do something like try to replace one firmware with another and get everything confused. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] [-- Attachment #2: Type: text/plain, Size: 187 bytes --] _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: ASoC and pulseaudio 2016-03-15 8:45 ` Mark Brown @ 2016-03-15 8:55 ` Takashi Iwai 2016-03-15 9:48 ` Liam Girdwood 0 siblings, 1 reply; 21+ messages in thread From: Takashi Iwai @ 2016-03-15 8:55 UTC (permalink / raw) To: Mark Brown Cc: alsa-devel, Linux Upstreaming Team, General PulseAudio Discussion, han.lu On Tue, 15 Mar 2016 09:45:44 +0100, Mark Brown wrote: > > On Tue, Mar 15, 2016 at 06:01:28AM +0000, Liam Girdwood wrote: > > > 1) Shortname is board/machine name. This can come from DMI or device > > tree. e.g. "Asus T100" > > That seems more useful for users. > > > 2) Long name is 1 + driver name + optional firmware name. (I've just > > added the FW name here too as we can have potentially > 1 FW per driver > > - BYT is an example) e.g. "Asus T00: byt-rt5640: IntSST1.bin". > > Shouldn't we use whatever we use to figure out which firmware to load > rather than the firmware name? Someone might do something like try to > replace one firmware with another and get everything confused. I agree that a consistent name would be better. Though, practically seen, the long name isn't persistent with many drivers, as it often contains the irq or port numbers that are assigned dynamically. That said, the consistency of long name isn't strictly required. It's regarded rather as a verbose information to user, which shouldn't be used as an identifier key. OTOH, the driver name is the primary id key used by alsa-lib for its configuration. So this must be retained through versions and unique for each configuration. The short name is something between them. The alsa-lib USB-audio config file refers to the short name because the driver doesn't provide a unique id for driver_name for various workarounds. But it should be considered as an exception. Ideally, driver_name should be unique enough for each different configuration. Takashi _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: ASoC and pulseaudio 2016-03-15 8:55 ` Takashi Iwai @ 2016-03-15 9:48 ` Liam Girdwood 2016-03-15 9:56 ` Takashi Iwai 2016-03-15 10:00 ` Mark Brown 0 siblings, 2 replies; 21+ messages in thread From: Liam Girdwood @ 2016-03-15 9:48 UTC (permalink / raw) To: Takashi Iwai Cc: alsa-devel, Mark Brown, Linux Upstreaming Team, General PulseAudio Discussion, han.lu On Tue, 2016-03-15 at 09:55 +0100, Takashi Iwai wrote: > On Tue, 15 Mar 2016 09:45:44 +0100, > Mark Brown wrote: > > > > On Tue, Mar 15, 2016 at 06:01:28AM +0000, Liam Girdwood wrote: > > > > > 1) Shortname is board/machine name. This can come from DMI or device > > > tree. e.g. "Asus T100" > > > > That seems more useful for users. > > > > > 2) Long name is 1 + driver name + optional firmware name. (I've just > > > added the FW name here too as we can have potentially > 1 FW per driver > > > - BYT is an example) e.g. "Asus T00: byt-rt5640: IntSST1.bin". > > > > Shouldn't we use whatever we use to figure out which firmware to load > > rather than the firmware name? Someone might do something like try to > > replace one firmware with another and get everything confused. > This is not to load FW for our use case, the FW name is hard coded in driver tables. We do have several FWs for the BYT driver that all have different capabilities. Userspace could set the correct config for each FW if it knew the FW that was being used. > I agree that a consistent name would be better. Though, practically > seen, the long name isn't persistent with many drivers, as it often > contains the irq or port numbers that are assigned dynamically. That > said, the consistency of long name isn't strictly required. It's > regarded rather as a verbose information to user, which shouldn't be > used as an identifier key. > > OTOH, the driver name is the primary id key used by alsa-lib for its > configuration. So this must be retained through versions and unique > for each configuration. > Ok, so we probably need to add in the board/machine name here (from DMI or DT). We currently have several x86 machines all using the same codec + DSP + FW, but all have slightly different clocking and routing that is causing problems as userspace cannot configure correctly. > The short name is something between them. The alsa-lib USB-audio > config file refers to the short name because the driver doesn't > provide a unique id for driver_name for various workarounds. But it > should be considered as an exception. Ideally, driver_name should be > unique enough for each different configuration. So IIUC this would mean ? 1) short name is optional, but could be board name. 2) long name is driver_name plus any other optional information for the user. Not used by applications or alsa-lib to determine sound card capabilities. 3) Driver name is unique. machine driver name + (optional) board name + (optional) fw name. e.g. "byt-rt5640: Asus T100: IntSST1.bin" used by alsa-lib and userspace to determine sound card and set config. Liam _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: ASoC and pulseaudio 2016-03-15 9:48 ` Liam Girdwood @ 2016-03-15 9:56 ` Takashi Iwai 2016-03-15 10:58 ` Liam Girdwood 2016-03-15 10:00 ` Mark Brown 1 sibling, 1 reply; 21+ messages in thread From: Takashi Iwai @ 2016-03-15 9:56 UTC (permalink / raw) To: Liam Girdwood Cc: alsa-devel, Mark Brown, Linux Upstreaming Team, General PulseAudio Discussion, han.lu On Tue, 15 Mar 2016 10:48:51 +0100, Liam Girdwood wrote: > > On Tue, 2016-03-15 at 09:55 +0100, Takashi Iwai wrote: > > On Tue, 15 Mar 2016 09:45:44 +0100, > > Mark Brown wrote: > > > > > > On Tue, Mar 15, 2016 at 06:01:28AM +0000, Liam Girdwood wrote: > > > > > > > 1) Shortname is board/machine name. This can come from DMI or device > > > > tree. e.g. "Asus T100" > > > > > > That seems more useful for users. > > > > > > > 2) Long name is 1 + driver name + optional firmware name. (I've just > > > > added the FW name here too as we can have potentially > 1 FW per driver > > > > - BYT is an example) e.g. "Asus T00: byt-rt5640: IntSST1.bin". > > > > > > Shouldn't we use whatever we use to figure out which firmware to load > > > rather than the firmware name? Someone might do something like try to > > > replace one firmware with another and get everything confused. > > > > This is not to load FW for our use case, the FW name is hard coded in > driver tables. We do have several FWs for the BYT driver that all have > different capabilities. Userspace could set the correct config for each > FW if it knew the FW that was being used. > > > I agree that a consistent name would be better. Though, practically > > seen, the long name isn't persistent with many drivers, as it often > > contains the irq or port numbers that are assigned dynamically. That > > said, the consistency of long name isn't strictly required. It's > > regarded rather as a verbose information to user, which shouldn't be > > used as an identifier key. > > > > OTOH, the driver name is the primary id key used by alsa-lib for its > > configuration. So this must be retained through versions and unique > > for each configuration. > > > > Ok, so we probably need to add in the board/machine name here (from DMI > or DT). We currently have several x86 machines all using the same codec > + DSP + FW, but all have slightly different clocking and routing that is > causing problems as userspace cannot configure correctly. > > > The short name is something between them. The alsa-lib USB-audio > > config file refers to the short name because the driver doesn't > > provide a unique id for driver_name for various workarounds. But it > > should be considered as an exception. Ideally, driver_name should be > > unique enough for each different configuration. > > So IIUC this would mean ? > > 1) short name is optional, but could be board name. Right. > 2) long name is driver_name plus any other optional information for the > user. Not used by applications or alsa-lib to determine sound card > capabilities. In most cases, long name is short name + more optional information. > 3) Driver name is unique. machine driver name + (optional) board name + > (optional) fw name. e.g. "byt-rt5640: Asus T100: IntSST1.bin" used by > alsa-lib and userspace to determine sound card and set config. But, beware that driver name is fairly short, it's a 16 bytes string. The short name is 32 bytes and long name is 80 bytes. Thus, you need a special care to provide a unique driver name. Takashi _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: ASoC and pulseaudio 2016-03-15 9:56 ` Takashi Iwai @ 2016-03-15 10:58 ` Liam Girdwood 2016-03-16 14:57 ` [pulseaudio-discuss] " Vinod Koul 0 siblings, 1 reply; 21+ messages in thread From: Liam Girdwood @ 2016-03-15 10:58 UTC (permalink / raw) To: Takashi Iwai Cc: alsa-devel, Mark Brown, Linux Upstreaming Team, General PulseAudio Discussion, han.lu On Tue, 2016-03-15 at 10:56 +0100, Takashi Iwai wrote: > On Tue, 15 Mar 2016 10:48:51 +0100, > Liam Girdwood wrote: > > > > On Tue, 2016-03-15 at 09:55 +0100, Takashi Iwai wrote: > > > On Tue, 15 Mar 2016 09:45:44 +0100, > > > Mark Brown wrote: > > > > > > > > On Tue, Mar 15, 2016 at 06:01:28AM +0000, Liam Girdwood wrote: > > > > > > > > > 1) Shortname is board/machine name. This can come from DMI or device > > > > > tree. e.g. "Asus T100" > > > > > > > > That seems more useful for users. > > > > > > > > > 2) Long name is 1 + driver name + optional firmware name. (I've just > > > > > added the FW name here too as we can have potentially > 1 FW per driver > > > > > - BYT is an example) e.g. "Asus T00: byt-rt5640: IntSST1.bin". > > > > > > > > Shouldn't we use whatever we use to figure out which firmware to load > > > > rather than the firmware name? Someone might do something like try to > > > > replace one firmware with another and get everything confused. > > > > > > > This is not to load FW for our use case, the FW name is hard coded in > > driver tables. We do have several FWs for the BYT driver that all have > > different capabilities. Userspace could set the correct config for each > > FW if it knew the FW that was being used. > > > > > I agree that a consistent name would be better. Though, practically > > > seen, the long name isn't persistent with many drivers, as it often > > > contains the irq or port numbers that are assigned dynamically. That > > > said, the consistency of long name isn't strictly required. It's > > > regarded rather as a verbose information to user, which shouldn't be > > > used as an identifier key. > > > > > > OTOH, the driver name is the primary id key used by alsa-lib for its > > > configuration. So this must be retained through versions and unique > > > for each configuration. > > > > > > > Ok, so we probably need to add in the board/machine name here (from DMI > > or DT). We currently have several x86 machines all using the same codec > > + DSP + FW, but all have slightly different clocking and routing that is > > causing problems as userspace cannot configure correctly. > > > > > The short name is something between them. The alsa-lib USB-audio > > > config file refers to the short name because the driver doesn't > > > provide a unique id for driver_name for various workarounds. But it > > > should be considered as an exception. Ideally, driver_name should be > > > unique enough for each different configuration. > > > > So IIUC this would mean ? > > > > 1) short name is optional, but could be board name. > > Right. > > > 2) long name is driver_name plus any other optional information for the > > user. Not used by applications or alsa-lib to determine sound card > > capabilities. > > In most cases, long name is short name + more optional information. > > > 3) Driver name is unique. machine driver name + (optional) board name + > > (optional) fw name. e.g. "byt-rt5640: Asus T100: IntSST1.bin" used by > > alsa-lib and userspace to determine sound card and set config. > > But, beware that driver name is fairly short, it's a 16 bytes string. > The short name is 32 bytes and long name is 80 bytes. Thus, you need > a special care to provide a unique driver name. Ok, that is probably too short :( I've quickly rechecked the userspace API and we do have the functionality to read back the long name amongst other strings. It may be that we have to use the long name to specify further information. e.g. Pulseaudio could read the long name to determine the correct UCM file to load for Asus 100 (instead of loading the default BYT UCM which may or may not work on Asus T100). Liam _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [pulseaudio-discuss] ASoC and pulseaudio 2016-03-15 10:58 ` Liam Girdwood @ 2016-03-16 14:57 ` Vinod Koul 2016-03-16 15:09 ` [alsa-devel] " Mark Brown 2016-03-16 17:57 ` Liam Girdwood 0 siblings, 2 replies; 21+ messages in thread From: Vinod Koul @ 2016-03-16 14:57 UTC (permalink / raw) To: Liam Girdwood Cc: alsa-devel, General PulseAudio Discussion, Takashi Iwai, Mark Brown, han.lu, Linux Upstreaming Team On Tue, Mar 15, 2016 at 10:58:26AM +0000, Liam Girdwood wrote: > On Tue, 2016-03-15 at 10:56 +0100, Takashi Iwai wrote: > > On Tue, 15 Mar 2016 10:48:51 +0100, > > Liam Girdwood wrote: > > > > > > On Tue, 2016-03-15 at 09:55 +0100, Takashi Iwai wrote: > > > > On Tue, 15 Mar 2016 09:45:44 +0100, > > > > Mark Brown wrote: > > > > > > > > > > On Tue, Mar 15, 2016 at 06:01:28AM +0000, Liam Girdwood wrote: > > > > > > > > > > > 1) Shortname is board/machine name. This can come from DMI or device > > > > > > tree. e.g. "Asus T100" > > > > > > > > > > That seems more useful for users. > > > > > > > > > > > 2) Long name is 1 + driver name + optional firmware name. (I've just > > > > > > added the FW name here too as we can have potentially > 1 FW per driver > > > > > > - BYT is an example) e.g. "Asus T00: byt-rt5640: IntSST1.bin". > > > > > > > > > > Shouldn't we use whatever we use to figure out which firmware to load > > > > > rather than the firmware name? Someone might do something like try to > > > > > replace one firmware with another and get everything confused. > > > > > > > > > > This is not to load FW for our use case, the FW name is hard coded in > > > driver tables. We do have several FWs for the BYT driver that all have > > > different capabilities. Userspace could set the correct config for each > > > FW if it knew the FW that was being used. > > > > > > > I agree that a consistent name would be better. Though, practically > > > > seen, the long name isn't persistent with many drivers, as it often > > > > contains the irq or port numbers that are assigned dynamically. That > > > > said, the consistency of long name isn't strictly required. It's > > > > regarded rather as a verbose information to user, which shouldn't be > > > > used as an identifier key. > > > > > > > > OTOH, the driver name is the primary id key used by alsa-lib for its > > > > configuration. So this must be retained through versions and unique > > > > for each configuration. > > > > > > > > > > Ok, so we probably need to add in the board/machine name here (from DMI > > > or DT). We currently have several x86 machines all using the same codec > > > + DSP + FW, but all have slightly different clocking and routing that is > > > causing problems as userspace cannot configure correctly. > > > > > > > The short name is something between them. The alsa-lib USB-audio > > > > config file refers to the short name because the driver doesn't > > > > provide a unique id for driver_name for various workarounds. But it > > > > should be considered as an exception. Ideally, driver_name should be > > > > unique enough for each different configuration. > > > > > > So IIUC this would mean ? > > > > > > 1) short name is optional, but could be board name. > > > > Right. > > > > > 2) long name is driver_name plus any other optional information for the > > > user. Not used by applications or alsa-lib to determine sound card > > > capabilities. > > > > In most cases, long name is short name + more optional information. > > > > > 3) Driver name is unique. machine driver name + (optional) board name + > > > (optional) fw name. e.g. "byt-rt5640: Asus T100: IntSST1.bin" used by > > > alsa-lib and userspace to determine sound card and set config. > > > > But, beware that driver name is fairly short, it's a 16 bytes string. > > The short name is 32 bytes and long name is 80 bytes. Thus, you need > > a special care to provide a unique driver name. > > Ok, that is probably too short :( > > I've quickly rechecked the userspace API and we do have the > functionality to read back the long name amongst other strings. It may > be that we have to use the long name to specify further information. > > e.g. Pulseaudio could read the long name to determine the correct UCM > file to load for Asus 100 (instead of loading the default BYT UCM which > may or may not work on Asus T100). Okay catching up on this thread now.. So I don't think FW name would help, if required we should add dev_info to print the firmware which is getting loaded. Now, since we have topology we should comprehend that as well. The topology files essentially change the DSP graph and hence would required different UCM settings so that should be added to name too. Same hardware with different graph will need different settings.. And while thinking for it, I think it might be good to separate the SoC and codec settings and in UCM setting for card specify the combination. That may avoid duplicate codec setting all over the place for different combination. I don't know if UCM supports that... Thanks -- ~Vinod ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [alsa-devel] ASoC and pulseaudio 2016-03-16 14:57 ` [pulseaudio-discuss] " Vinod Koul @ 2016-03-16 15:09 ` Mark Brown 2016-03-16 15:17 ` Takashi Iwai 2016-03-16 17:57 ` Liam Girdwood 1 sibling, 1 reply; 21+ messages in thread From: Mark Brown @ 2016-03-16 15:09 UTC (permalink / raw) To: Vinod Koul Cc: alsa-devel, General PulseAudio Discussion, Takashi Iwai, han.lu, Linux Upstreaming Team [-- Attachment #1.1: Type: text/plain, Size: 413 bytes --] On Wed, Mar 16, 2016 at 08:27:04PM +0530, Vinod Koul wrote: > So I don't think FW name would help, if required we should add dev_info > to print the firmware which is getting loaded. We can't really be relying on userspace trawling through the logs - quite apart from anything else the message might be long gone by the time the relevant program gets started. Might be an idea to record it in sysfs somewhere? [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] [-- Attachment #2: Type: text/plain, Size: 187 bytes --] _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [alsa-devel] ASoC and pulseaudio 2016-03-16 15:09 ` [alsa-devel] " Mark Brown @ 2016-03-16 15:17 ` Takashi Iwai 2016-03-16 15:53 ` [pulseaudio-discuss] " Vinod Koul 2016-03-16 17:58 ` Liam Girdwood 0 siblings, 2 replies; 21+ messages in thread From: Takashi Iwai @ 2016-03-16 15:17 UTC (permalink / raw) To: Mark Brown Cc: alsa-devel, General PulseAudio Discussion, Vinod Koul, han.lu, Linux Upstreaming Team On Wed, 16 Mar 2016 16:09:49 +0100, Mark Brown wrote: > > On Wed, Mar 16, 2016 at 08:27:04PM +0530, Vinod Koul wrote: > > > So I don't think FW name would help, if required we should add dev_info > > to print the firmware which is getting loaded. > > We can't really be relying on userspace trawling through the logs - > quite apart from anything else the message might be long gone by the > time the relevant program gets started. > > Might be an idea to record it in sysfs somewhere? Yeah, that should be feasible. Also, there is a "component" field assigned to the card. This is supposed to be referred by user-space as additional information. See snd_component_add(). Takashi _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [pulseaudio-discuss] ASoC and pulseaudio 2016-03-16 15:17 ` Takashi Iwai @ 2016-03-16 15:53 ` Vinod Koul 2016-03-16 17:59 ` [alsa-devel] " Liam Girdwood 2016-03-16 17:58 ` Liam Girdwood 1 sibling, 1 reply; 21+ messages in thread From: Vinod Koul @ 2016-03-16 15:53 UTC (permalink / raw) To: Takashi Iwai Cc: alsa-devel, General PulseAudio Discussion, Liam Girdwood, Mark Brown, han.lu, Linux Upstreaming Team On Wed, Mar 16, 2016 at 04:17:02PM +0100, Takashi Iwai wrote: > On Wed, 16 Mar 2016 16:09:49 +0100, > Mark Brown wrote: > > > > On Wed, Mar 16, 2016 at 08:27:04PM +0530, Vinod Koul wrote: > > > > > So I don't think FW name would help, if required we should add dev_info > > > to print the firmware which is getting loaded. > > > > We can't really be relying on userspace trawling through the logs - > > quite apart from anything else the message might be long gone by the > > time the relevant program gets started. > > > > Might be an idea to record it in sysfs somewhere? Sounds good to me > Yeah, that should be feasible. Also, there is a "component" field > assigned to the card. This is supposed to be referred by user-space > as additional information. See snd_component_add(). Will add this to my ever growing list of things to do... :D -- ~Vinod ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [alsa-devel] ASoC and pulseaudio 2016-03-16 15:53 ` [pulseaudio-discuss] " Vinod Koul @ 2016-03-16 17:59 ` Liam Girdwood 2016-03-17 11:23 ` [pulseaudio-discuss] " Lu, Han 2016-03-17 11:28 ` [alsa-devel] " Lu, Han 0 siblings, 2 replies; 21+ messages in thread From: Liam Girdwood @ 2016-03-16 17:59 UTC (permalink / raw) To: Vinod Koul Cc: alsa-devel, General PulseAudio Discussion, Takashi Iwai, Mark Brown, han.lu, Linux Upstreaming Team On Wed, 2016-03-16 at 21:23 +0530, Vinod Koul wrote: > > > Yeah, that should be feasible. Also, there is a "component" field > > assigned to the card. This is supposed to be referred by user-space > > as additional information. See snd_component_add(). > > Will add this to my ever growing list of things to do... :D You don't have to :) It's on Han's list. Liam _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [pulseaudio-discuss] ASoC and pulseaudio 2016-03-16 17:59 ` [alsa-devel] " Liam Girdwood @ 2016-03-17 11:23 ` Lu, Han 2016-03-17 11:28 ` [alsa-devel] " Lu, Han 1 sibling, 0 replies; 21+ messages in thread From: Lu, Han @ 2016-03-17 11:23 UTC (permalink / raw) To: General PulseAudio Discussion, Koul, Vinod, liam.r.girdwood Cc: Takashi Iwai, alsa-devel, Mark Brown, Linux Upstreaming Team, han.lu > -----Original Message----- > From: pulseaudio-discuss [mailto:pulseaudio-discuss- > bounces@lists.freedesktop.org] On Behalf Of Liam Girdwood > Sent: Thursday, March 17, 2016 2:00 AM > To: Koul, Vinod <vinod.koul@intel.com> > Cc: alsa-devel@alsa-project.org; General PulseAudio Discussion <pulseaudio- > discuss@lists.freedesktop.org>; Takashi Iwai <tiwai@suse.de>; Mark Brown > <broonie@kernel.org>; han.lu <han.lu@linux.intel.com>; Linux Upstreaming > Team <linux@endlessm.com> > Subject: Re: [pulseaudio-discuss] [alsa-devel] ASoC and pulseaudio > > On Wed, 2016-03-16 at 21:23 +0530, Vinod Koul wrote: > > > > > > Yeah, that should be feasible. Also, there is a "component" field > > > assigned to the card. This is supposed to be referred by user-space > > > as additional information. See snd_component_add(). > > > > Will add this to my ever growing list of things to do... :D > > You don't have to :) > > It's on Han's list. > > Liam > I installed Ubuntu 14.04 to T100 and update the kernel to 4.5.0+ today, and I tested with a simple patch, which only added long_name in format "DMI_PRODUCT_NAME:card->name", and now in T100, command "cat /proc/sound/cards" will print 0 [bytcrrt5640 ]: bytcr-rt5640 - bytcr-rt5640 T100TA:bytcr-rt5640 Please find details below. I'll continue to add fw name. Or shall we use sysfs and snd_component_add instead? >From 511e6f6a606438a977d9e006c4629fa9b967d6a8 Mon Sep 17 00:00:00 2001 From: "Lu, Han" <han.lu@intel.com> Date: Thu, 17 Mar 2016 16:50:54 +0800 Subject: [PATCH RFC 1/1] Asoc: rt5640: add more machine/board information for user Add more machine/board information for PA and UCM. Signed-off-by: Lu, Han <han.lu@intel.com> diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index 032a2e7..9bd5e21 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -160,6 +160,12 @@ static int byt_rt5640_init(struct snd_soc_pcm_runtime *runtime) const struct snd_soc_dapm_route *custom_map; int num_routes; + if (!card->long_name) { + card->long_name = dmi_get_system_info(DMI_PRODUCT_NAME); + strcat((char *)card->long_name, ":"); + strcat((char *)card->long_name, card->name); + } + card->dapm.idle_bias_off = true; rt5640_sel_asrc_clk_src(codec, -- 2.5.0 BR, Han > > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [alsa-devel] ASoC and pulseaudio 2016-03-16 17:59 ` [alsa-devel] " Liam Girdwood 2016-03-17 11:23 ` [pulseaudio-discuss] " Lu, Han @ 2016-03-17 11:28 ` Lu, Han 2016-03-17 16:29 ` Vinod Koul 1 sibling, 1 reply; 21+ messages in thread From: Lu, Han @ 2016-03-17 11:28 UTC (permalink / raw) To: General PulseAudio Discussion, Koul, Vinod, liam.r.girdwood Cc: Takashi Iwai, alsa-devel, Mark Brown, Linux Upstreaming Team, han.lu Sorry, I manually wrapped lines but the format looks corrupted from my "sent" folder. Do you have any suggestions to avoid this? Thanks. BR, Han Lu > -----Original Message----- > From: Lu, Han > Sent: Thursday, March 17, 2016 7:23 PM > To: General PulseAudio Discussion <pulseaudio- > discuss@lists.freedesktop.org>; Koul, Vinod <vinod.koul@intel.com>; > liam.r.girdwood@linux.intel.com > Cc: alsa-devel@alsa-project.org; Takashi Iwai <tiwai@suse.de>; Mark Brown > <broonie@kernel.org>; han.lu <han.lu@linux.intel.com>; Linux Upstreaming > Team <linux@endlessm.com> > Subject: RE: [pulseaudio-discuss] [alsa-devel] ASoC and pulseaudio > > > -----Original Message----- > > From: pulseaudio-discuss [mailto:pulseaudio-discuss- > > bounces@lists.freedesktop.org] On Behalf Of Liam Girdwood > > Sent: Thursday, March 17, 2016 2:00 AM > > To: Koul, Vinod <vinod.koul@intel.com> > > Cc: alsa-devel@alsa-project.org; General PulseAudio Discussion > > <pulseaudio- discuss@lists.freedesktop.org>; Takashi Iwai > > <tiwai@suse.de>; Mark Brown <broonie@kernel.org>; han.lu > > <han.lu@linux.intel.com>; Linux Upstreaming Team <linux@endlessm.com> > > Subject: Re: [pulseaudio-discuss] [alsa-devel] ASoC and pulseaudio > > > > On Wed, 2016-03-16 at 21:23 +0530, Vinod Koul wrote: > > > > > > > > > Yeah, that should be feasible. Also, there is a "component" field > > > > assigned to the card. This is supposed to be referred by > > > > user-space as additional information. See snd_component_add(). > > > > > > Will add this to my ever growing list of things to do... :D > > > > You don't have to :) > > > > It's on Han's list. > > > > Liam > > > > I installed Ubuntu 14.04 to T100 and update the kernel to 4.5.0+ today, and I > tested with a simple patch, which only added long_name in format > "DMI_PRODUCT_NAME:card->name", and now in T100, command "cat > /proc/sound/cards" will print > 0 [bytcrrt5640 ]: bytcr-rt5640 - bytcr-rt5640 > T100TA:bytcr-rt5640 Please find details below. I'll continue > to add fw name. > Or shall we use sysfs and snd_component_add instead? > > From 511e6f6a606438a977d9e006c4629fa9b967d6a8 Mon Sep 17 00:00:00 > 2001 > From: "Lu, Han" <han.lu@intel.com> > Date: Thu, 17 Mar 2016 16:50:54 +0800 > Subject: [PATCH RFC 1/1] Asoc: rt5640: add more machine/board information > for user > > Add more machine/board information for PA and UCM. > > Signed-off-by: Lu, Han <han.lu@intel.com> > > diff --git a/sound/soc/intel/boards/bytcr_rt5640.c > b/sound/soc/intel/boards/bytcr_rt5640.c > index 032a2e7..9bd5e21 100644 > --- a/sound/soc/intel/boards/bytcr_rt5640.c > +++ b/sound/soc/intel/boards/bytcr_rt5640.c > @@ -160,6 +160,12 @@ static int byt_rt5640_init(struct > snd_soc_pcm_runtime > *runtime) > const struct snd_soc_dapm_route *custom_map; > int num_routes; > > + if (!card->long_name) { > + card->long_name = dmi_get_system_info(DMI_PRODUCT_NAME); > + strcat((char *)card->long_name, ":"); > + strcat((char *)card->long_name, card->name); > + } > + > card->dapm.idle_bias_off = true; > > rt5640_sel_asrc_clk_src(codec, > -- > 2.5.0 > > BR, > Han > > > > _______________________________________________ > > pulseaudio-discuss mailing list > > pulseaudio-discuss@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [alsa-devel] ASoC and pulseaudio 2016-03-17 11:28 ` [alsa-devel] " Lu, Han @ 2016-03-17 16:29 ` Vinod Koul 0 siblings, 0 replies; 21+ messages in thread From: Vinod Koul @ 2016-03-17 16:29 UTC (permalink / raw) To: Lu, Han Cc: alsa-devel, General PulseAudio Discussion, Takashi Iwai, Mark Brown, han.lu, Linux Upstreaming Team On Thu, Mar 17, 2016 at 04:58:11PM +0530, Lu, Han wrote: > Sorry, I manually wrapped lines but the format looks corrupted from my "sent" > folder. Do you have any suggestions to avoid this? Thanks. Yes, don't use M$ tools to send Linux Code :) You can use evolution, mutt or any other tool, they work well with our corporate accounts... > > BR, > Han Lu > > > > -----Original Message----- > > From: Lu, Han > > Sent: Thursday, March 17, 2016 7:23 PM > > To: General PulseAudio Discussion <pulseaudio- > > discuss@lists.freedesktop.org>; Koul, Vinod <vinod.koul@intel.com>; > > liam.r.girdwood@linux.intel.com > > Cc: alsa-devel@alsa-project.org; Takashi Iwai <tiwai@suse.de>; Mark Brown > > <broonie@kernel.org>; han.lu <han.lu@linux.intel.com>; Linux Upstreaming > > Team <linux@endlessm.com> > > Subject: RE: [pulseaudio-discuss] [alsa-devel] ASoC and pulseaudio > > > > > -----Original Message----- > > > From: pulseaudio-discuss [mailto:pulseaudio-discuss- > > > bounces@lists.freedesktop.org] On Behalf Of Liam Girdwood > > > Sent: Thursday, March 17, 2016 2:00 AM > > > To: Koul, Vinod <vinod.koul@intel.com> > > > Cc: alsa-devel@alsa-project.org; General PulseAudio Discussion > > > <pulseaudio- discuss@lists.freedesktop.org>; Takashi Iwai > > > <tiwai@suse.de>; Mark Brown <broonie@kernel.org>; han.lu > > > <han.lu@linux.intel.com>; Linux Upstreaming Team <linux@endlessm.com> > > > Subject: Re: [pulseaudio-discuss] [alsa-devel] ASoC and pulseaudio > > > > > > On Wed, 2016-03-16 at 21:23 +0530, Vinod Koul wrote: > > > > > > > > > > > > Yeah, that should be feasible. Also, there is a "component" field > > > > > assigned to the card. This is supposed to be referred by > > > > > user-space as additional information. See snd_component_add(). > > > > > > > > Will add this to my ever growing list of things to do... :D > > > > > > You don't have to :) > > > > > > It's on Han's list. > > > > > > Liam > > > > > > > I installed Ubuntu 14.04 to T100 and update the kernel to 4.5.0+ today, and I > > tested with a simple patch, which only added long_name in format > > "DMI_PRODUCT_NAME:card->name", and now in T100, command "cat > > /proc/sound/cards" will print > > 0 [bytcrrt5640 ]: bytcr-rt5640 - bytcr-rt5640 > > T100TA:bytcr-rt5640 Please find details below. I'll continue > > to add fw name. > > Or shall we use sysfs and snd_component_add instead? > > > > From 511e6f6a606438a977d9e006c4629fa9b967d6a8 Mon Sep 17 00:00:00 > > 2001 > > From: "Lu, Han" <han.lu@intel.com> > > Date: Thu, 17 Mar 2016 16:50:54 +0800 > > Subject: [PATCH RFC 1/1] Asoc: rt5640: add more machine/board information > > for user > > > > Add more machine/board information for PA and UCM. > > > > Signed-off-by: Lu, Han <han.lu@intel.com> > > > > diff --git a/sound/soc/intel/boards/bytcr_rt5640.c > > b/sound/soc/intel/boards/bytcr_rt5640.c > > index 032a2e7..9bd5e21 100644 > > --- a/sound/soc/intel/boards/bytcr_rt5640.c > > +++ b/sound/soc/intel/boards/bytcr_rt5640.c > > @@ -160,6 +160,12 @@ static int byt_rt5640_init(struct > > snd_soc_pcm_runtime > > *runtime) > > const struct snd_soc_dapm_route *custom_map; > > int num_routes; > > > > + if (!card->long_name) { > > + card->long_name = dmi_get_system_info(DMI_PRODUCT_NAME); > > + strcat((char *)card->long_name, ":"); > > + strcat((char *)card->long_name, card->name); > > + } > > + > > card->dapm.idle_bias_off = true; > > > > rt5640_sel_asrc_clk_src(codec, > > -- > > 2.5.0 > > > > BR, > > Han > > > > > > _______________________________________________ > > > pulseaudio-discuss mailing list > > > pulseaudio-discuss@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- ~Vinod _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [alsa-devel] ASoC and pulseaudio 2016-03-16 15:17 ` Takashi Iwai 2016-03-16 15:53 ` [pulseaudio-discuss] " Vinod Koul @ 2016-03-16 17:58 ` Liam Girdwood 1 sibling, 0 replies; 21+ messages in thread From: Liam Girdwood @ 2016-03-16 17:58 UTC (permalink / raw) To: Takashi Iwai Cc: alsa-devel, General PulseAudio Discussion, Vinod Koul, Mark Brown, han.lu, Linux Upstreaming Team On Wed, 2016-03-16 at 16:17 +0100, Takashi Iwai wrote: > On Wed, 16 Mar 2016 16:09:49 +0100, > Mark Brown wrote: > > > > On Wed, Mar 16, 2016 at 08:27:04PM +0530, Vinod Koul wrote: > > > > > So I don't think FW name would help, if required we should add dev_info > > > to print the firmware which is getting loaded. > > > > We can't really be relying on userspace trawling through the logs - > > quite apart from anything else the message might be long gone by the > > time the relevant program gets started. > > > > Might be an idea to record it in sysfs somewhere? > > Yeah, that should be feasible. Also, there is a "component" field > assigned to the card. This is supposed to be referred by user-space > as additional information. See snd_component_add(). > We could also probably put FW versions in sysfs too. Useful for bugs. Liam _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [alsa-devel] ASoC and pulseaudio 2016-03-16 14:57 ` [pulseaudio-discuss] " Vinod Koul 2016-03-16 15:09 ` [alsa-devel] " Mark Brown @ 2016-03-16 17:57 ` Liam Girdwood 1 sibling, 0 replies; 21+ messages in thread From: Liam Girdwood @ 2016-03-16 17:57 UTC (permalink / raw) To: Vinod Koul Cc: alsa-devel, General PulseAudio Discussion, Takashi Iwai, Mark Brown, han.lu, Linux Upstreaming Team On Wed, 2016-03-16 at 20:27 +0530, Vinod Koul wrote: > Okay catching up on this thread now.. > > So I don't think FW name would help, if required we should add dev_info > to print the firmware which is getting loaded. > > Now, since we have topology we should comprehend that as well. The > topology files essentially change the DSP graph and hence would required > different UCM settings so that should be added to name too. Same > hardware with different graph will need different settings.. > > And while thinking for it, I think it might be good to separate the SoC > and codec settings and in UCM setting for card specify the combination. > That may avoid duplicate codec setting all over the place for different > combination. I don't know if UCM supports that... That's the plan :) The intention is to make UCM machine specific rather than driver specific configuration. Han is going to add #include and #define like support to UCM in order to facilitate a library of codec UCM files that can be included into machine UCM configs. Liam > > Thanks _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: ASoC and pulseaudio 2016-03-15 9:48 ` Liam Girdwood 2016-03-15 9:56 ` Takashi Iwai @ 2016-03-15 10:00 ` Mark Brown 2016-03-15 10:48 ` [alsa-devel] " Liam Girdwood 1 sibling, 1 reply; 21+ messages in thread From: Mark Brown @ 2016-03-15 10:00 UTC (permalink / raw) To: Liam Girdwood Cc: Takashi Iwai, alsa-devel, Linux Upstreaming Team, General PulseAudio Discussion, han.lu [-- Attachment #1.1: Type: text/plain, Size: 1411 bytes --] On Tue, Mar 15, 2016 at 09:48:51AM +0000, Liam Girdwood wrote: > On Tue, 2016-03-15 at 09:55 +0100, Takashi Iwai wrote: > > > Shouldn't we use whatever we use to figure out which firmware to load > > > rather than the firmware name? Someone might do something like try to > > > replace one firmware with another and get everything confused. > This is not to load FW for our use case, the FW name is hard coded in It's not for loading, it's because the firmware name we requested may not be the firmware that actually got loaded. > driver tables. We do have several FWs for the BYT driver that all have > different capabilities. Userspace could set the correct config for each > FW if it knew the FW that was being used. Is the firmware configuration sufficiently reusable between boards or could that just be figured out in userspace? > > The short name is something between them. The alsa-lib USB-audio > > config file refers to the short name because the driver doesn't > > provide a unique id for driver_name for various workarounds. But it > > should be considered as an exception. Ideally, driver_name should be > > unique enough for each different configuration. > So IIUC this would mean ? > 1) short name is optional, but could be board name. I'd not make it optional, the long names tend to be on the verbose side so applications do seem to use the short name for user rendering purposes. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] [-- Attachment #2: Type: text/plain, Size: 187 bytes --] _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [alsa-devel] ASoC and pulseaudio 2016-03-15 10:00 ` Mark Brown @ 2016-03-15 10:48 ` Liam Girdwood 0 siblings, 0 replies; 21+ messages in thread From: Liam Girdwood @ 2016-03-15 10:48 UTC (permalink / raw) To: Mark Brown Cc: Takashi Iwai, alsa-devel, Linux Upstreaming Team, General PulseAudio Discussion, han.lu On Tue, 2016-03-15 at 10:00 +0000, Mark Brown wrote: > On Tue, Mar 15, 2016 at 09:48:51AM +0000, Liam Girdwood wrote: > > On Tue, 2016-03-15 at 09:55 +0100, Takashi Iwai wrote: > > > > > Shouldn't we use whatever we use to figure out which firmware to load > > > > rather than the firmware name? Someone might do something like try to > > > > replace one firmware with another and get everything confused. > > > This is not to load FW for our use case, the FW name is hard coded in > > It's not for loading, it's because the firmware name we requested may > not be the firmware that actually got loaded. > > > driver tables. We do have several FWs for the BYT driver that all have > > different capabilities. Userspace could set the correct config for each > > FW if it knew the FW that was being used. > > Is the firmware configuration sufficiently reusable between boards or > could that just be figured out in userspace? This depends on the FW. Some are quite reusable (i.e. use SSP0 instead of SSP1), but others have could require additional config. This should not be a problem for the newer FWs though that use topology though. Liam _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2016-03-17 16:29 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAL9uMOHRjcCJomr6zzR0ySh384AVj1FRvASZSp3KsPqfeS8Lzw@mail.gmail.com> [not found] ` <56C8AEFD.4060808@linux.intel.com> [not found] ` <1456225994.6424.35.camel@loki> [not found] ` <B51200AC81AB024499A3C2C9A1BB90A83D3AABF9@SHSMSX101.ccr.corp.intel.com> 2016-03-14 8:19 ` ASoC and pulseaudio Liam Girdwood 2016-03-14 15:23 ` [alsa-devel] " Pierre-Louis Bossart 2016-03-14 16:06 ` Mark Brown 2016-03-15 6:01 ` Liam Girdwood 2016-03-15 8:45 ` Mark Brown 2016-03-15 8:55 ` Takashi Iwai 2016-03-15 9:48 ` Liam Girdwood 2016-03-15 9:56 ` Takashi Iwai 2016-03-15 10:58 ` Liam Girdwood 2016-03-16 14:57 ` [pulseaudio-discuss] " Vinod Koul 2016-03-16 15:09 ` [alsa-devel] " Mark Brown 2016-03-16 15:17 ` Takashi Iwai 2016-03-16 15:53 ` [pulseaudio-discuss] " Vinod Koul 2016-03-16 17:59 ` [alsa-devel] " Liam Girdwood 2016-03-17 11:23 ` [pulseaudio-discuss] " Lu, Han 2016-03-17 11:28 ` [alsa-devel] " Lu, Han 2016-03-17 16:29 ` Vinod Koul 2016-03-16 17:58 ` Liam Girdwood 2016-03-16 17:57 ` Liam Girdwood 2016-03-15 10:00 ` Mark Brown 2016-03-15 10:48 ` [alsa-devel] " Liam Girdwood
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.