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

[alsa-devel] Error patching file pcm_native.c
by Delusion's Master 20 Nov '24

20 Nov '24

Hi, first of all I apologize in case you receive multiple copies of this message, but I forgot to specify a subject in the original mail. I have a problem compiling the latest alsa driver snapshots. Specifically, it's a problem when patching pcm_native.c: [..] copying file alsa-kernel/core/info.c patching file info.c copying file alsa-kernel/core/pcm.c patching file pcm.c Hunk #3 succeeded at 739 (offset 2 lines). Hunk #5 succeeded at 954 (offset 2 lines). Hunk #7 succeeded at 1045 (offset 2 lines). copying file alsa-kernel/core/pcm_native.c patching file pcm_native.c Hunk #4 succeeded at 1544 (offset -25 lines). Hunk #5 succeeded at 2827 (offset 12 lines). Hunk #6 succeeded at 2878 (offset 10 lines). Hunk #7 FAILED at 2906. Hunk #8 FAILED at 2922. Hunk #9 succeeded at 2915 (offset -23 lines). Hunk #10 succeeded at 3036 (offset 10 lines). Hunk #11 succeeded at 3027 (offset -23 lines). Hunk #12 succeeded at 3074 (offset 10 lines). Hunk #13 succeeded at 3098 (offset -23 lines). Hunk #14 succeeded at 3143 (offset 10 lines). Hunk #15 succeeded at 3124 (offset -23 lines). Hunk #16 succeeded at 3214 (offset 10 lines). Hunk #17 succeeded at 3208 (offset -23 lines). Hunk #18 succeeded at 3271 (offset 10 lines). Hunk #19 succeeded at 3304 (offset -23 lines). Hunk #20 succeeded at 3386 (offset 10 lines). Hunk #21 succeeded at 3411 (offset -23 lines). Hunk #22 succeeded at 3456 (offset 10 lines). Hunk #23 succeeded at 3450 (offset -23 lines). Hunk #24 succeeded at 3525 (offset 10 lines). Hunk #25 succeeded at 3644 (offset -23 lines). 2 out of 25 hunks FAILED -- saving rejects to file pcm_native.c.rej make[2]: *** [pcm_native.c] Error 1 It's some days I get this, but I waited to report this since I thought it could be a temporary problem. My OS is Fedora 11 x86_64. Previous snapshots didn't give me this problem, but I can't say which one broke the compilation, since I usually try updated snapshots only at kernel updates. I searched for this error and the only relevant report I could find is this one: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-April/016420.html a report from last April. What could the problem be? Thanks _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

3 10

[alsa-devel] unsupported variant of snd_hda_intel
by Alexandre 04 Jul '24

04 Jul '24

