May 2012 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] snd-hda-intel+dmix: Disabling power save doesn't work
by Adam Nielsen 08 May '12

08 May '12

Hi all, I'm trying to hunt down a bug in either dmix or the snd-hda-intel module and I'm hoping someone can give me some pointers. When I am playing audio and I pause playback, the codec goes into power save and stops generating a SPDIF signal. My amplifier then displays a 'signal lost' message. This is quite annoying as it takes a few seconds to sync when the signal returns (during which time I can't hear the audio being played), so I set "powersave=0" to disable this behaviour. This works as expected when stopping playback, but if I only *pause* playback then the signal drops almost exactly one second later, no matter what "powersave" is set to. So of course then resuming playback means I lose a couple of seconds of audio while the amplifier re-syncs to the SPDIF signal. Setting powersave to other values only affects the time before going into powersave mode after playback has stopped. It has no effect on whether power saving is activated while paused. The problem happens with any audio program (e.g. mplayer and xmms2.) Setting "powersave=0" means the SPDIF signal keeps going when stopping playback, but it still drops after one second when pausing playback. It doesn't happen if I use hw:0,1 as the output device (the SPDIF signal keeps going, even when paused) but as soon as I change the output device to dmix then the signal drops whenever the audio is paused. Is there any way to stop this behaviour and make dmix honour the module setting? Thanks, Adam.

2 3

[alsa-devel] [PATCH] ASoC: lowland: Support digital link for WM9081
by Mark Brown 08 May '12

08 May '12

The WM9081 on Lowland is connected to AIF3 on the WM5100. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/lowland.c | 42 +++++++++++++++++++++++++++--------------- 1 file changed, 27 insertions(+), 15 deletions(-) diff --git a/sound/soc/samsung/lowland.c b/sound/soc/samsung/lowland.c index 6cac1e9..6abf341 100644 --- a/sound/soc/samsung/lowland.c +++ b/sound/soc/samsung/lowland.c @@ -74,6 +74,25 @@ static int lowland_wm5100_init(struct snd_soc_pcm_runtime *rtd) return 0; } +static int lowland_wm9081_init(struct snd_soc_pcm_runtime *rtd) +{ + struct snd_soc_codec *codec = rtd->codec; + + snd_soc_dapm_nc_pin(&codec->dapm, "LINEOUT"); + + /* At any time the WM9081 is active it will have this clock */ + return snd_soc_codec_set_sysclk(codec, WM9081_SYSCLK_MCLK, 0, + CLKOUT_RATE, 0); +} + +static const struct snd_soc_pcm_stream sub_params = { + .formats = SNDRV_PCM_FMTBIT_S32_LE, + .rate_min = 44100, + .rate_max = 44100, + .channels_min = 2, + .channels_max = 2, +}; + static struct snd_soc_dai_link lowland_dai[] = { { .name = "CPU", @@ -96,21 +115,16 @@ static struct snd_soc_dai_link lowland_dai[] = { SND_SOC_DAIFMT_CBM_CFM, .ignore_suspend = 1, }, -}; - -static int lowland_wm9081_init(struct snd_soc_dapm_context *dapm) -{ - snd_soc_dapm_nc_pin(dapm, "LINEOUT"); - - /* At any time the WM9081 is active it will have this clock */ - return snd_soc_codec_set_sysclk(dapm->codec, WM9081_SYSCLK_MCLK, 0, - CLKOUT_RATE, 0); -} - -static struct snd_soc_aux_dev lowland_aux_dev[] = { { - .name = "wm9081", + .name = "Sub Speaker", + .stream_name = "Sub Speaker", + .cpu_dai_name = "wm5100-aif3", + .codec_dai_name = "wm9081-hifi", .codec_name = "wm9081.1-006c", + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM, + .ignore_suspend = 1, + .params = &sub_params, .init = lowland_wm9081_init, }, }; @@ -155,8 +169,6 @@ static struct snd_soc_card lowland = { .owner = THIS_MODULE, .dai_link = lowland_dai, .num_links = ARRAY_SIZE(lowland_dai), - .aux_dev = lowland_aux_dev, - .num_aux_devs = ARRAY_SIZE(lowland_aux_dev), .codec_conf = lowland_codec_conf, .num_configs = ARRAY_SIZE(lowland_codec_conf), -- 1.7.10

1 0

[alsa-devel] [PATCH] ASoC: lowland: Convert to dai_fmt
by Mark Brown 08 May '12

08 May '12

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/lowland.c | 33 ++++----------------------------- 1 file changed, 4 insertions(+), 29 deletions(-) diff --git a/sound/soc/samsung/lowland.c b/sound/soc/samsung/lowland.c index 4adff93..6cac1e9 100644 --- a/sound/soc/samsung/lowland.c +++ b/sound/soc/samsung/lowland.c @@ -21,33 +21,6 @@ #define MCLK1_RATE (44100 * 512) #define CLKOUT_RATE (44100 * 256) -static int lowland_hw_params(struct snd_pcm_substream *substream, - struct snd_pcm_hw_params *params) -{ - struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct snd_soc_dai *cpu_dai = rtd->cpu_dai; - struct snd_soc_dai *codec_dai = rtd->codec_dai; - int ret; - - ret = snd_soc_dai_set_fmt(codec_dai, SND_SOC_DAIFMT_I2S - | SND_SOC_DAIFMT_NB_NF - | SND_SOC_DAIFMT_CBM_CFM); - if (ret < 0) - return ret; - - ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_I2S - | SND_SOC_DAIFMT_NB_NF - | SND_SOC_DAIFMT_CBM_CFM); - if (ret < 0) - return ret; - - return 0; -} - -static struct snd_soc_ops lowland_ops = { - .hw_params = lowland_hw_params, -}; - static struct snd_soc_jack lowland_headset; /* Headset jack detection DAPM pins */ @@ -109,7 +82,8 @@ static struct snd_soc_dai_link lowland_dai[] = { .codec_dai_name = "wm5100-aif1", .platform_name = "samsung-audio", .codec_name = "wm5100.1-001a", - .ops = &lowland_ops, + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM, .init = lowland_wm5100_init, }, { @@ -118,7 +92,8 @@ static struct snd_soc_dai_link lowland_dai[] = { .cpu_dai_name = "wm5100-aif2", .codec_dai_name = "wm1250-ev1", .codec_name = "wm1250-ev1.1-0027", - .ops = &lowland_ops, + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM, .ignore_suspend = 1, }, }; -- 1.7.10

1 0

[alsa-devel] Strange Problem with snd-hda-intel
by Frank Maik Kittelmann 08 May '12

08 May '12

We have some strange behavior in our audio application using the ALC 888 hardware in ubuntu 10.10 with the hda-intel driver . Basically the main problem seems to be a buffer or memory management issue. Once a playback is stopped the very last sample is repeated forever, independently from sampling rate or sound file format. This sample leads to a constant DC voltage after the DA converters. We already tried the following steps: 1.) we changed a line in hda_intel.c to reset the fifo --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1797,7 +1797,7 @@ static int azx_pcm_hw_free(struct snd_pcm_substream *substream) /* reset BDL address */ azx_sd_writel(azx_dev, SD_BDLPL, 0); azx_sd_writel(azx_dev, SD_BDLPU, 0); - azx_sd_writel(azx_dev, SD_CTL, 0); + azx_stream_reset(chip, azx_dev); azx_dev->bufsize = 0; azx_dev->period_bytes = 0; azx_dev->format_val = 0; 2.) we set 2 parameters in the .config file before kernel compiling CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 Both solutions didn´t work for us - still same problem. Has anyone another idea how to solve this? Would be great if we could fix this. Frank

