October 2020 - Alsa-devel - mailman.alsa-project.org

[PATCH] ASoC: Intel: atom: Remove duplicate kconfigs
by Cezary Rojewski 14 Oct '20

14 Oct '20

SND_SST_IPC and its _PCI and _ACPI variants all target sound/soc/intel/atom solution alone. SND_SST_IPC is the core component, required for PCI and ACPI based atom platforms both. _PCI and _ACPI target Merrifield/Edison and Baytrial/Cherrytrail platforms respectively. On top of that, there is an equivalent set of configs targeting the same solution: - SND_SST_ATOM_HIFI2_PLATFORM (core) - SND_SST_ATOM_HIFI2_PLATFORM_PCI - SND_SST_ATOM_HIFI2_PLATFORM_ACPI As both sets do the same job - allow for granular platform selection - remove the duplicate set and rely on SND_SST_ATOM_HIFI2_PLATOFRM_XXX configs alone. Signed-off-by: Cezary Rojewski <cezary.rojewski(a)intel.com> --- sound/soc/intel/Kconfig | 18 ------------------ sound/soc/intel/atom/Makefile | 2 +- sound/soc/intel/atom/sst/Makefile | 6 +++--- 3 files changed, 4 insertions(+), 22 deletions(-) diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index d5bae5d1ab6f..a5b446d5af19 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -15,22 +15,6 @@ config SND_SOC_INTEL_SST_TOPLEVEL if SND_SOC_INTEL_SST_TOPLEVEL -config SND_SST_IPC - tristate - # This option controls the IPC core for HiFi2 platforms - -config SND_SST_IPC_PCI - tristate - select SND_SST_IPC - # This option controls the PCI-based IPC for HiFi2 platforms - # (Medfield, Merrifield). - -config SND_SST_IPC_ACPI - tristate - select SND_SST_IPC - # This option controls the ACPI-based IPC for HiFi2 platforms - # (Baytrail, Cherrytrail) - config SND_SOC_INTEL_SST tristate @@ -57,7 +41,6 @@ config SND_SST_ATOM_HIFI2_PLATFORM config SND_SST_ATOM_HIFI2_PLATFORM_PCI tristate "PCI HiFi2 (Merrifield) Platforms" depends on X86 && PCI - select SND_SST_IPC_PCI select SND_SST_ATOM_HIFI2_PLATFORM help If you have a Intel Merrifield/Edison platform, then @@ -70,7 +53,6 @@ config SND_SST_ATOM_HIFI2_PLATFORM_ACPI tristate "ACPI HiFi2 (Baytrail, Cherrytrail) Platforms" default ACPI depends on X86 && ACPI && PCI - select SND_SST_IPC_ACPI select SND_SST_ATOM_HIFI2_PLATFORM select SND_SOC_ACPI_INTEL_MATCH select IOSF_MBI diff --git a/sound/soc/intel/atom/Makefile b/sound/soc/intel/atom/Makefile index a9326d5ec44c..c66f03f5d8d6 100644 --- a/sound/soc/intel/atom/Makefile +++ b/sound/soc/intel/atom/Makefile @@ -6,4 +6,4 @@ snd-soc-sst-atom-hifi2-platform-objs := sst-mfld-platform-pcm.o \ obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM) += snd-soc-sst-atom-hifi2-platform.o # DSP driver -obj-$(CONFIG_SND_SST_IPC) += sst/ +obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM) += sst/ diff --git a/sound/soc/intel/atom/sst/Makefile b/sound/soc/intel/atom/sst/Makefile index f17c905df3e2..5761d30a5f9d 100644 --- a/sound/soc/intel/atom/sst/Makefile +++ b/sound/soc/intel/atom/sst/Makefile @@ -3,6 +3,6 @@ snd-intel-sst-core-objs := sst.o sst_ipc.o sst_stream.o sst_drv_interface.o sst_ snd-intel-sst-pci-objs += sst_pci.o snd-intel-sst-acpi-objs += sst_acpi.o -obj-$(CONFIG_SND_SST_IPC) += snd-intel-sst-core.o -obj-$(CONFIG_SND_SST_IPC_PCI) += snd-intel-sst-pci.o -obj-$(CONFIG_SND_SST_IPC_ACPI) += snd-intel-sst-acpi.o +obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM) += snd-intel-sst-core.o +obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_PCI) += snd-intel-sst-pci.o +obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI) += snd-intel-sst-acpi.o -- 2.17.1

