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

[alsa-devel] ASoC updates for 2.6.30
by Mark Brown 15 May '09

15 May '09

The following changes since commit 1ffafeb556d50de8039e14f1cbbe58e9e4549915: Mike Rapoport (1): pxa2xx-ac97: fix reset gpio mode setting are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.30 David Brownell (3): ASoC: davinci-pcm buildfixes ASoC: DaVinci I2S updates ASoC: DaVinci EVM board support buildfixes arch/arm/mach-davinci/include/mach/asp.h | 25 ++++++++++ sound/soc/davinci/Kconfig | 7 ++- sound/soc/davinci/davinci-evm.c | 63 ++++++++++++++++++++++----- sound/soc/davinci/davinci-i2s.c | 26 ++++++++++- sound/soc/davinci/davinci-pcm.c | 71 +++++++++++++++++------------ 5 files changed, 146 insertions(+), 46 deletions(-) create mode 100644 arch/arm/mach-davinci/include/mach/asp.h

2 3

[alsa-devel] [PATCH 0/1] ALC889A chip identification
by Torben Schulz 15 May '09

15 May '09

Hi everyone, here is my first patch, with allows the intel-hda module to identify the Realtek ALC889A chip correctly. Everything else stands in the changelog of the mail with the patch. This some kind of test-run for my big MacBook 3,1 patch, so any feedback - especially in case of formal mistakes - is welcome. Bai Torben

1 0

[alsa-devel] [PATCH V1 00/13] mpc5200 audio rework for AC97
by Jon Smirl 14 May '09

14 May '09

The following series implements audio support for the mpc5200. It adds an AC97 driver and STAC9766 codec driver. Board support for the Efika and Phytec pcm030 are also included. I'm sure everyone will have some edits on this first version. --- Jon Smirl (13): Support for AC97 on Phytec pmc030 base board. Fabric bindings for STAC9766 on the Efika AC97 driver for mpc5200 Codec for STAC9766 used on the Efika Main rewite of the mpc5200 audio DMA code Have the WM9712 driver self register itself Add SNDRV_PCM_FMTBIT_S32_BE as a valid AC97 format Allow a custom ASOC fabric driver with soc-of-simple Add a few more mpc5200 PSC defines redo 2008f137e92220b98120c4803499cdddb2b0fb06 Rename the PSC functions to DMA Basic split of mpc5200 DMA code out from mpc5200_psc_i2s Temporarily undo 2008f137e92220b98120c4803499cdddb2b0fb06 arch/powerpc/boot/dts/pcm030.dts | 8 arch/powerpc/include/asm/mpc52xx_psc.h | 10 arch/powerpc/platforms/52xx/efika.c | 8 include/sound/soc-dai.h | 3 include/sound/soc-of-simple.h | 16 + sound/last.c | 6 sound/soc/codecs/Kconfig | 4 sound/soc/codecs/Makefile | 2 sound/soc/codecs/stac9766.c | 491 ++++++++++++++++++++++ sound/soc/codecs/stac9766.h | 21 + sound/soc/codecs/tlv320aic26.c | 2 sound/soc/codecs/wm9712.c | 34 ++ sound/soc/fsl/Kconfig | 30 + sound/soc/fsl/Makefile | 6 sound/soc/fsl/efika-audio-fabric.c | 95 ++++ sound/soc/fsl/mpc5200_dma.c | 693 +++++++++++++++++++++++++++++++ sound/soc/fsl/mpc5200_dma.h | 83 ++++ sound/soc/fsl/mpc5200_psc_ac97.c | 379 +++++++++++++++++ sound/soc/fsl/mpc5200_psc_ac97.h | 13 + sound/soc/fsl/mpc5200_psc_i2s.c | 707 +------------------------------- sound/soc/fsl/soc-of-simple.c | 160 ++++++- 21 files changed, 2053 insertions(+), 718 deletions(-) create mode 100644 sound/soc/codecs/stac9766.c create mode 100644 sound/soc/codecs/stac9766.h create mode 100644 sound/soc/fsl/efika-audio-fabric.c create mode 100644 sound/soc/fsl/mpc5200_dma.c create mode 100644 sound/soc/fsl/mpc5200_dma.h create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.c create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.h -- Jon Smirl jonsmirl(a)gmail.com

