April 2014 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] v3.15-rc1: CORB reset timeout#1, CORBRP = 0
by Ronald 29 Apr '14

29 Apr '14

Just rebuild v3.15. The message in the subject appears to be at the error level. Sound plays fine. Everything seems to work as intended. [ 6.779741] snd_hda_intel 0000:00:10.1: Disabling MSI [ 6.781978] ALSA device list: [ 6.781980] No soundcards found. [ 6.785907] snd_hda_intel 0000:00:10.1: CORB reset timeout#1, CORBRP = 0 [ 7.670040] sound hdaudioC0D0: autoconfig: line_outs=1 (0x10/0x0/0x0/0x0/0x0) type:speaker [ 7.670046] sound hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 7.670049] sound hdaudioC0D0: hp_outs=1 (0x11/0x0/0x0/0x0/0x0) [ 7.670052] sound hdaudioC0D0: mono: mono_out=0x0 [ 7.670055] sound hdaudioC0D0: dig-out=0x13/0x0 [ 7.670057] sound hdaudioC0D0: inputs: [ 7.670060] sound hdaudioC0D0: Mic=0x14 [ 8.730734] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:10.1/sound/card0/hdaudioC0D0/input10 [ 8.731256] input: HDA NVidia Front Headphone as /devices/pci0000:00/0000:00:10.1/sound/card0/input11 Is this reason for concern?

2 5

[alsa-devel] [PATCH] ASoC: dapm: Factor out duplicated code in soc_dapm_stream_event()
by Lars-Peter Clausen 29 Apr '14

29 Apr '14