3 2

[PATCH 1/2] ASoC: Intel: catpt: Wake up device before configuring SSP port
by Cezary Rojewski 14 Oct '20

14 Oct '20

catpt_dai_pcm_new() invoked during new PCM runtime creation configures SSP by sending IPC to DSP firmware. For that to succeed device needs to be up and running. While components default probing behavior - snd_soc_catpt causing machine board module to load just after it - needs no changes, machine board's module may be unloaded and re-loaded at a different time e.g.: when catpt is already asleep. Wake device explicitly in catpt_dai_pcm_new() to ensure communication is established before sending any IPCs, enabling those advanced scenarios in the process. Signed-off-by: Cezary Rojewski <cezary.rojewski(a)intel.com> --- In short, this allows for following scenario (which user usually do not touch): 1. modprobe snd_soc_catpt // core driver 2. modprobe snd_soc_sst_broadwell // machine board driver 3. wait for snd_soc_catpt to suspend (~2s) 4. rmmod snd_soc_sst_broadwell 5. modprobe snd_soc_sst_broadwell Without the 3. everything works just fine but let's be more flexible here. Right now, -110 (timeout) will occur as device will simply be asleep. To allow for this advanced scenario, pm_runtime manipulation is required. memcmp check is to prevent unnecessary operations from occurring. sound/soc/intel/catpt/pcm.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sound/soc/intel/catpt/pcm.c b/sound/soc/intel/catpt/pcm.c index f78018c857b8..ba653ebea7d1 100644 --- a/sound/soc/intel/catpt/pcm.c +++ b/sound/soc/intel/catpt/pcm.c @@ -667,7 +667,17 @@ static int catpt_dai_pcm_new(struct snd_soc_pcm_runtime *rtm, break; } + /* see if this is a new configuration */ + if (!memcmp(&cdev->devfmt[devfmt.iface], &devfmt, sizeof(devfmt))) + return 0; + + pm_runtime_get_sync(cdev->dev); + ret = catpt_ipc_set_device_format(cdev, &devfmt); + + pm_runtime_mark_last_busy(cdev->dev); + pm_runtime_put_autosuspend(cdev->dev); + if (ret) return CATPT_IPC_ERROR(ret); -- 2.17.1

2 2

[PATCH 0/3] ASoC: sof: cleanup Kconfig files
by Randy Dunlap 14 Oct '20

14 Oct '20

Cc: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Cc: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Cc: Daniel Baluta <daniel.baluta(a)nxp.com> Cc: sound-open-firmware(a)alsa-project.org Cc: alsa-devel(a)alsa-project.org Some general editing of sound/soc/sof/ Kconfig files: [PATCH 1/3] ASoC: sof: imx: fix Kconfig punctuation [PATCH 2/3] ASoC: sof: intel: fix Kconfig punctuation and wording [PATCH 3/3] ASoC: sof: Kconfig: fix Kconfig punctuation and wording sound/soc/sof/Kconfig | 42 +++++++++++------------ sound/soc/sof/imx/Kconfig | 10 ++--- sound/soc/sof/intel/Kconfig | 62 +++++++++++++++++----------------- 3 files changed, 57 insertions(+), 57 deletions(-)

2 5

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Pavel Machek 14 Oct '20

14 Oct '20