3 30

[alsa-devel] [PATCH 1/4 v3] pxa2xx-i2s: Proper hw initialization
by Karl Beldan 14 May '09

14 May '09

Make sure we are in a know good state at end of probe : Reset FIFO logic and registers, and make sure REC and RPL functions along with FIFO service are disabled (SACR0_RST enables REC and RPL). Resetting loses current settings so remove reset from stream startup. Now reset occurs only at probe. Signed-off-by: Karl Beldan <karl.beldan(a)mobile-devices.fr> --- sound/soc/pxa/pxa2xx-i2s.c | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c index 2f4b6e4..59cc4f5 100644 --- a/sound/soc/pxa/pxa2xx-i2s.c +++ b/sound/soc/pxa/pxa2xx-i2s.c @@ -106,10 +106,8 @@ static int pxa2xx_i2s_startup(struct snd_pcm_substream *substream, if (IS_ERR(clk_i2s)) return PTR_ERR(clk_i2s); - if (!cpu_dai->active) { - SACR0 |= SACR0_RST; + if (!cpu_dai->active) SACR0 = 0; - } return 0; } @@ -346,6 +344,19 @@ static int pxa2xx_i2s_probe(struct platform_device *dev) if (ret != 0) clk_put(clk_i2s); + /* + * PXA Developer's Manual: + * If SACR0[ENB] is toggled in the middle of a normal operation, + * the SACR0[RST] bit must also be set and cleared to reset all + * I2S controller registers. + */ + SACR0 = SACR0_RST; + SACR0 = 0; + /* Make sure RPL and REC are disabled */ + SACR1 = SACR1_DRPL | SACR1_DREC; + /* Along with FIFO servicing */ + SAIMR &= ~(SAIMR_RFS | SAIMR_TFS); + return ret; } -- 1.6.3.rc1.34.g0be9b -- Karl

2 4

[alsa-devel] Dynamically registering a codec
by Jon Smirl 14 May '09

14 May '09

On PowerPC the device tree is used to dynamically load the correct codec module. How am I supposed to get this dynamically loaded module registered? The WM8580 codec registers itself. Modifying the WM9712 codec to register itself on device load works for me. If I don't do this how am I supposed to dynamically find the DAI pointer so that I can call snd_soc_register_dais()? diff --git a/sound/soc/codecs/wm9712.c b/sound/soc/codecs/wm9712.c index 550c903..cb0e679 100644 --- a/sound/soc/codecs/wm9712.c +++ b/sound/soc/codecs/wm9712.c @@ -20,6 +20,7 @@ #include <sound/initval.h> #include <sound/soc.h> #include <sound/soc-dapm.h> +#include <sound/soc-of-simple.h> #include "wm9712.h" #define WM9712_VERSION "0.4" @@ -740,6 +741,39 @@ struct snd_soc_codec_device soc_codec_dev_wm9712 = { }; EXPORT_SYMBOL_GPL(soc_codec_dev_wm9712); +static int __init wm9712_probe(struct platform_device *pdev) +{ + snd_soc_register_dais(wm9712_dai, ARRAY_SIZE(wm9712_dai)); +#if defined(CONFIG_SND_SOC_OF_SIMPLE) + /* Tell the of_soc helper about this codec */ + of_snd_soc_register_codec(&soc_codec_dev_wm9712, pdev->dev.archdata.of_node, + wm9712_dai, ARRAY_SIZE(wm9712_dai), + pdev->dev.archdata.of_node); +#endif + return 0; +} + +static struct platform_driver wm9712_driver = +{ + .probe = wm9712_probe, + .driver = { + .name = "wm9712", + }, +}; + +static __init int wm9712_driver_init(void) +{ + return platform_driver_register(&wm9712_driver); +} + +static __exit void wm9712_driver_exit(void) +{ +} + +module_init(wm9712_driver_init); +module_exit(wm9712_driver_exit); + + MODULE_DESCRIPTION("ASoC WM9711/WM9712 driver"); MODULE_AUTHOR("Liam Girdwood"); MODULE_LICENSE("GPL"); -- Jon Smirl jonsmirl(a)gmail.com

