Re: ASoC and pulseaudio

Re: ASoC and pulseaudio

[Liam Girdwood]

+ 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

Re: [alsa-devel] ASoC and pulseaudio

[Pierre-Louis Bossart]

[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

Re: ASoC and pulseaudio

[Mark Brown]

[-- 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

Re: ASoC and pulseaudio

[Liam Girdwood]

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

Re: ASoC and pulseaudio

[Mark Brown]

[-- 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

Re: ASoC and pulseaudio

[Takashi Iwai]

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

Re: ASoC and pulseaudio

[Liam Girdwood]

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

Re: ASoC and pulseaudio

[Takashi Iwai]

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

Re: ASoC and pulseaudio

[Mark Brown]

[-- 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

Re: [alsa-devel] ASoC and pulseaudio

[Liam Girdwood]

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

Re: ASoC and pulseaudio

[Liam Girdwood]

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

Re: [pulseaudio-discuss] ASoC and pulseaudio

[Vinod Koul]

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

Re: [alsa-devel] ASoC and pulseaudio

[Mark Brown]

[-- 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

Re: [alsa-devel] ASoC and pulseaudio

[Takashi Iwai]

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

Re: [pulseaudio-discuss] ASoC and pulseaudio

[Vinod Koul]

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

Re: [alsa-devel] ASoC and pulseaudio

[Liam Girdwood]

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

Re: [alsa-devel] ASoC and pulseaudio

[Liam Girdwood]

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

Re: [alsa-devel] ASoC and pulseaudio

[Liam Girdwood]

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

Re: [pulseaudio-discuss] ASoC and pulseaudio

[Lu, Han]

> -----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

Re: [alsa-devel] ASoC and pulseaudio

[Lu, Han]

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

Re: [alsa-devel] ASoC and pulseaudio

[Vinod Koul]

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