In soc_dapm_stream_event() we have the same code twice, once for the codec_dai and once for the cpu_dai. This patch factors the duplicated code out into a separate function. This will make it easier to modify the implementation (since there is only one place that needs to be updated) and also easier to add support for more than two DAIs per DAI link. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/soc-dapm.c | 51 ++++++++++++++++----------------------------------- 1 file changed, 16 insertions(+), 35 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index a2475e1..1871dfc 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -3446,32 +3446,25 @@ void snd_soc_dapm_connect_dai_link_widgets(struct snd_soc_card *card) } } -static void soc_dapm_stream_event(struct snd_soc_pcm_runtime *rtd, int stream, +static void soc_dapm_dai_stream_event(struct snd_soc_dai *dai, int stream, int event) { + struct snd_soc_dapm_widget *w; - struct snd_soc_dapm_widget *w_cpu, *w_codec; - struct snd_soc_dai *cpu_dai = rtd->cpu_dai; - struct snd_soc_dai *codec_dai = rtd->codec_dai; - - if (stream == SNDRV_PCM_STREAM_PLAYBACK) { - w_cpu = cpu_dai->playback_widget; - w_codec = codec_dai->playback_widget; - } else { - w_cpu = cpu_dai->capture_widget; - w_codec = codec_dai->capture_widget; - } - - if (w_cpu) { + if (stream == SNDRV_PCM_STREAM_PLAYBACK) + w = dai->playback_widget; + else + w = dai->capture_widget; - dapm_mark_dirty(w_cpu, "stream event"); + if (w) { + dapm_mark_dirty(w, "stream event"); switch (event) { case SND_SOC_DAPM_STREAM_START: - w_cpu->active = 1; + w->active = 1; break; case SND_SOC_DAPM_STREAM_STOP: - w_cpu->active = 0; + w->active = 0; break; case SND_SOC_DAPM_STREAM_SUSPEND: case SND_SOC_DAPM_STREAM_RESUME: @@ -3480,25 +3473,13 @@ static void soc_dapm_stream_event(struct snd_soc_pcm_runtime *rtd, int stream, break; } } +} - if (w_codec) { - - dapm_mark_dirty(w_codec, "stream event"); - - switch (event) { - case SND_SOC_DAPM_STREAM_START: - w_codec->active = 1; - break; - case SND_SOC_DAPM_STREAM_STOP: - w_codec->active = 0; - break; - case SND_SOC_DAPM_STREAM_SUSPEND: - case SND_SOC_DAPM_STREAM_RESUME: - case SND_SOC_DAPM_STREAM_PAUSE_PUSH: - case SND_SOC_DAPM_STREAM_PAUSE_RELEASE: - break; - } - } +static void soc_dapm_stream_event(struct snd_soc_pcm_runtime *rtd, int stream, + int event) +{ + soc_dapm_dai_stream_event(rtd->cpu_dai, stream, event); + soc_dapm_dai_stream_event(rtd->codec_dai, stream, event); dapm_power_widgets(rtd->card, event); } -- 1.8.0

2 1

[alsa-devel] No sound on Thinkpad T440s in Docking Station
by Joschi Brauchle 29 Apr '14

29 Apr '14

Dear all, using openSUSE 13.1 on an Thinkpad T440s, I am not getting sound once the laptop is docked to its docking station. I suspect an additional SND_PCI_QUIRK is needed for this model. "pactl list" returns ---------------- alsa.mixer_name = "Realtek ALC292" alsa.components = "HDA:10ec0292,17aa220c,00100001" ---------------- for the analog audio output sink in docked state. Hence I assume a new line similar to this ---------------- SND_PCI_QUIRK(0x17aa, 0x220c, "Thinkpad T440s", ALC269_FIXUP_LENOVO_DOCK), ---------------- is needed? What about the ALC292 instead of 269 Realtek chip...? Please find alsa-info.sh output attached. -- Dipl.-Ing. Joschi Brauchle, M.S. Institute for Communications Engineering (LNT) Technische Universitaet Muenchen (TUM) 80290 Munich, Germany Tel (work): +49 89 289-23474 Fax (work): +49 89 289-23490 E-mail: joschi.brauchle(a)tum.de Web: http://www.lnt.ei.tum.de/

1 0

[alsa-devel] [PATCHv2 0/2] fm801: small clean up series
by Andy Shevchenko 29 Apr '14

29 Apr '14

Two patches in the series are targeting to clean up a bit fm801 driver. Changes since v1: - remove inline from helper function definitions - fix rebase issue that led to wrong logic - rename helper function to be more particular - reorder parameters in the hw accessor macros Andy Shevchenko (2): fm801: introduce macros to access the hardware fm801: introduce fm801_ac97_is_ready()/fm801_ac97_is_valid() helpers sound/pci/fm801.c | 200 ++++++++++++++++++++++++++++-------------------------- 1 file changed, 105 insertions(+), 95 deletions(-) -- 1.8.3.101.g727a46b

2 4

[alsa-devel] Invalid PCM pointer with CMI8738 and pcm.c buffer underuns
by Andoru 29 Apr '14

29 Apr '14

[Continued from here: http://thread.gmane.org/gmane.linux.alsa.devel/122028/focus=122354 ] > It's way too old. Better to build the latest kernel. The latest kernel available for my distro, or the latest kernel available "from Linus"? I've already tried the former. > You need to figure out the condition reproducing the issue. For all I know (I'm not that knowledgeable on those things, mind you) this happens completely at random. There hasn't been any pattern when the PC would become unusable, and the OS unresponsive. > For example, application may apply some strange buffer size and period > size the hardware chip doesn't like. If so, changing the buffer size > and/or period size may reduce the problem. I'm not aware of any feature to change the buffer size in any of the programs that cause the lock-ups. > Meanwhile, you can try the patch below, too, which aligns the period That patch is for kernel sources or for the above snapshots I mentioned? Or perhaps there are more recent ALSA source codes?

2 3

Re: [alsa-devel] hda-jack-retask on CentOS 6.5
by Takashi Iwai 29 Apr '14

29 Apr '14

At Mon, 28 Apr 2014 12:33:03 -0500, Chris Pemberton wrote: > > The laptop left and right speakers work as is: the third "Beats Audio" > sub is the only thing needing a fix. I changed the following: > > 0x0d (Internal Speaker, Front Side) -> Override Internal Speaker (Back) > 0x10 -> Internal speaker (LFE) So, just replacing the pin config of NID 0x0d suffices? Could you give the alsa-info.sh output with that setup? Then I can write a patch for adding the configuration statically to the kernel. thanks, Takashi > > I recompiled the module per the CentOS wiki; and it failed to load > (wrong file type; although it was the _identical _file type). I then > compiled the entire kernel and used the new module with the old kernel; > it wouldn't load due to not being signed. Finally found a mainline > kernel in the elrepo repo that had the proper snd_hda_intel configured. > Works great with the pin configs I provided previously. > > Machine is currently loaded with Fedora 20 and Win7 if you'd like more > detailed information. I was able to download a Win7 driver from HP that > supposedly enables Beats Audio for many HP laptops models; if it could > be of any use. > > On 04/28/2014 10:43 AM, Takashi Iwai wrote: > > At Mon, 21 Apr 2014 13:54:22 -0500, > > Chris Pemberton wrote: > >> I could not find an rpm containing "hda-jack-retask" for CentOS 6.5, nor > >> could I compile it from source as it requires newer libraries than > >> CentOS provides. I therefore booted into Ubuntu 14.04, ran > >> hdajackretask, and saved the pin reassignments that fix my particular > >> laptop. > >> > >> From Ubuntu 14.14 /lib/firmware/hda-jack-retask.fw > >> > >> [codec] > >> 0x111d76e0 0x103c190d 0 > >> > >> [pincfg] > >> 0x0a 0x03a11020 > >> 0x0b 0x0321101f > >> 0x0c 0x40f000f0 > >> 0x0d 0x90170152 > >> 0x0e 0x40f000f0 > >> 0x0f 0x40f000f0 > >> 0x10 0x90170151 > >> 0x11 0xd5a30130 > >> 0x1f 0x40f000f0 > >> 0x20 0x40f000f0 > >> > >> I created the following /etc/modprobe.d/hda-jack-retask.conf in CentOS 6.5: > >> > >> options snd-hda-intel > >> patch=hda-jack-retask.fw,hda-jack-retask.fw,hda-jack-retask.fw,hda-jack-retask.fw > >> > >> Now when CentOS tries to load the snd-hda-intel module, I get the > >> following error: > >> > >> snd_hda_intel: Unknown parameter `patch' > >> > >> Is there another method I can use to set the pins? This is the only way > >> I've managed to get "Beats Audio" working on my HP Envy k025dx. > > You need to rebuild your kernel with proper configs. The patch option > > is available via CONFIG_SND_HDA_PATCH_LOADER. > > > > BTW, which pin setup is missing? It's better to add the static fixup > > in the kernel code. > > > > > > Takashi > > [2 <text/html; ISO-8859-1 (7bit)>] >

1 0

[alsa-devel] [PATCH 00/15] ASoC: Arnds randconfig fixes for ASoC
by Xia Kaixu 29 Apr '14

29 Apr '14

This patchset series addresses various bugs found and fixed by Arnd Bergmann whilst doing randconfig builds. My involvement has been to review, add/check the maintainers are correct and submit upstream to try and reduce the backlog. Best Regards, Kaixu Xia Arnd Bergmann (11): ASoC: CS42L51 and WM8962 codecs depend on INPUT ASoC: davinci: add dependencies for SND_SOC_TLV320AIC3X ASoC: SMDK_WM8580_PCM needs REGMAP_I2C ASoC: samsung-idma: avoid 64-bit division ASoC: nuc900: export nuc900_ac97_data ASoC: RX-51 audio needs I2C ASoC: UDA1380 needs I2C ASoC: Atmel WM8904 codec support needs I2C ASoC: SND_S3C_DMA_LEGACY needs S3C24XX_DMA ASoC: Amstrad E3 needs TTY support for codec ASoC: pxa: remove mach header dependency Xia Kaixu (4): ASoC: TTC DKB audio needs I2C ASoC: Migo-R sound needs I2C ASoC: TLV320AIC23 and Simtec Hermes audio need I2C ASoC: WM0010 needs SPI sound/arm/pxa2xx-pcm.c | 2 ++ sound/arm/pxa2xx-pcm.h | 3 +-- sound/soc/atmel/Kconfig | 2 +- sound/soc/codecs/Kconfig | 8 ++++---- sound/soc/davinci/Kconfig | 10 +++++----- sound/soc/fsl/Kconfig | 2 +- sound/soc/nuc900/Kconfig | 1 + sound/soc/nuc900/nuc900-ac97.c | 1 + sound/soc/omap/Kconfig | 4 ++-- sound/soc/pxa/Kconfig | 2 +- sound/soc/pxa/pxa-ssp.c | 2 -- sound/soc/pxa/pxa2xx-pcm.c | 2 ++ sound/soc/samsung/Kconfig | 22 ++++++++++------------ sound/soc/samsung/idma.c | 2 +- sound/soc/sh/Kconfig | 2 +- 15 files changed, 33 insertions(+), 32 deletions(-) -- 1.7.9.5

1 0

[alsa-devel] [PATCH 15/15] ASoC: pxa: remove mach header dependency
by Xia Kaixu 29 Apr '14

29 Apr '14

From: Arnd Bergmann <arnd(a)arndb.de> As we are moving the mmp platform towards multiplatform support, we have to stop including platform header files. This changes the pxa-ssp sound driver file to no longer depend on mach/hardware.h and mach/dma.h. The code using the definitions from those headers is actually gone already, the only thing that was still being used was the pxa_dma_desc typedef, which we can easily work around by using the normal 'struct pxa_dma_desc' name. The pxa2xx-dma driver still uses this header, so we include it explicitly there, which is ok because that is only used on pxa, not on mmp. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Xia Kaixu <kaixu.xia(a)linaro.org> Cc: Mark Brown <broonie(a)kernel.org> Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Eric Miao <eric.y.miao(a)gmail.com> Cc: Russell King <linux(a)arm.linux.org.uk> Cc: Haojian Zhuang <haojian.zhuang(a)gmail.com> Cc: linux-arm-kernel(a)lists.infradead.org Cc: alsa-devel(a)alsa-project.org --- sound/arm/pxa2xx-pcm.c | 2 ++ sound/arm/pxa2xx-pcm.h | 3 +-- sound/soc/pxa/pxa-ssp.c | 2 -- sound/soc/pxa/pxa2xx-pcm.c | 2 ++ 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/sound/arm/pxa2xx-pcm.c b/sound/arm/pxa2xx-pcm.c index e6c727b..83be8e3 100644 --- a/sound/arm/pxa2xx-pcm.c +++ b/sound/arm/pxa2xx-pcm.c @@ -14,6 +14,8 @@ #include <linux/dma-mapping.h> #include <linux/dmaengine.h> +#include <mach/dma.h> + #include <sound/core.h> #include <sound/pxa2xx-lib.h> #include <sound/dmaengine_pcm.h> diff --git a/sound/arm/pxa2xx-pcm.h b/sound/arm/pxa2xx-pcm.h index 2a8fc08..0033098 100644 --- a/sound/arm/pxa2xx-pcm.h +++ b/sound/arm/pxa2xx-pcm.h @@ -9,12 +9,11 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ -#include <mach/dma.h> struct pxa2xx_runtime_data { int dma_ch; struct snd_dmaengine_dai_dma_data *params; - pxa_dma_desc *dma_desc_array; + struct pxa_dma_desc *dma_desc_array; dma_addr_t dma_desc_array_phys; }; diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c index a3119a0..9b19ee7 100644 --- a/sound/soc/pxa/pxa-ssp.c +++ b/sound/soc/pxa/pxa-ssp.c @@ -34,8 +34,6 @@ #include <sound/pxa2xx-lib.h> #include <sound/dmaengine_pcm.h> -#include <mach/hardware.h> - #include "../../arm/pxa2xx-pcm.h" #include "pxa-ssp.h" diff --git a/sound/soc/pxa/pxa2xx-pcm.c b/sound/soc/pxa/pxa2xx-pcm.c index d58b09f..42f2f01 100644 --- a/sound/soc/pxa/pxa2xx-pcm.c +++ b/sound/soc/pxa/pxa2xx-pcm.c @@ -15,6 +15,8 @@ #include <linux/dmaengine.h> #include <linux/of.h> +#include <mach/dma.h> + #include <sound/core.h> #include <sound/soc.h> #include <sound/pxa2xx-lib.h> -- 1.7.9.5

1 0

[alsa-devel] Application development
by Rob Janssen 29 Apr '14

29 Apr '14

A week and a half ago I asked some questions about application development using alsa ("Control the exact moment of output"), but it appears this list is more about development of alsa itself. Is there another place where discussions about using alsa are more appropriate, and/or a place where documentation can be found that goes a bit further than a plain list of function names and parameter lists? I.e. a more general description about how one structures an application that uses alsa, and how timing fits in that picture. Rob

2 1

[alsa-devel] Invalid PCM pointer with CMI8738 and pcm.c buffer underuns
by Andoru 29 Apr '14

29 Apr '14

[Continued from here: http://news.gmane.org/find-root.php?message_id=loom.20140406T010044%2d863%4…] Since I didn't get any answer again, I decided to try and build the latest ALSA snapshots myself (alsa-driver-1.0.25.3584.gb044d; alsa-firmware-1.0.27.2.gf21a8; alsa-lib-1.0.27.2; alsa-oss-1.0.25.2.g39df1; alsa-plugins-1.0.27.10.gb5917; alsa-utils-1.0.27.2.22.gb7ed4) and purge the Debian ALSA packages to see if I could do something at compile time or if it would fix the problems, but they're still there. The OS still slows down to a crawl at random times and I still have the issue with the volume control plus other quirks I mentioned in the previous threads...

2 2