2 11

[alsa-devel] Intel HDA fix for Macbook 3,1 and newer
by Le Torbi 14 May '09

14 May '09

Hi guys, I'm new to this list and never contributed anything to such a big open-source project like ALSA, so please forgive me if I make some newbie mistakes. But back the the important stuff: I own a MacBook 3,1 and experienced some sound issues with this. I didn't have no sound, but the sound was quite low in quality and volume. After some research and a lot of wrong ways I stumbled upon bug 0004086 "MacBook 4,1 sounds tinny or not at all " in the ALSA bug tracking system (https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4086) and managed to fix it. Any details can be found in the bug report as well as a link to my patch. My questions now are: 1. Could an exprineced ALSA-Coder check my patch for bugs or "newbie code glitches"? 2. What do I have to do, to get my patch in the official code repository? Thanks in advance for any help. Bai Le Torbi

3 8

[alsa-devel] [PATCH] ASoC: Added OMAP3 EVM support in ASoC.
by Anuj Aggarwal 14 May '09

14 May '09

Resending the patch after fixing the minor issues. Signed-off-by: Anuj Aggarwal <anuj.aggarwal(a)ti.com> --- sound/soc/omap/Kconfig | 8 +++ sound/soc/omap/Makefile | 2 + sound/soc/omap/omap3evm.c | 147 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 157 insertions(+), 0 deletions(-) create mode 100644 sound/soc/omap/omap3evm.c diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 675732e..b771238 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -39,6 +39,14 @@ config SND_OMAP_SOC_OMAP2EVM help Say Y if you want to add support for SoC audio on the omap2evm board. +config SND_OMAP_SOC_OMAP3EVM + tristate "SoC Audio support for OMAP3EVM board" + depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3EVM + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for SoC audio on the omap3evm board. + config SND_OMAP_SOC_SDP3430 tristate "SoC Audio support for Texas Instruments SDP3430" depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP_3430SDP diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 0c9e4ac..a37f498 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -10,6 +10,7 @@ snd-soc-n810-objs := n810.o snd-soc-osk5912-objs := osk5912.o snd-soc-overo-objs := overo.o snd-soc-omap2evm-objs := omap2evm.o +snd-soc-omap3evm-objs := omap3evm.o snd-soc-sdp3430-objs := sdp3430.o snd-soc-omap3pandora-objs := omap3pandora.o snd-soc-omap3beagle-objs := omap3beagle.o @@ -18,6 +19,7 @@ obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o obj-$(CONFIG_MACH_OMAP2EVM) += snd-soc-omap2evm.o +obj-$(CONFIG_MACH_OMAP3EVM) += snd-soc-omap3evm.o obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o diff --git a/sound/soc/omap/omap3evm.c b/sound/soc/omap/omap3evm.c new file mode 100644 index 0000000..9114c26 --- /dev/null +++ b/sound/soc/omap/omap3evm.c @@ -0,0 +1,147 @@ +/* + * omap3evm.c -- ALSA SoC support for OMAP3 EVM + * + * Author: Anuj Aggarwal <anuj.aggarwal(a)ti.com> + * + * Based on sound/soc/omap/beagle.c by Steve Sakoman + * + * Copyright (C) 2008 Texas Instruments, Incorporated + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind, + * whether express or implied; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ + +#include <linux/clk.h> +#include <linux/platform_device.h> +#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/soc.h> +#include <sound/soc-dapm.h> + +#include <asm/mach-types.h> +#include <mach/hardware.h> +#include <mach/gpio.h> +#include <mach/mcbsp.h> + +#include "omap-mcbsp.h" +#include "omap-pcm.h" +#include "../codecs/twl4030.h" + +static int omap3evm_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 *codec_dai = rtd->dai->codec_dai; + struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; + int ret; + + /* Set codec DAI configuration */ + 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) { + printk(KERN_ERR "Can't set codec DAI configuration\n"); + return ret; + } + + /* Set cpu DAI configuration */ + 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) { + printk(KERN_ERR "Can't set cpu DAI configuration\n"); + return ret; + } + + /* Set the codec system clock for DAC and ADC */ + ret = snd_soc_dai_set_sysclk(codec_dai, 0, 26000000, + SND_SOC_CLOCK_IN); + if (ret < 0) { + printk(KERN_ERR "Can't set codec system clock\n"); + return ret; + } + + return 0; +} + +static struct snd_soc_ops omap3evm_ops = { + .hw_params = omap3evm_hw_params, +}; + +/* Digital audio interface glue - connects codec <--> CPU */ +static struct snd_soc_dai_link omap3evm_dai = { + .name = "TWL4030", + .stream_name = "TWL4030", + .cpu_dai = &omap_mcbsp_dai[0], + .codec_dai = &twl4030_dai[TWL4030_DAI_HIFI], + .ops = &omap3evm_ops, +}; + +/* Audio machine driver */ +static struct snd_soc_card snd_soc_omap3evm = { + .name = "omap3evm", + .platform = &omap_soc_platform, + .dai_link = &omap3evm_dai, + .num_links = 1, +}; + +/* Audio subsystem */ +static struct snd_soc_device omap3evm_snd_devdata = { + .card = &snd_soc_omap3evm, + .codec_dev = &soc_codec_dev_twl4030, +}; + +static struct platform_device *omap3evm_snd_device; + +static int __init omap3evm_soc_init(void) +{ + int ret; + + if (!machine_is_omap3evm()) { + pr_err("Not OMAP3 EVM!\n"); + return -ENODEV; + } + pr_info("OMAP3 EVM SoC init\n"); + + omap3evm_snd_device = platform_device_alloc("soc-audio", -1); + if (!omap3evm_snd_device) { + printk(KERN_ERR "Platform device allocation failed\n"); + return -ENOMEM; + } + + platform_set_drvdata(omap3evm_snd_device, &omap3evm_snd_devdata); + omap3evm_snd_devdata.dev = &omap3evm_snd_device->dev; + *(unsigned int *)omap3evm_dai.cpu_dai->private_data = 1; + + ret = platform_device_add(omap3evm_snd_device); + if (ret) + goto err1; + + return 0; + +err1: + printk(KERN_ERR "Unable to add platform device\n"); + platform_device_put(omap3evm_snd_device); + + return ret; +} + +static void __exit omap3evm_soc_exit(void) +{ + platform_device_unregister(omap3evm_snd_device); +} + +module_init(omap3evm_soc_init); +module_exit(omap3evm_soc_exit); + +MODULE_AUTHOR("Anuj Aggarwal <anuj.aggarwal(a)ti.com>"); +MODULE_DESCRIPTION("ALSA SoC OMAP3 EVM"); +MODULE_LICENSE("GPLv2"); -- 1.6.2.4