1 0

[alsa-devel] [PATCH 0/1] hdsp - Provide ioctl_compat
by Andre Schramm 08 May '12

08 May '12

Hi, short patch to provide ioctl_compat for HDSP cards as well. Quick test with SNDRV_HDSPM_IOCTL_GET_PEAK_RMS worked. Please review and apply. Thanks! Cheers, Andre

3 4

[alsa-devel] Issue with RME HDSPe AIO latency
by jamesm 07 May '12

07 May '12

Hello all, I'm using the RME hdspm kernel module with a Hammerfall HDSPe AIO card. I'm on RHEL 5.5, with alsa 1.0.17, kernel 2.6.18-194.11.4. I have backported the latest alsa hdspm code to this kernel, as there were a number of bugs in the one that ships with the 2.6.18-194 kernel. I've also implemented support for copy() and silence() functions so that the hdspm driver can be used with applications via the RDWR interface instead of just MMAP (ie it just works with aplay without using plughw first.) The latest hdspm driver code from alsa and kernel.org indicates that the HDSPe AIO card has a fixed buffer size of 16384. I've chosen a period size of 1024, which gives me 16 periods. The issue I have is that whenever I play audio through the hdspm driver, the delay between the hw pointer and sw pointer is always close to the maximum buffer size (approx 16000). This leaves me with a large delay between writing data into the PCM and it coming out of the card. I'd like this to be between 1024 and 2048, I could probably crank the period down further to 512. My application sets the start_threshold to 0 and avail_min to one period (1024). It then runs a thread, constantly writing data to the PCM (silence or real data). Does anyone have any suggestions as to why the hdspm driver hw pointer is not following the application pointer more closely? Is it due to the number of periods? Unfortunately I can't change that as the AIO buffer size is fixed. Here are my pcm hwparams, swparams and status from /proc/asound when my app is running: $ cat /proc/asound/card0/pcm0p/info card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: RME AIO name: RME AIO subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 0 $ cat /proc/asound/card0/pcm0p/sub0/hw_params access: RW_NONINTERLEAVED format: S32_LE subformat: STD channels: 16 rate: 48000 (48000/1) period_size: 1024 buffer_size: 16384 tick_time: 1000 $ cat /proc/asound/card0/pcm0p/sub0/sw_params tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 1024 xfer_align: 1 start_threshold: 0 stop_threshold: 18446744073709551615 silence_threshold: 0 silence_size: 0 boundary: 4611686018427387904 $ cat /proc/asound/card0/pcm0p/sub0/status state: RUNNING trigger_time: 1335799965.972782000 tstamp : 1335801526.687332000 delay : 15664 avail : 720 avail_max : 1056 ----- hw_ptr : 74911440 appl_ptr : 74927104 Regards James Milne FilmLight Ltd.