Hello, I have an Acer Aspire 4736G laptop. The soundcard that is shipped in this laptop is intel-hda based as shown (actually it's a realtek): cat /proc/asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0x9b300000 irq 46 Basic sound output is correct but few feature are missing: - internal mic seems to be found but do not works. - sound output stop working when trying to send it using HDMI output - heads do not work when plugged neither when forcing pulseaudio to use it. I have an ubuntu 10.10 which is shipped with alsa 1.0.23. I have googled around and tried loading the snd-hda-intel with several parameters () as found in HD-Audio-Models.txt to no avail. cat /proc/asound/pcm 00-00: ALC888 Analog : ALC888 Analog : playback 1 : capture 1 00-01: ALC888 Digital : ALC888 Digital : playback 1 00-03: NVIDIA HDMI : NVIDIA HDMI : playback 1 Where can I begin to help implement the support for this sound card? I have very skills in developement in general but am ready to try if it is not to hard (I supose I can use previous code for similar models).. I just need a shepherd. Thanks

4 4

[alsa-devel] echo-cancellation plugin advice?
by Max Klein 27 Oct '23

27 Oct '23

> Well, asym wouldn't be the answer. Basically you'll need to open two > slave PCMs in one plugin. So, it's no simple filter-type plugin. > It's doable, but not easy as it sounds, I guess. Takashi, can you please further explain why asym is not the solution and what you see as a problem? I am also trying to figure out if it would be possible to create such a plugin for ALSA? I am still searching for some good starting points on how to write an ALSA plugin... Jean-Marc Valin (http://lists.linuxaudio.org/pipermail/linux-audio-dev/2005-June/012454.html) already released his work as part of speex but as far I know there is no plugin that has been made out of it? Thanks for any hint! -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

3 2

[alsa-devel] ALSA 1.0.29 release
by Jaroslav Kysela 19 Feb '20

19 Feb '20

Hello all, all userspace packages (except alsa-oss) were released today. You may download them from the ALSA website http://www.alsa-project.org or directly from the FTP server ftp://ftp.alsa-project.org/pub . Full list of changes: http://www.alsa-project.org/main/index.php/Changes_v1.0.28_v1.0.29 Have fun, Jaroslav -- Jaroslav Kysela <perex(a)perex.cz> Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.

2 16

[alsa-devel] [PATCH 1/1] ASoC: bcm2835-i2s: Support 384k sample rate
by Clive Messer 10 Nov '17

10 Nov '17

Add support for sample rates up to 384k to bcm2835-i2s driver, with SNDRV_PCM_RATE_CONTINUOUS and specifying 8k min and 384k max, for both playback and capture. Signed-off-by: Clive Messer <clive.messer(a)digitaldreamtime.co.uk> --- sound/soc/bcm/bcm2835-i2s.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/sound/soc/bcm/bcm2835-i2s.c b/sound/soc/bcm/bcm2835-i2s.c index 6ba2049..4a67db2 100644 --- a/sound/soc/bcm/bcm2835-i2s.c +++ b/sound/soc/bcm/bcm2835-i2s.c @@ -578,7 +578,9 @@ static struct snd_soc_dai_driver bcm2835_i2s_dai = { .playback = { .channels_min = 2, .channels_max = 2, - .rates = SNDRV_PCM_RATE_8000_192000, + .rates = SNDRV_PCM_RATE_CONTINUOUS, + .rate_min = 8000, + .rate_max = 384000, .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE @@ -586,7 +588,9 @@ static struct snd_soc_dai_driver bcm2835_i2s_dai = { .capture = { .channels_min = 2, .channels_max = 2, - .rates = SNDRV_PCM_RATE_8000_192000, + .rates = SNDRV_PCM_RATE_CONTINUOUS, + .rate_min = 8000, + .rate_max = 384000, .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE -- 2.5.5

3 2

[alsa-devel] ASoC Sound Driver I2S over LPE, Intel Baytrail SoC. MinnowBoard Max
by Michael Pogrebinsky 02 Oct '17

02 Oct '17

Hi all, I have the MinnowBoard Max with Baytrail Atom (ValleyView) SoC. I'm attempting to write an Alsa (ASoC) driver for my sound card to work with this board. PCM should work through I2S for this sound card I have. >From my understanding Baytrail's I2S goes over LPE. I read this thread:https://www.mail-archive.com/elinux-minnowboard@lists.elinux.org/msg… So I understand that I need the 3 components for my ASoC driver. However I am having trouble at understanding how to communicate with the LPE to get the I2S working. Here is what I have done so far: I am running Ubuntu 14.04 LTS, kernel : 4.3.0-040300rc4 First of all I downloaded the firmware fw_sst_0f28.bin-48kHz_i2s_master fromhttps://kernel.googlesource.com/pub/scm/linux/kernel/git/firmware/linux… And put it /lib/firmware/intel/. Later I went to the Bios and enabled LPE in PCI mode. I do see the LPE controller now, but it shows as UNCLAIMED. Later I looked at the sound/soc/inte/baytrail/ and from my understanding in order for me to get the I2S working I need to load this module so I did modprobe snd-soc-sst-baytrail-pcm. Later I wrote a simple codec and machine driver (looking at the example of sound/soc/intel/boards/byt_max98090) however everytime I attempt to register the sound card with snd_soc_register_card, I get the following error message in dmesg : "ASoC: CPU DAI baytrail-pcm-audio not registered". >From this I deduct that although I loaded the snd-soc-sst-baytrail-pcm module, the driver has not actually been loaded. I'm clueless on how to proceed from here. I would highly appreciate your help.

3 7

[alsa-devel] [PATCH 0/9] AC97 device/driver model revamp
by Robert Jarzmik 19 Sep '17

19 Sep '17

It all started in the pxa device-tree submission here : https://lkml.org/lkml/2016/2/25/965 Last submission was a RFC in here: http://www.gossamer-threads.com/lists/linux/kernel/2446863 It will be maintained in : git fetch https://github.com/rjarzmik/linux.git work/ac97 The driving ideas are still the same, and I put them in [1] for memory. This is the first post RFC submission. In order to make a full demonstration of the framework, wm97xx was converted to an MFD, see [2] for the "why". As this serie is a complete wm9713 change towards the new AC97 bus, here is the patch organization : - 1/9, 2/9, 3/9 and 5/9: the new AC97 bus, for Mark and Takashi to review - 4/9: wm9713 conversion, this one has ugly #ifdefs, should be reviewed more carefully - 6/9: prerequisite for final 9/9, for Marek and Sebastian to approve => this one is independent and can flow through Sebastian's tree in this next-cycle if accepted - 7/9: prerequisite for final 9/9, for Mark/Dmitry => this one is also independent and can flow in this cycle if accepted - 8/9: prerequisite for final 9/9, for Lee to review => this one has a dependency on 2/9, so it probably can't fit in this next-cycle - 9/9: this last one depends on all the patches before, so it can't fit in this next-cycle As a sum-up, I'd like to push for review for this -next cycle at least the patches 1, 2, 3, 5, 6 and 9. Happy review. Robert Jarzmik (9): ALSA: ac97: split out the generic ac97 registers ALSA: ac97: add an ac97 bus ASoC: add new ac97 bus support ASoC: wm9713: add ac97 new bus support ASoC: pxa: switch to new ac97 bus support power_supply: wm97xx_battery: use power_supply_get_drvdata Input: wm97xx: split out touchscreen registering mfd: wm97xx-core: core support for wm97xx Codec Input: wm97xx: add new AC97 bus support drivers/input/touchscreen/Kconfig | 2 +- drivers/input/touchscreen/wm97xx-core.c | 247 +++++++++++----- drivers/mfd/Kconfig | 14 + drivers/mfd/Makefile | 1 + drivers/mfd/wm97xx-core.c | 282 ++++++++++++++++++ drivers/power/supply/wm97xx_battery.c | 25 +- include/linux/mfd/wm97xx.h | 31 ++ include/sound/ac97/codec.h | 115 +++++++ include/sound/ac97/compat.h | 21 ++ include/sound/ac97/controller.h | 85 ++++++ include/sound/ac97/regs.h | 262 ++++++++++++++++ include/sound/ac97_codec.h | 239 +-------------- include/sound/pxa2xx-lib.h | 15 +- sound/Kconfig | 2 + sound/Makefile | 1 + sound/ac97/Kconfig | 19 ++ sound/ac97/Makefile | 8 + sound/ac97/ac97_core.h | 10 + sound/ac97/bus.c | 510 ++++++++++++++++++++++++++++++++ sound/ac97/codec.c | 15 + sound/ac97/snd_ac97_compat.c | 105 +++++++ sound/arm/Kconfig | 1 - sound/arm/pxa2xx-ac97-lib.c | 39 ++- sound/soc/Kconfig | 4 + sound/soc/codecs/Kconfig | 3 +- sound/soc/codecs/wm9713.c | 37 ++- sound/soc/pxa/Kconfig | 5 +- sound/soc/pxa/pxa2xx-ac97.c | 22 +- 28 files changed, 1738 insertions(+), 382 deletions(-) create mode 100644 drivers/mfd/wm97xx-core.c create mode 100644 include/linux/mfd/wm97xx.h create mode 100644 include/sound/ac97/codec.h create mode 100644 include/sound/ac97/compat.h create mode 100644 include/sound/ac97/controller.h create mode 100644 include/sound/ac97/regs.h create mode 100644 sound/ac97/Kconfig create mode 100644 sound/ac97/Makefile create mode 100644 sound/ac97/ac97_core.h create mode 100644 sound/ac97/bus.c create mode 100644 sound/ac97/codec.c create mode 100644 sound/ac97/snd_ac97_compat.c -- 2.1.4 [1] RFC PATCH reminder: Amongst the driving ideas behind this RFC : - use device/driver model for AC'97 device/driver binding is based on vendor_id{1,2} - use auto-probe of the AC'97 bus to enumerate codecs and create devices - be compatible with previous platform_data model for codecs => this enables a smooth transition, where a codec (here wm9713) can be used either through platform_device or automatic discovery - struct snd_ac97 is not used This structure is really heavy, and doesn't represent an AC97 device, but rather an AC'97 codec internals IIUC. I think it's right place would be in include/sound/ac97/codec.h. This is also a problem for regmap adherence, hence the include/sound/ac97/compat.h. - a new AC'97 bus Kconfig is created This was done for a smooth transition ... let's see if it's a good idea. - split the AC'97 into : - the codec - the digital controller - the bus Amongst the things that are not all touched yet : - ac97_codec.c The generic AC'97 codec in sound/pci/ac97/ac97_codec.c has really a lot features, which are not at all PCI related. They could be transfered to sound/ac97, without the pci specific field. => this deserves a deep ahead thinking, which I'll do if the current approach is accepted by the communauty. The most important patch is 2/7 "ALSA: ac97: add an ac97 bus". This is the main evaluation point for the serie, the others are here so that I can test it all. Well, this is a long term effort, which might need a complete rewrite according to the comments it'll get. Let's expose it for comments and see how I can progress with it. [2] As a corollary, wm97xx is changed into a MFD device, which at least spawns: - the touchscreen device - the ac97 codec - the problem to solve was stated in http://www.gossamer-threads.com/lists/linux/kernel/2510113#2510113

9 38

[alsa-devel] [RFC PATCH 0/7] AC97 device/driver model revamp
by Robert Jarzmik 04 Sep '17

04 Sep '17

It all started in the pxa device-tree submission here : https://lkml.org/lkml/2016/2/25/965 It will be maintained in : git fetch https://github.com/rjarzmik/linux.git work/ac97 And now it transformed into this RFC, which would bring a ground for AC'97 devices closer to the linux device/driver model. This is just an RFC to see if we understand each other Mark. Amongst the driving ideas behind this RFC : - use device/driver model for AC'97 device/driver binding is based on vendor_id{1,2} - use auto-probe of the AC'97 bus to enumerate codecs and create devices - be compatible with previous platform_data model for codecs => this enables a smooth transition, where a codec (here wm9713) can be used either through platform_device or automatic discovery - struct snd_ac97 is not used This structure is really heavy, and doesn't represent an AC97 device, but rather an AC'97 codec internals IIUC. I think it's right place would be in include/sound/ac97/codec.h. This is also a problem for regmap adherence, hence the include/sound/ac97/compat.h. - a new AC'97 bus Kconfig is created This was done for a smooth transition ... let's see if it's a good idea. - split the AC'97 into : - the codec - the digital controller - the bus Amongst the things that are not all touched yet : - ac97_codec.c The generic AC'97 codec in sound/pci/ac97/ac97_codec.c has really a lot features, which are not at all PCI related. They could be transfered to sound/ac97, without the pci specific field. => this deserves a deep ahead thinking, which I'll do if the current approach is accepted by the communauty. The most important patch is 2/7 "ALSA: ac97: add an ac97 bus". This is the main evaluation point for the serie, the others are here so that I can test it all. Well, this is a long term effort, which might need a complete rewrite according to the comments it'll get. Let's expose it for comments and see how I can progress with it. Cheers. -- Robert Robert Jarzmik (7): ALSA: ac97: split out the generic ac97 registers ALSA: ac97: add an ac97 bus ASoC: wm9713: add ac97 new bus support ASoC: pxa: switch to new ac97 bus support ARM: pxa: mioa701 remove wm9713 from platform devices ASoC: mioa701_wm9713: convert to new ac97 bus ASoC: add new ac97 bus support arch/arm/mach-pxa/mioa701.c | 1 - include/sound/ac97/codec.h | 98 ++++++++++++ include/sound/ac97/compat.h | 21 +++ include/sound/ac97/controller.h | 39 +++++ include/sound/ac97/regs.h | 262 +++++++++++++++++++++++++++++++ include/sound/ac97_codec.h | 239 +---------------------------- include/sound/pxa2xx-lib.h | 14 +- sound/Kconfig | 7 + sound/Makefile | 1 + sound/ac97/Kconfig | 9 ++ sound/ac97/Makefile | 5 + sound/ac97/ac97_core.h | 10 ++ sound/ac97/bus.c | 330 ++++++++++++++++++++++++++++++++++++++++ sound/ac97/codec.c | 15 ++ sound/ac97/snd_ac97_compat.c | 104 +++++++++++++ sound/arm/Kconfig | 1 - sound/arm/pxa2xx-ac97-lib.c | 31 ++-- sound/soc/Kconfig | 4 + sound/soc/codecs/wm9713.c | 62 +++++++- sound/soc/pxa/Kconfig | 4 +- sound/soc/pxa/mioa701_wm9713.c | 4 +- sound/soc/pxa/pxa2xx-ac97.c | 12 +- 22 files changed, 1000 insertions(+), 273 deletions(-) create mode 100644 include/sound/ac97/codec.h create mode 100644 include/sound/ac97/compat.h create mode 100644 include/sound/ac97/controller.h create mode 100644 include/sound/ac97/regs.h create mode 100644 sound/ac97/Kconfig create mode 100644 sound/ac97/Makefile create mode 100644 sound/ac97/ac97_core.h create mode 100644 sound/ac97/bus.c create mode 100644 sound/ac97/codec.c create mode 100644 sound/ac97/snd_ac97_compat.c -- 2.1.4

3 29

Re: [alsa-devel] Dell USB audio driver workaround
by Takashi Iwai 21 Jun '17

21 Jun '17

On Wed, 06 Apr 2016 08:29:12 +0200, Kailang wrote: > > Hi Takashi, > > Dell had USB dock. > Maybe firmware issue, the master volume always keep at 0x57. > Attach patch will fix it to keep at Max volume. > > Could you help us to update it? Well, I don't get how this patch works.. > diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c > index 4f85757..84d9a4e 100644 > --- a/sound/usb/mixer.c > +++ b/sound/usb/mixer.c > @@ -846,6 +846,12 @@ static void volume_control_quirks(struct usb_mixer_elem_info *cval, > { > struct snd_usb_audio *chip = cval->head.mixer->chip; > switch (chip->usb_id) { > + case USB_ID(0x0bda, 0x4014): /* Dell workaround */ > + if (strstr(kctl->id.name, "Playback Volume") != NULL) { > + cval->min = 0x0000; > + cval->max = 0x0000; > + } > + break; So, this means that this value has to be fixed to 0? If yes, can't we simply remove this volume instead? thanks, Takashi

4 16

[alsa-devel] [PATCH 0/7] of_graph: prepare for ALSA graph support
by Kuninori Morimoto 17 May '17

17 May '17

Hi Rob, Mark Cc Guennadi, Laurent Now OF graph is mainly used by V4L2 SoC, and ALSA SoC is using different style for SoC <-> Codec binding. But, for example, HDMI case, V4L2 <-> ALSA need to collaborate, and then ALSA SoC needs to adjust to OF graph. OTOH, V4L2's "OF graph" position is same as ALSA SoC "sound card" position. And ALSA SoC side want to keep existing supported feature on new OF graph style. I'm posting this on ALSA SoC ML now. Now, current of_graph is indicating port/endpoint, but there is no way to understand that it is for video port ? or sound port ? or other device port ? For example, HDMI has video port, and sound port. Because of this reason, ALSA SoC side can't handle OF graph correctly. Thus, this patch-set tries to add new "type" on OF graph. And this patch-set includes small feature which are useful for ALSA SoC side OF graph support. Kuninori Morimoto (7): Documentation: of: add type property of_graph: add of_graph_get_remote_endpoint() of_graph: add of_graph_port/endpoint_type_is() of_graph: add of_graph_get_endpoint_count() of_graph: add of_graph_get_port_parent() of_graph: add of_graph_get_top_port() of_graph: add for_each_of_port() / for_each_of_endpoint_in_port() Documentation/devicetree/bindings/graph.txt | 26 ++++ drivers/of/base.c | 196 ++++++++++++++++++++++++++-- include/linux/of_graph.h | 67 ++++++++++ 3 files changed, 279 insertions(+), 10 deletions(-) -- 1.9.1

3 12