On Wed 2020-10-14 10:22:01, Udo van den Heuvel wrote: > On 14-10-2020 10:11, Pavel Machek wrote: > >> It's a computer, not a disco-light or anything like that. > > > > And you probably have numlock LED. > > On the case? no way. > It is on the keyboard, a separate device, and already has a function. > We also have a caps lock LED and scroll lock LED there, with separate > functions. > I do not need 'extra' functionality for those. > > > Additional config options have costs, too, and we don't want to > > support gazillion config options. > > That is not the issue. > One should have thought about stuff beforehand. We did. And decided this is best solution. > The non-selectability is not my fault. It also does not affect you in any way. Feel free to go to the mic LED discussion to see why we did it like this. Then you can come up with better solution for problem at hand. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

1 0

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Randy Dunlap 14 Oct '20

14 Oct '20

On 10/13/20 10:16 PM, Udo van den Heuvel wrote: > On 14-10-2020 07:07, Randy Dunlap wrote: >> On 10/13/20 9:56 PM, Udo van den Heuvel wrote: > >>> I.e.: it looks like I will lose some funcionality when I disable >>> SND_HDA_CODEC_REALTEK. >> >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK >> with no LEDS. That driver apparently wants LEDS. > > Thanks but why have I gone for years without LEDS? > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are > visible, usable, etc). > > Please make this selectable instead of forcing more bulk into my kernel. > > Kind regards, > Udo Hi Takashi, Regarding commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc Author: Takashi Iwai <tiwai(a)suse.de> Date: Thu Jun 18 13:08:31 2020 +0200 ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev and this Kconfig entry: config SND_HDA_CODEC_REALTEK tristate "Build Realtek HD-audio codec support" select SND_HDA_GENERIC select SND_HDA_GENERIC_LEDS it seems that LED support is not always wanted (please see above). I.e., user(s) would like to build a kernel without LED support at all. Can you make it a build option? thanks. -- ~Randy

3 8

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Pavel Machek 14 Oct '20

14 Oct '20

On Wed 2020-10-14 10:05:42, Udo van den Heuvel wrote: > On 14-10-2020 09:58, Pavel Machek wrote: > > Contrary to his claims, Udo very probably has LEDs in his systems... > > We have a visible power LED. > WE have a HDD LED. > The board has LEDs, yes, but the SilverStone Fortress FT02 hides them > fairly well. > I did not ask for LEDs nor need them this way. > It's a computer, not a disco-light or anything like that. And you probably have numlock LED. > Whether the code is big or not does not matter, it is a matter of being > able to select what one needs without getting bothered with other code > that will do nothing. No. Additional config options have costs, too, and we don't want to support gazillion config options. LED core should be small enough that it does not matter. Sound was inventing its own "tiny LED core" before. > So please consider. I did. Answer is no. Please accept it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

1 0

[PATCH 1/2] Asoc: qcom: lpass-cpu: Fix clock disable failure
by Srinivasa Rao Mandadapu 14 Oct '20

14 Oct '20

From: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Disable MI2S bit clock from PAUSE/STOP/SUSPEND usecase instead of shutdown time. Acheive this by invoking clk_disable_unprepare API from cpu daiops shutdown to cpu daiops trigger. This Fix is update to the below patch. https://lore.kernel.org/patchwork/patch/1308101/ Signed-off-by: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Signed-off-by: Srinivasa Rao Mandadapu <srivasam(a)codeaurora.org> --- sound/soc/qcom/lpass-cpu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c index ba2aca3..2dfb921 100644 --- a/sound/soc/qcom/lpass-cpu.c +++ b/sound/soc/qcom/lpass-cpu.c @@ -88,8 +88,6 @@ static void lpass_cpu_daiops_shutdown(struct snd_pcm_substream *substream, { struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai); - clk_disable_unprepare(drvdata->mi2s_bit_clk[dai->driver->id]); - clk_disable_unprepare(drvdata->mi2s_osr_clk[dai->driver->id]); } @@ -324,6 +322,7 @@ static int lpass_cpu_daiops_trigger(struct snd_pcm_substream *substream, if (ret) dev_err(dai->dev, "error writing to i2sctl reg: %d\n", ret); + clk_disable_unprepare(drvdata->mi2s_bit_clk[dai->driver->id]); break; } -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