3 3

[alsa-devel] mute and unmute
by Deweirdt Peter-Jan 14 May '09

14 May '09

Hi, I have written a small (proof of concept) program that is providing audio on all my channels on the audio. What I have noticed is that the "Speaker" channel gets muted every time. I don't know how or by who? When I change with alsamixer the mute then after less then 5 sec it get muted. How can I debug who is muting my 'Speaker' channel. Here is some output. [root@localhost ~]# amixer -c 0 Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 75 [59%] [-20.00dB] [on] Front Right: Playback 75 [59%] [-20.00dB] [on] Simple mixer control 'Headphone SZCMode',0 Capabilities: penum Items: 'Immediate' 'Zero Cross' 'Soft Ramp' 'Soft Ramp on Zero Cross' Item0: 'Soft Ramp' Simple mixer control 'Line',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 63 Front Left: Capture 51 [81%] [0.00dB] [off] Front Right: Capture 51 [81%] [0.00dB] [off] Simple mixer control 'Line Input',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 3 Front Left: Capture 0 [0%] [0.00dB] Front Right: Capture 0 [0%] [0.00dB] Simple mixer control 'Line-In PGA Mode',0 Capabilities: cenum Items: 'Differential' 'Single-ended' Item0: 'Differential' Simple mixer control 'Line-Out',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 115 [91%] [0.00dB] [on] Front Right: Playback 115 [91%] [0.00dB] [on] Simple mixer control 'Line-In SZCMode',0 Capabilities: cenum Items: 'Immediate' 'Digital Immediate, Analog Zero Cross' 'Digital and Analog Soft Ramp' 'Digital Soft Ramp, Analog Zero Cross' Item0: 'Digital and Analog Soft Ramp' Simple mixer control 'Line-Out SZCMode',0 Capabilities: penum Items: 'Immediate' 'Zero Cross' 'Soft Ramp' 'Soft Ramp on Zero Cross' Item0: 'Soft Ramp' Simple mixer control 'Mic',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 63 Front Left: Capture 51 [81%] [0.00dB] [off] Front Right: Capture 51 [81%] [0.00dB] [off] Simple mixer control 'Mic Input',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 3 Front Left: Capture 0 [0%] [0.00dB] Front Right: Capture 0 [0%] [0.00dB] Simple mixer control 'Mic PGA Mode',0 Capabilities: cenum Items: 'Differential' 'Single-ended' Item0: 'Differential' Simple mixer control 'Mic SZCMode',0 Capabilities: cenum Items: 'Immediate' 'Digital Immediate, Analog Zero Cross' 'Digital and Analog Soft Ramp' 'Digital Soft Ramp, Analog Zero Cross' Item0: 'Digital and Analog Soft Ramp' Simple mixer control 'IEC958',0 Capabilities: pswitch pswitch-joined cswitch cswitch-joined Playback channels: Mono Capture channels: Mono Mono: Playback [off] Capture [off] Simple mixer control 'IEC958 Default PCM',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'Analog In',0 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [on] Simple mixer control 'Analog In',1 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [on] Simple mixer control 'Digital Input 1',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 2 Front Left: Capture 0 [0%] [0.00dB] Front Right: Capture 0 [0%] [0.00dB] Simple mixer control 'Digital Input 2',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 2 Front Left: Capture 0 [0%] [0.00dB] Front Right: Capture 0 [0%] [0.00dB] Simple mixer control 'Digital Mic',0 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [off] Simple mixer control 'Digital Mic',1 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [off] Simple mixer control 'Speakers',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 100 [79%] [-7.50dB] [off] Front Right: Playback 100 [79%] [-7.50dB] [off] Simple mixer control 'Speakers SZCMode',0 Capabilities: penum Items: 'Immediate' 'Zero Cross' 'Soft Ramp' 'Soft Ramp on Zero Cross' Item0: 'Soft Ramp' [root@localhost ~]# No I unmute the "Speaker" channel: [root@localhost ~]# amixer set -c 0 Speakers unmute; date Simple mixer control 'Speakers',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 100 [79%] [-7.50dB] [on] Front Right: Playback 100 [79%] [-7.50dB] [on] Thu May 14 16:20:57 EDT 2009 [root@localhost ~]# amixer get -c 0 Speakers; date Simple mixer control 'Speakers',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 100 [79%] [-7.50dB] [on] Front Right: Playback 100 [79%] [-7.50dB] [on] Thu May 14 16:20:58 EDT 2009 [root@localhost ~]# amixer get -c 0 Speakers; date Simple mixer control 'Speakers',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 100 [79%] [-7.50dB] [off] Front Right: Playback 100 [79%] [-7.50dB] [off] Thu May 14 16:21:00 EDT 2009 [root@localhost ~]# amixer get -c 0 Speakers; date Simple mixer control 'Speakers',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 100 [79%] [-7.50dB] [off] Front Right: Playback 100 [79%] [-7.50dB] [off] Thu May 14 16:21:01 EDT 2009 [root@localhost ~]#

