August 2010 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [alsa-lib] Query regarding snd_config_update_free_global() and threads etc.
by Colin Guthrie 24 Aug '10

24 Aug '10

Hi there, I've got a (hopefully quick) query about snd_config_update_free_global() and it's general thread safetyness. I'm currently going insane on this bug: https://bugs.kde.org/show_bug.cgi?id=232068 which revolves around a bug manifested in snd_pcm_close() (or rather snd_pcm_ioplug_close()) when dealing with the ALSA->PulseAudio plugin. _From what I can gather, this problem is related to a KDE module that is loaded into the library in question which does some alsa probing and ultimately calls snd_config_update_free_global() several times. The library itself then goes on to use GStreamer to do actual audio output. The crash then manifests itself prior to any sound actually being output. I can reliably reproduce the machine on two machines (I don't have many at my disposal), but cannot reproduce on a third. The two I can reproduce it on are two and four core intel duo's. The one I cannot reproduce on is an older, single core machine. I am leaning towards some kind of thread safety issue. In searching for similar problems, I found several references to similar crashes attributed to snd_dlobj_cache_cleanup() perhaps not being thread safe. e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=482797#c14 and http://osdir.com/ml/attachments/txtpisfDmzbcN.txt (and from that: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2124 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589896 ) I've found that removing the calls to snd_config_update_free_global() avoid the issue. I'm not even sure they are needed, but all the same I wanted to discuss the core issue. The MEMORY-LEAK file suggests that it should only be called after all snd_*_open() calls, but it doesn't indicate if this is just a recommendation or mandatory. Is the *only* purpose of this call to make valgrind happy? Or does it serve some other useful purpose too? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]

2 3

[alsa-devel] Implementing full-duplex realtime sound processor
by Gregory Bonik 23 Aug '10

23 Aug '10

Hi there, I'm trying to implement a full-duplex realtime sound processing app. I.e., it should capture a stream from a soundcard, do some processing on it and play it with minimal latency. I don't want to use JACK or any other higher-level API, so I'm looking for the best way to do it directly with ALSA. So far I've discovered three approaches: a) Just use blocking read/write functions. This approach seems flawed to me, since a separate thread is required for writing. Synchronizing between threds also introduces additional latency. b) Use the alsalib's asynchronous functionality. At first sight it sounds attractively, but googling for it gets not so happy results. For example, the alsa.opensrc.org wiki claims this functionality is unstable, especially in combination with PulseAudio. I don't know if it's true or not, but it discourages me even from trying it. c) Use synchronous I/O multiplexing (i.e poll syscall) together with non-blocking mode (much like doing I/O on network sockets). It becomes possible with the snd_pcm_poll_descriptors* family of functions. So I decided to try the third way first and wrote a simple test program. I'm using Ubuntu and therefore have PulseAudio sound system. So my program worked successfully through PulseAudio (i. e. with 'default' pcm). But when I tried to run it directly on hw:0,0, it hung in the poll() system call, waiting infinitely for an event on a capturing PCM, as if there was no data available for capturing. I started to look through ALSA API's functions and found occasionally snd_pcm_start. I've never seen it in any tutorial, but I decided to try calling it just after snd_pcm_prepare() for my capturing pcm handle and it did the trick. But if I call this function on a playback pcm handle, it fails with 'Broken pipe' error. To sum it up, I have the following questions: - What does actually snd_pcm_start() do? - Why does it fail on a playback device and do the job on a capture device? - Why does my program work without it when I'm using PulseAudio? - Am I generally on the right way or should I use other approach? Thanks, Gregory Bonik.

2 2

[alsa-devel] aplay -l vs. aplay -L: Missing PCMs?
by Stephen Warren 23 Aug '10

23 Aug '10