2 2

Accessing pending hw_params in SND_PCM_HOOK_TYPE_HW_PARAMS call back
by alsa＠scripple.org 13 Oct '20

13 Oct '20

Hello, I'll try again with a more specific question. Is there a way one can access the hw_params that cause the SND_PCM_HOOK_TYPE_HW_PARAMS call back to be called inside the call back function? The hook only provides access to the snd_pcm_t object, but all the public calls to get hw_params fail because it's not in a prepared state yet. If there isn't a way to get them now could we please add the ability with a patch like the one below? With this patch a call to snd_pcm_hook_get_hw_params provides access to the pending hw_params structure and the pending parameters can be accessed with standard calls like snd_pcm_hw_params_get_channels. Hopefully I'm just missing how to get them without the patch, but if not they really should be made accessible. diff --git a/alsa-lib-1.1.8/include/pcm.h b/pcm.h index 5b07823..0cf5dca 100644 --- a/alsa-lib-1.1.8/include/pcm.h +++ b/pcm.h @@ -1181,6 +1181,7 @@ typedef struct _snd_pcm_hook snd_pcm_hook_t; /** PCM hook callback function */ typedef int (*snd_pcm_hook_func_t)(snd_pcm_hook_t *hook); snd_pcm_t *snd_pcm_hook_get_pcm(snd_pcm_hook_t *hook); +snd_pcm_hw_params_t *snd_pcm_hook_get_hw_params(snd_pcm_hook_t *hook); void *snd_pcm_hook_get_private(snd_pcm_hook_t *hook); void snd_pcm_hook_set_private(snd_pcm_hook_t *hook, void *private_data); int snd_pcm_hook_add(snd_pcm_hook_t **hookp, snd_pcm_t *pcm, diff --git a/alsa-lib-1.1.8/src/pcm/pcm_hooks.c b/pcm_hooks.c index 4416d36..f56c3af 100644 --- a/alsa-lib-1.1.8/src/pcm/pcm_hooks.c +++ b/pcm_hooks.c @@ -38,6 +38,7 @@ const char *_snd_module_pcm_hooks = ""; #ifndef DOC_HIDDEN struct _snd_pcm_hook { snd_pcm_t *pcm; + snd_pcm_hw_params_t *params; snd_pcm_hook_func_t func; void *private_data; struct list_head list; @@ -117,6 +118,7 @@ static int snd_pcm_hooks_hw_params(snd_pcm_t *pcm, snd_pcm_hw_params_t *params) return err; list_for_each_safe(pos, next, &h->hooks[SND_PCM_HOOK_TYPE_HW_PARAMS]) { snd_pcm_hook_t *hook = list_entry(pos, snd_pcm_hook_t, list); + hook->params = params; err = hook->func(hook); if (err < 0) return err; @@ -563,6 +565,17 @@ snd_pcm_t *snd_pcm_hook_get_pcm(snd_pcm_hook_t *hook) return hook->pcm; } +/** + * \brief Get hw_params handle for a PCM hook + * \param hook PCM hook handle + * \return hw_params handle + */ +snd_pcm_hw_params_t *snd_pcm_hook_get_hw_params(snd_pcm_hook_t *hook) +{ + assert(hook); + return hook->params; +} + /** * \brief Get callback function private data for a PCM hook * \param hook PCM hook handle @@ -609,6 +622,7 @@ int snd_pcm_hook_add(snd_pcm_hook_t **hookp, snd_pcm_t *pcm, if (!h) return -ENOMEM; h->pcm = pcm; + h->params = NULL; h->func = func; h->private_data = private_data; hooks = pcm->private_data;

1 0

[PATCH v2 0/6] Ancillary bus implementation and SOF multi-client support
by Dave Ertman 13 Oct '20

13 Oct '20

Version 2 of this patchset is being pushed out when there are still some issues up in the air. This push, along with the changes in the change log below, is to fix the broken distribution among mailing lists and individuals of the first version submission. At least two items still under discussion are: Final name for the bus Documentation of sysfs directories Brief history of Ancillary Bus ============================== The ancillary bus code was originally submitted upstream as virtual bus, and was submitted through the netdev tree.  This process generated up to v4.  This discussion can be found here: https://lore.kernel.org/netdev/20191111192219.30259-1-jeffrey.t.kirsher@int… At this point, GregKH requested that we take the review and revision process to an internal mailing list and garner the buy-in of a respected kernel contributor. The ancillary bus (then known as virtual bus) was originally submitted along with implementation code for the ice driver and irdma drive, causing the complication of also having dependencies in the rdma tree. This new submission is utilizing an ancillary bus consumer in only the sound driver tree to create the initial implementation and a single user. Since implementation work has started on this patch set, there have been multiple inquiries about the time frame of its completion. It appears that there will be numerous consumers of this functionality. The process of internal review and implementation using the sound drivers generated 19 internal versions.  The changes, including the name change from virtual bus to ancillary bus, from these versions can be summarized as the following: - Fixed compilation and checkpatch errors - Improved documentation to address the motivation for virtual bus. - Renamed virtual bus to ancillary bus - increased maximum device name size - Correct order in Kconfig and Makefile - removed the mid-layer adev->release layer for device unregister - pushed adev->id management to parent driver - all error paths out of ancillary_device_register return error code - all error paths out of ancillary_device_register use put_device - added adev->name element - modname in register cannot be NULL - added KBUILD_MODNAME as prefix for match_name - push adev->id responsibility to registering driver - uevent now parses adev->dev name - match_id function now parses adev->dev name - changed drivers probe function to also take an ancillary_device_id param - split ancillary_device_register into device_initialize and device_add - adjusted what is done in device_initialize and device_add - change adev to ancildev and adrv to ancildrv - change adev to ancildev in documentation ========================== Introduces the ancillary bus implementation along with the example usage in the Sound Open Firmware(SOF) audio driver. In some subsystems, the functionality of the core device (PCI/ACPI/other) may be too complex for a single device to be managed as a monolithic block or a part of the functionality might need to be exposed to a different subsystem. Splitting the functionality into smaller orthogonal devices makes it easier to manage data, power management and domain-specific communication with the hardware. Also, common ancillary_device functionality across primary devices can be handled by a common ancillary_device. A key requirement for such a split is that there is no dependency on a physical bus, device, register accesses or regmap support. These individual devices split from the core cannot live on the platform bus as they are not physical devices that are controlled by DT/ACPI. The same argument applies for not using MFD in this scenario as it relies on individual function devices being physical devices that are DT enumerated. An example for this kind of requirement is the audio subsystem where a single IP handles multiple entities such as HDMI, Soundwire, local devices such as mics/speakers etc. The split for the core's functionality can be arbitrary or be defined by the DSP firmware topology and include hooks for test/debug. This allows for the audio core device to be minimal and tightly coupled with handling the hardware-specific logic and communication. The ancillary bus is intended to be minimal, generic and avoid domain-specific assumptions. Each ancillary bus device represents a part of its parent functionality. The generic behavior can be extended and specialized as needed by encapsulating an ancillary bus device within other domain-specific structures and the use of .ops callbacks. The SOF driver adopts the ancillary bus for implementing the multi-client support. A client in the context of the SOF driver represents a part of the core device's functionality. It is not a physical device but rather an ancillary device that needs to communicate with the DSP via IPCs. With multi-client support,the sound card can be separated into multiple orthogonal ancillary devices for local devices (mic/speakers etc), HDMI, sensing, probes, debug etc. In this series, we demonstrate the usage of the ancillary bus with the help of the IPC test client which is used for testing the serialization of IPCs when multiple clients talk to the DSP at the same time. v2 changes: defined pr_fmt for kernel messages replaced WARN_ON calls in registration with pr_err calls adding kernel-doc function comments for device_initialize and device_add fix typo in documentation removed inaccurate line in documentation fixed formatting in drivers/bus/Makefile changed unwind path for sof_client_dev_alloc() improved comments for client list and mem freeing during client unreg removed debugfs entries in sof_ipc_test_client_drv during remove changed the signature of sof_debug_ipc_flood_test() fix a looping error in ancillary_match_id updated error value in sof_client_dev_register() mutex held while traversing client list when unregistering clients updated includes in sof-client.h Dave Ertman (1): Add ancillary bus support Fred Oh (1): ASoC: SOF: debug: Remove IPC flood test support in SOF core Ranjani Sridharan (4): ASoC: SOF: Introduce descriptors for SOF client ASoC: SOF: Create client driver for IPC test ASoC: SOF: ops: Add ops for client registration ASoC: SOF: Intel: Define ops for client registration Documentation/driver-api/ancillary_bus.rst | 229 ++++++++++++++ Documentation/driver-api/index.rst | 1 + drivers/bus/Kconfig | 3 + drivers/bus/Makefile | 3 + drivers/bus/ancillary.c | 225 ++++++++++++++ include/linux/ancillary_bus.h | 69 +++++ include/linux/mod_devicetable.h | 8 + scripts/mod/devicetable-offsets.c | 3 + scripts/mod/file2alias.c | 8 + sound/soc/sof/Kconfig | 29 +- sound/soc/sof/Makefile | 7 + sound/soc/sof/core.c | 12 + sound/soc/sof/debug.c | 230 -------------- sound/soc/sof/intel/Kconfig | 9 + sound/soc/sof/intel/Makefile | 3 + sound/soc/sof/intel/apl.c | 18 ++ sound/soc/sof/intel/bdw.c | 18 ++ sound/soc/sof/intel/byt.c | 22 ++ sound/soc/sof/intel/cnl.c | 18 ++ sound/soc/sof/intel/intel-client.c | 53 ++++ sound/soc/sof/intel/intel-client.h | 26 ++ sound/soc/sof/ops.h | 14 + sound/soc/sof/sof-client.c | 119 ++++++++ sound/soc/sof/sof-client.h | 69 +++++ sound/soc/sof/sof-ipc-test-client.c | 332 +++++++++++++++++++++ sound/soc/sof/sof-priv.h | 19 +- 26 files changed, 1308 insertions(+), 239 deletions(-) create mode 100644 Documentation/driver-api/ancillary_bus.rst create mode 100644 drivers/bus/ancillary.c create mode 100644 include/linux/ancillary_bus.h create mode 100644 sound/soc/sof/intel/intel-client.c create mode 100644 sound/soc/sof/intel/intel-client.h create mode 100644 sound/soc/sof/sof-client.c create mode 100644 sound/soc/sof/sof-client.h create mode 100644 sound/soc/sof/sof-ipc-test-client.c -- 2.26.2

10 71

support the Roland UA-4FX2 card
by kalashnikov-HJ4JGG 13 Oct '20

13 Oct '20

Hello i am juan and i am trying to use this (Roland UA-4FX2) sound card on linux, I posted this on the github and they recommended to put it on this mailing list. from https://github.com/alsa-project/alsa-lib/issues/81 hi i'm trying to use this audio card with a Raspberry pi and y get this from the command dmesg on linux console ``` usb 3-2: new high-speed USB device number 6 using xhci_hcd usb 3-2: New USB device found, idVendor=0582, idProduct=01e2, bcdDevice= 0.2b usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-2: Product: UA-4FX2 usb 3-2: Manufacturer: ROLAND mc: Linux media interface: v0.10 usbcore: registered new interface driver snd-usb-audio usb 3-2: Unable to change format on ep #8e: already in use usb 3-2: Unable to change format on ep #8e: already in use : : ``` and when i try to select the device on a program get this ``` ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side ALSA lib pcm_route.c:869:(find_matching_chmap) Found no matching channel map ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card ``` it seems that the card is not supported by ALSA lib. How is the procedure to add new cards to the driver? How can I help to do this? Thank you

1 0