1 0

[alsa-devel] appl_ptr and DMA overrun at end of stream
by Jon Smirl 14 May '09

14 May '09

I am having problem with DMA overrun at the end of the audio stream. Is there an official way to know the address of the last valid audio sample? mpc5200 ac97 is keeping a bunch of descriptors queued in a loop to continuously play music. I believe this is the way ALSA wants it. Now say the last period is half full. ALSA fills the other half with silence. When that period finishes playing it will generate an interrupt. ALSA comes back from that interrupt with trigger(STOP). But, our CPU is slow compared to a 3Ghz desktop, there is considerable latency from the period end interrupt to trigger(STOP) getting called. So the DMA hardware starts playing the next period before trigger(STOP) can get the DMA stopped. I turned off tried turning off BestComm, flushing the FIFO, and turning off the audio clocks. None can be done fast enough. That next period contains stale data from further back in the stream. When the front part of it plays it makes a burst of noise. What I need is the address of the end of valid data in the buffer. I need that address so that I can program the DMA automatically stop at end of stream and not overrun. Search around in the guys of ALSA I found appl_ptr. I can use appl_ptr to determine the location of end of stream and prevent DMA overrun. When there is no valid data I don't enqueue the descriptor. s->appl_ptr track the previous value of s->runtime->control->appl_ptr. The difference between these two is the amount of valid data in the buffer. When this difference goes to zero, I stop queue new buffers to ALSA. That fixes the DMA overrun. static void psc_dma_bcom_enqueue_next_buffer(struct psc_dma_stream *s) { struct bcom_bd *bd; while (s->appl_ptr < s->runtime->control->appl_ptr) { if (bcom_queue_full(s->bcom_task)) return; s->appl_ptr += s->period_size; /* Prepare and enqueue the next buffer descriptor */ bd = bcom_prepare_next_buffer(s->bcom_task); bd->status = s->period_bytes; bd->data[0] = s->period_next_pt; bcom_submit_next_buffer(s->bcom_task, NULL); /* Update for next period */ s->period_next_pt += s->period_bytes; if (s->period_next_pt >= s->period_end) s->period_next_pt = s->period_start; } } -- Jon Smirl jonsmirl(a)gmail.com

