Re: [alsa-devel] [pulseaudio-discuss] ASoC and pulseaudio
+ 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
[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.
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.
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
On Tue, Mar 15, 2016 at 06:01:28AM +0000, Liam Girdwood wrote:
- Shortname is board/machine name. This can come from DMI or device
tree. e.g. "Asus T100"
That seems more useful for users.
- 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.
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:
- Shortname is board/machine name. This can come from DMI or device
tree. e.g. "Asus T100"
That seems more useful for users.
- 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
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:
- Shortname is board/machine name. This can come from DMI or device
tree. e.g. "Asus T100"
That seems more useful for users.
- 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
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:
- Shortname is board/machine name. This can come from DMI or device
tree. e.g. "Asus T100"
That seems more useful for users.
- 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 ?
- short name is optional, but could be board name.
Right.
- 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.
- 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
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:
- Shortname is board/machine name. This can come from DMI or device
tree. e.g. "Asus T100"
That seems more useful for users.
- 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 ?
- short name is optional, but could be board name.
Right.
- 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.
- 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
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:
- Shortname is board/machine name. This can come from DMI or device
tree. e.g. "Asus T100"
That seems more useful for users.
- 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 ?
- short name is optional, but could be board name.
Right.
- 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.
- 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
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?
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
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
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
-----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
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
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
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
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
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 ?
- 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.
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
participants (6)
-
Liam Girdwood -
Lu, Han -
Mark Brown -
Pierre-Louis Bossart -
Takashi Iwai -
Vinod Koul