3 2

[alsa-devel] [PATCH] ALSA: jack: Update documention to reflect other userspace interfaces
by Mark Brown 07 May '12

07 May '12

Since this is a generic API which should support any userspace interface for reporting jacks update the documentation a little to make that a bit clearer. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/core/jack.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/core/jack.c b/sound/core/jack.c index 471e1e3..a06b165 100644 --- a/sound/core/jack.c +++ b/sound/core/jack.c @@ -155,7 +155,7 @@ EXPORT_SYMBOL(snd_jack_new); * @jack: The jack to configure * @parent: The device to set as parent for the jack. * - * Set the parent for the jack input device in the device tree. This + * Set the parent for the jack devices in the device tree. This * function is only valid prior to registration of the jack. If no * parent is configured then the parent device will be the sound card. */ @@ -179,6 +179,9 @@ EXPORT_SYMBOL(snd_jack_set_parent); * mapping is provided but keys are enabled in the jack type then * BTN_n numeric buttons will be reported. * + * If jacks are not reporting via the input API this call will have no + * effect. + * * Note that this is intended to be use by simple devices with small * numbers of keys that can be reported. It is also possible to * access the input device directly - devices with complex input -- 1.7.10

2 1

[alsa-devel] [PATCH RESEND 0/9] Enable pinctrl support for mach-mxs
by Shawn Guo 07 May '12

07 May '12

[Resend to have subsystem lists Cc-ed] With pinctrl-mxs driver (DT only) applied on pinctrl tree, the mxs device tree conversion can start basing on that support. This series adopts pinctrl support for mxs device drivers with a dummy pinctrl state provided for non-DT boot, so that the pinctrl call in the device drivers will be bypassed for non-DT probe while it starts working for DT probe. To ease the merge process, I would like to ask Arnd and Olof to pull pinctrl tree as a dependency in arm-soc and have this series go through arm-soc. Regards, Shawn Shawn Guo (9): ARM: mxs: enable pinctrl dummy states serial: amba-pl011: adopt pinctrl support serial: mxs-auart: adopt pinctrl support mmc: mxs-mmc: adopt pinctrl support mtd: nand: gpmi: adopt pinctrl support i2c: mxs: adopt pinctrl support ASoC: mxs-saif: adopt pinctrl support video: mxsfb: adopt pinctrl support ARM: mxs: enable pinctrl support arch/arm/Kconfig | 1 + arch/arm/mach-mxs/Kconfig | 2 ++ arch/arm/mach-mxs/include/mach/common.h | 2 ++ arch/arm/mach-mxs/mach-apx4devkit.c | 2 ++ arch/arm/mach-mxs/mach-m28evk.c | 2 ++ arch/arm/mach-mxs/mach-mx23evk.c | 2 ++ arch/arm/mach-mxs/mach-mx28evk.c | 2 ++ arch/arm/mach-mxs/mach-stmp378x_devb.c | 2 ++ arch/arm/mach-mxs/mach-tx28.c | 2 ++ arch/arm/mach-mxs/mm.c | 11 +++++++++++ drivers/i2c/busses/i2c-mxs.c | 6 ++++++ drivers/mmc/host/mxs-mmc.c | 8 ++++++++ drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 9 +++++++++ drivers/tty/serial/amba-pl011.c | 8 ++++++++ drivers/tty/serial/mxs-auart.c | 8 ++++++++ drivers/video/mxsfb.c | 9 +++++++++ sound/soc/mxs/mxs-saif.c | 8 ++++++++ 17 files changed, 84 insertions(+), 0 deletions(-) -- 1.7.5.4