3 19

[alsa-devel] [RFC] ALSA vs. dedicated char device for a USB Audio Class gadget driver
by Laurent Pinchart 14 May '09

14 May '09

Hi everybody. Linux provides a USB Audio Class (UAC) driver on the USB host side, but a UAC gadget driver on the USB device side is currently missing. Considering plugging in this hole, I'm looking at userspace <-> kernelspace APIs. In a nutshell (let's consider recording, where the device appears to the host as a USB microphone), the kernel driver needs to be fed with audio data from a userspace application and stream those data on USB. Audio data can come from a real microphone (through an ALSA driver), a file, a network socket, ... the driver will not care. I need an API to transfer audio data from userspace to kernelspace. I initially thought about ALSA, but it turns out some assumptions made by ALSA are not fulfilled by my system. One of the most serious problems is that the UAC gadget driver doesn't have any audio clock. The only hardware clock available is the USB device controller interrupts generated at the USB transfer rate, and those are much faster than the audio sample rate. This will cause buffer underruns that I need to handle. I can thing of 3 solutions to solve this issue, and I'd like your opinion on them. 1. Get the userspace application to provide a clock to the driver. This could be done by writing to a /proc file, a special char device, or even by adding an ioctl to ALSA. Every time the driver receives a clock tick it would transfer one period of data. 2. Find out how much data is available in the ALSA ring buffer. I could then throttle USB interrupts when no data is available in the buffer and try again later. ALSA maintains a read and a write pointer (hw_ptr and appl_ptr) that can be accessed through the snd_pcm_*_avail() functions. However, I'm not sure how to handle proper locking, and I don't understand how runtime->boundary interacts with those functions. I've also heard that there's a free-running mode that will make those functions return bogus values. I'd appreciate help on this. 3. Use another API (dedicated character device, socket, ...) to transfer audio data from userspace to kernelspace. ALSA is way too big for my requirements (2 layers of abstraction, architectured around assumptions that make sense for real sound cards but not for my hardware, ...). On the other hand, it would be handy to use existing ALSA applications to driver the device. I'd appreciate comments regarding the API choice. How do you all expect to push data from a userspace application to a UAC driver on the device side ? If ALSA is *the* way, is one of the above solutions practical or is there a better way ? Best regards, Laurent Pinchart

1 0