The Azalia controller on NVIDIA GPUs gives 4 ALSA hw devices: (on card 1): [swarren@swarren-lx2 ~]$ sudo aplay -l **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 0: ALC1200 Analog [ALC1200 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 3: ALC1200 Digital [ALC1200 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia_1 [HDA NVidia], device 3: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia_1 [HDA NVidia], device 7: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia_1 [HDA NVidia], device 8: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia_1 [HDA NVidia], device 9: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 ... all of which appear to work OK. However, the list of available "PCMs" from aplay -L doesn't expose them all: [swarren@swarren-lx2 ~]$ sudo aplay -L front:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Analog Front speakers surround40:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers hdmi:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Digital HDMI Audio Output null Discard all samples (playback) or generate zero samples (capture) pulse Playback/recording through the PulseAudio sound server hdmi:CARD=NVidia_1 HDA NVidia, NVIDIA HDMI HDMI Audio Output Similarly, pulseaudio only shows one output for the GPU; I assume it uses the same enumeration mechanism for ALSA sinks as "aplay -L". Instead, I imagined that I'd see 4 PCMs listed by "aplay -L"; one for each converter. Is this an incorrect assumption? How would I make that happen? I imagine that's why Google shows up so many hits on probe_mask for NVIDIA GPUs, so that the one that does show up is the one users want? Thanks. -- nvpublic

3 7

[alsa-devel] HDMI hot-plug/ELD issues
by pl bossart 23 Aug '10

23 Aug '10

Hi, I was testing my pulseaudio AC3 passthrough patch on my new laptop (all Intel hw, Corei5/IbexPeak, 2.6.35) and noticed a set of issues with the HDMI output: 1. Playback can happen even if there's no HDMI cable plugged. Or when I remove the cable, the player isn't notified and keeps sending data to the driver. This is fine for PCM but I noticed that the receiver can handle some trouble synchronizing with in AC3-passthrough mode if the cable is inserted after the playback starts. It would be much cleaner to allow playback only when there's an actual cable connected, and to return -ENODEV or something to apps when this happens. 2. It looks like the ELD info is invalid in /proc/asound/cards/. Tried both with my TV and AV receiver, no luck, all zeroes except for 'monitor_present' monitor_present 1 eld_valid 0 monitor_name connection_type HDMI eld_version [0x0] reserved edid_version [0x0] no CEA EDID Timing Extension block present manufacture_id 0x0 product_id 0x0 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH sad_count 0 Is there a missing link with the display driver so that this info would make sense? I remember having a conversation with Fengguang Wu on this, but I can't remember what the outcome was. Or is this a case of back luck with broken hardware not sending the legal EDID info? Thanks for your help on this. -Pierre

2 2

[alsa-devel] Problem to init AD1938 on i.MX25
by Sven Zeisberg 23 Aug '10

23 Aug '10

Hello, we're working on an ALSA driver for AD1938 for i.MX25 based system. On the I²S the CODEC is Master. On the SPI, the MCU is Master. SSI seems to work (when we set the CODEC as Master by Hardware). We have problems to get the communication via SPI working. The CODEC requires 24Bit words and we can set SPI according to this in the board-file and verify this also with a logic analyzer. However, we can send only one word to the CODEC! This first word is transferred correctly, but all subsequent transfers show no activity on the SPI lines. We do not get any error messages from the SPI drivers! All SPI writes after the first word seem to be executed in software but show not effect in hardware. All reads return 0xff. We assume that something with the set-up of the platform device is wrong: if we do not set the 24 Bit word size for each message, the SPI transfer is only 8 bit long - only when we set 24 bit in the spi_transfer struct for a transmission, the correct signals appear on the logic analyzer. Could anybody point us to an example of platform device set-up for a similar CODEC on this MCU? Are there known limitations of SPI transfers on the i.MX24 (like it can do only 8-Bit transfers)? Any idea for further investigations would be highly appreciated...! We have the following SPI / SSI set-up in the board file: static struct pad_desc stk5_ad1938_pads[] = { MX25_PAD_RW__AUD4_TXFS, MX25_PAD_EB0__AUD4_TXD, MX25_PAD_EB1__AUD4_RXD, MX25_PAD_OE__AUD4_TXC, }; static int stk5_ad1938_plat_init(void) { int ret; DBG(0, "%s: \n", __FUNCTION__); ret = mxc_iomux_v3_setup_multiple_pads(stk5_ad1938_pads, ARRAY_SIZE(stk5_ad1938_pads)); return ret; } static void stk5_ad1938_plat_finit(void) { DBG(0, "%s: \n", __FUNCTION__); mxc_iomux_v3_release_multiple_pads(stk5_ad1938_pads, ARRAY_SIZE(stk5_ad1938_pads)); } static struct mxc_audio_platform_data stk5_ad1938_data = { .ssi_num = 0, .src_port = 1, .ext_port = 4, .sysclk = 11289600, .init = stk5_ad1938_plat_init, .finit = stk5_ad1938_plat_finit, }; static struct platform_device stk5_ad1938_device = { .name = "imx-ad1938", .dev = { .platform_data =&stk5_ad1938_data, }, }; static int __init stk5_ad1938_init(void) { DBG(0, "%s: Registering device %s\n", __FUNCTION__, stk5_ad1938_device.name); return platform_device_register(&stk5_ad1938_device); } arch_initcall(stk5_ad1938_init); static int stk5_spi_chipselect[] = { MXC_SPI_CS(0), }; static struct pad_desc stk5_cspi1_pads[] = { MX25_PAD_CSPI1_MOSI__CSPI1_MOSI, MX25_PAD_CSPI1_MISO__CSPI1_MISO, MX25_PAD_CSPI1_SS0__CSPI1_SS0, MX25_PAD_CSPI1_SS1__CSPI1_SS1, MX25_PAD_CSPI1_SCLK__CSPI1_SCLK, MX25_PAD_CSPI1_RDY__CSPI1_RDY, }; static struct spi_device ad1938_spi_chip_info = { .bits_per_word = 24, }; static struct spi_board_info stk5_spi_info[] = { { .modalias = "ad1938", .max_speed_hz = 10000000, .bus_num = 0, .chip_select = 0, .controller_data =&ad1938_spi_chip_info, .mode = SPI_MODE_0, }, }; static struct spi_imx_master stk5_spi1_data = { .chipselect = stk5_spi_chipselect, .num_chipselect = ARRAY_SIZE(stk5_spi_chipselect), }; static int __init stk5_spi_register(void) { int ret; ret = mxc_iomux_v3_setup_multiple_pads(stk5_cspi1_pads, ARRAY_SIZE(stk5_cspi1_pads)); if (ret) { printk(KERN_ERR "Failed to configure CSPI1 pads\n"); return ret; } ret = spi_register_board_info(stk5_spi_info, ARRAY_SIZE(stk5_spi_info)); if (ret) { printk(KERN_ERR "%s: Failed to register SPI board_info: %d\n", __FUNCTION__, ret); goto err; } ret = mxc_register_device(&mxc_spi_device0,&stk5_spi1_data); DBG(0, "%s: mxc_register_device() returned: %d\n", __FUNCTION__, ret); return 0; err: mxc_iomux_v3_release_multiple_pads(stk5_cspi1_pads, ARRAY_SIZE(stk5_cspi1_pads)); return ret; } device_initcall(stk5_spi_register); And the following functino to write to the CODEC Registers: static int ad1938_write_reg(struct snd_soc_codec *codec, unsigned int reg, unsigned int value) { u8 *reg_cache = codec->reg_cache; int ret = 0; if (value != reg_cache[reg]) { uint8_t buf[AD1938_SPI_BUFLEN]; struct spi_transfer t = { .tx_buf = buf, .len = AD1938_SPI_BUFLEN, .bits_per_word = 24, .cs_change = 0, }; struct spi_message m; buf[2] = AD1938_SPI_ADDR<< 1; buf[1] = reg; buf[0] = value; spi_message_init(&m); spi_message_add_tail(&t,&m); m.is_dma_mapped =0; printk(KERN_ERR "SPI-WRITE->Reg= %x, value=%x\n",reg,buf[2]); ret = spi_sync(codec->control_data,&m); printk(KERN_ERR "SPI-WRITE->Return %i\n",ret); if (ret == 0) reg_cache[reg] = value; } return ret; } BR, Sven Zeisberg

3 4

[alsa-devel] ASoC update for 2.6.36
by Mark Brown 23 Aug '10

23 Aug '10

The following changes since commit b2c1e07b81a126e5846dfc3d36f559d861df59f4: ASoC: Remove DSP mode support for WM8776 (2010-08-16 11:46:57 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.36 Sascha Hauer (1): ASoC: i.MX ssi: use SSI_STCCR in synchronous mode Simple, non-invasive bug fix. sound/soc/imx/imx-ssi.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)

2 1

[alsa-devel] [PATCH 1/3] ASoC: pxa2xx-i2s is the proper name of the I2S DAI, not pxa-i2s.
by Ian Lartey 23 Aug '10

23 Aug '10

Signed-off-by: Ian Lartey <ian(a)opensource.wolfsonmicro.com> --- sound/soc/pxa/imote2.c | 2 +- sound/soc/pxa/magician.c | 2 +- sound/soc/pxa/poodle.c | 2 +- sound/soc/pxa/z2.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/pxa/imote2.c b/sound/soc/pxa/imote2.c index 03765fc..154fc6f 100644 --- a/sound/soc/pxa/imote2.c +++ b/sound/soc/pxa/imote2.c @@ -63,7 +63,7 @@ static struct snd_soc_ops imote2_asoc_ops = { static struct snd_soc_dai_link imote2_dai = { .name = "WM8940", .stream_name = "WM8940", - .cpu_dai_name = "pxa-i2s", + .cpu_dai_name = "pxa2xx-i2s", .codec_dai_name = "wm8940-hifi", .platform_name = "pxa-pcm-audio", .codec_name = "wm8940-codec.0-0034", diff --git a/sound/soc/pxa/magician.c b/sound/soc/pxa/magician.c index 608bc3d..b8207ce 100644 --- a/sound/soc/pxa/magician.c +++ b/sound/soc/pxa/magician.c @@ -437,7 +437,7 @@ static struct snd_soc_dai_link magician_dai[] = { { .name = "uda1380", .stream_name = "UDA1380 Capture", - .cpu_dai_name = "pxa-i2s", + .cpu_dai_name = "pxa2xx-i2s", .codec_dai_name = "uda1380-hifi-capture", .platform_name = "pxa-pcm-audio", .codec_name = "uda1380-codec.0-0018", diff --git a/sound/soc/pxa/poodle.c b/sound/soc/pxa/poodle.c index fa752f6..af84ee9 100644 --- a/sound/soc/pxa/poodle.c +++ b/sound/soc/pxa/poodle.c @@ -266,7 +266,7 @@ static int poodle_wm8731_init(struct snd_soc_pcm_runtime *rtd) static struct snd_soc_dai_link poodle_dai = { .name = "WM8731", .stream_name = "WM8731", - .cpu_dai_name = "pxa-i2s", + .cpu_dai_name = "pxa2xx-i2s", .codec_dai_name = "wm8731-hifi", .platform_name = "pxa-pcm-audio", .codec_name = "wm8731-codec.0-001a", diff --git a/sound/soc/pxa/z2.c b/sound/soc/pxa/z2.c index 704f74b..4cc841b 100644 --- a/sound/soc/pxa/z2.c +++ b/sound/soc/pxa/z2.c @@ -189,7 +189,7 @@ static struct snd_soc_ops z2_ops = { static struct snd_soc_dai_link z2_dai = { .name = "wm8750", .stream_name = "WM8750", - .cpu_dai_name = "pxa-i2s", + .cpu_dai_name = "pxa2xx-i2s", .codec_dai_name = "wm8750-hifi", .platform_name = "pxa-pcm-audio", .codec_name = "wm8750-codec.0-001a", -- 1.7.0.4

3 4

[alsa-devel] ASoC i.MX ssi: use SSI_STCCR in synchronous mode
by Sascha Hauer 23 Aug '10

23 Aug '10

Hi, This time with cc list. Please consider applying for -rc. Sascha In synchronous mode the SSI_SRCCR values are ignored. Instead SSI_STCCR must be used for both receiving and transmitting. Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> --- sound/soc/imx/imx-ssi.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/imx/imx-ssi.c b/sound/soc/imx/imx-ssi.c index a11daa1..c81da05 100644 --- a/sound/soc/imx/imx-ssi.c +++ b/sound/soc/imx/imx-ssi.c @@ -254,6 +254,9 @@ static int imx_ssi_hw_params(struct snd_pcm_substream *substream, dma_data = &ssi->dma_params_rx; } + if (ssi->flags & IMX_SSI_SYN) + reg = SSI_STCCR; + snd_soc_dai_set_dma_data(cpu_dai, substream, dma_data); sccr = readl(ssi->base + reg) & ~SSI_STCCR_WL_MASK; -- 1.7.1 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

3 2

[alsa-devel] [PATCH] ASoC: Add build infrastructure for WL1273
by Mark Brown 23 Aug '10

23 Aug '10

The Makefile and Kconfig updates for WL1273 appear to have been mising from the patch posted, add them. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/Kconfig | 4 ++++ sound/soc/codecs/Makefile | 2 ++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index a3cfc18..155c127 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -41,6 +41,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TWL6040 if TWL4030_CORE select SND_SOC_UDA134X select SND_SOC_UDA1380 if I2C + select SND_SOC_WL1273 if WL1273_CORE select SND_SOC_WM2000 if I2C select SND_SOC_WM8350 if MFD_WM8350 select SND_SOC_WM8400 if MFD_WM8400 @@ -193,6 +194,9 @@ config SND_SOC_UDA134X config SND_SOC_UDA1380 tristate +config SND_SOC_WL1273 + tristate + config SND_SOC_WM8350 tristate diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index b9c4358..10d468e 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -27,6 +27,7 @@ snd-soc-twl4030-objs := twl4030.o snd-soc-twl6040-objs := twl6040.o snd-soc-uda134x-objs := uda134x.o snd-soc-uda1380-objs := uda1380.o +snd-soc-wl1273-objs := wl1273.o snd-soc-wm8350-objs := wm8350.o snd-soc-wm8400-objs := wm8400.o snd-soc-wm8510-objs := wm8510.o @@ -98,6 +99,7 @@ obj-$(CONFIG_SND_SOC_TWL4030) += snd-soc-twl4030.o obj-$(CONFIG_SND_SOC_TWL6040) += snd-soc-twl6040.o obj-$(CONFIG_SND_SOC_UDA134X) += snd-soc-uda134x.o obj-$(CONFIG_SND_SOC_UDA1380) += snd-soc-uda1380.o +obj-$(CONFIG_SND_SOC_WL1273) += snd-soc-wl1273.o obj-$(CONFIG_SND_SOC_WM8350) += snd-soc-wm8350.o obj-$(CONFIG_SND_SOC_WM8400) += snd-soc-wm8400.o obj-$(CONFIG_SND_SOC_WM8510) += snd-soc-wm8510.o -- 1.7.1

2 1

[alsa-devel] [PATCH] ASoC: omap: rx51: Use gpio_set_value_cansleep for speaker amp control
by Jarkko Nikula 23 Aug '10

23 Aug '10

Speaker amplifier is controlled by TWL4030 GPIO which may sleep. Therefore use gpio_set_value_cansleep to get rid of runtime warning that is introduced after the commit 9c4ba94 and to get a stack trace if ever executing this code in atomic context. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> --- sound/soc/omap/rx51.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/omap/rx51.c b/sound/soc/omap/rx51.c index d1d8098..04b5723 100644 --- a/sound/soc/omap/rx51.c +++ b/sound/soc/omap/rx51.c @@ -146,9 +146,9 @@ static int rx51_spk_event(struct snd_soc_dapm_widget *w, struct snd_kcontrol *k, int event) { if (SND_SOC_DAPM_EVENT_ON(event)) - gpio_set_value(RX51_SPEAKER_AMP_TWL_GPIO, 1); + gpio_set_value_cansleep(RX51_SPEAKER_AMP_TWL_GPIO, 1); else - gpio_set_value(RX51_SPEAKER_AMP_TWL_GPIO, 0); + gpio_set_value_cansleep(RX51_SPEAKER_AMP_TWL_GPIO, 0); return 0; } -- 1.7.1

3 2