3 5

Re: [alsa-devel] [BUG] Internal CD input missing since linux-3.4
by Takashi Iwai 07 May '12

07 May '12

At Tue, 1 May 2012 12:23:00 +0200, Philipp Matthias Hahn wrote: > > Hello, > > I upgraded my desktop to 3.3.4 last weekend and noticed that the > internal CD connector is no longer available for recording. Instead I > see some new controls about "headphone volume", "rear microphone" and > "auto-mute". But I need the CD input since it's connected to my Analog > TV card, which MythTV needs for recording. > > Using "git bisect" showed the following patch to be doing the switch: > > 31ef22579302ac42054bebecb528710f46580925 is the first bad commit > > commit 31ef22579302ac42054bebecb528710f46580925 > > Author: Takashi Iwai <tiwai(a)suse.de> > > Date: Thu Dec 1 17:41:36 2011 +0100 > > > > ALSA: hda - Integrate input-jack stuff into kctl-jack This looks pretty irrelevant, maybe the bisection went wrong. Basically the problem is that your BIOS doesn't expose the pin for the CD input as an available pin. In alsa-info.sh output, you can see the pin 0x1c is shown as N/A. We can override a pin config value manually in such a case. See HD-Audio.txt in Documentation/sound/alsa. In anyway, I'll try to prepare a test patch in the next week. thanks, Takashi

1 1

[alsa-devel] [PATCH] pci/echoaudio: Remove incorrect part of assertion
by Mark Hills 06 May '12

06 May '12

This assertion seems to imply that chip->dsp_code_to_load is a pointer. It's actually an integer handle on the actual firmware, and 0 has no special meaning. The assertion prevents initialisation of a Darla20 card, but would also affect other models. It seems it was introduced in commit dd7b254d. ALSA sound/pci/echoaudio/echoaudio.c:2061 Echoaudio driver starting... ALSA sound/pci/echoaudio/echoaudio.c:1969 chip=ebe4e000 ALSA sound/pci/echoaudio/echoaudio.c:2007 pci=ed568000 irq=19 subdev=0010 Init hardware... ALSA sound/pci/echoaudio/darla20_dsp.c:36 init_hw() - Darla20 ------------[ cut here ]------------ WARNING: at sound/pci/echoaudio/echoaudio_dsp.c:478 init_hw+0x1d1/0x86c [snd_darla20]() Hardware name: Dell DM051 BUG? (!chip->dsp_code_to_load || !chip->comm_page) Signed-off-by: Mark Hills <mark(a)pogo.org.uk> --- sound/pci/echoaudio/echoaudio_dsp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/pci/echoaudio/echoaudio_dsp.c b/sound/pci/echoaudio/echoaudio_dsp.c index 64417a7..d8c670c 100644 --- a/sound/pci/echoaudio/echoaudio_dsp.c +++ b/sound/pci/echoaudio/echoaudio_dsp.c @@ -475,7 +475,7 @@ static int load_firmware(struct echoaudio *chip) const struct firmware *fw; int box_type, err; - if (snd_BUG_ON(!chip->dsp_code_to_load || !chip->comm_page)) + if (snd_BUG_ON(!chip->comm_page)) return -EPERM; /* See if the ASIC is present and working - only if the DSP is already loaded */ -- 1.7.4.4

2 1