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

[alsa-devel] [PATCH 0/7 v2] extract a simple dmaengine library from shdma.c
by Guennadi Liakhovetski 06 Feb '12

06 Feb '12

This is v2 of the simple DMA dmaengine library. It addresses Paul's comments to v1 - thanks, adds some comments. Guennadi Liakhovetski (7): dmaengine: add a simple dma library dma: shdma: prepare for simple DMA conversion mmc: sh_mmcif: remove unneeded struct sh_mmcif_dma, prepare for simple DMA mmc: sh_mobile_sdhi: prepare for conversion to simple DMA serial: sh-sci: prepare for conversion to simple DMA ASoC: SIU: prepare for conversion to simple DMA dma: shdma: convert to the simple DMA library drivers/dma/Kconfig | 4 + drivers/dma/Makefile | 1 + drivers/dma/dma-simple.c | 873 ++++++++++++++++++++++++++++ drivers/dma/shdma.c | 1138 +++++++++---------------------------- drivers/dma/shdma.h | 45 +- drivers/mmc/host/sh_mmcif.c | 24 +- drivers/mmc/host/sh_mobile_sdhi.c | 8 +- drivers/tty/serial/sh-sci.c | 8 +- include/linux/dma-simple.h | 124 ++++ include/linux/mmc/sh_mmcif.h | 8 +- include/linux/sh_dma.h | 39 +- sound/soc/sh/siu_pcm.c | 8 +- 12 files changed, 1334 insertions(+), 946 deletions(-) create mode 100644 drivers/dma/dma-simple.c create mode 100644 include/linux/dma-simple.h -- 1.7.2.5 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/

3 19

[alsa-devel] Some questions related to ALSA based duplex audio processing
by public-hk 02 Feb '12

02 Feb '12

Hi, I have just started to develop a duplex audio processing application based on ALSA. My development goals are - of course - maximum stability as well as lowest possible delay (latency). So, here is what I did on my Ubuntu laptop: 1) Setup of device/soundcard "hw:0,0" for processing at a samplerate of 44.1 kHz, buffersize 128 samples. 2) I created one input PCM device and one output PCM device handle 3) I use the function "snd_async_add_pcm_handler" to install a callback function (ASYNC mode), one for input, one for output. 4) I use "snd_pcm_link" to synchronize both pcm handles. 5) I use the mmap'ed area access My motivation to work the way I do is to maximize the control of processing behavior and to minimize the latency. E.g., I have understood from the docs that the snd_pcm_read/snd_pcm_write functions do nothing else than addressing the memory mapped areas. As a conclusion, I realize this access myself to have more control about it. And by using the async callbacks, I do not have to deal with blocking or non-blocking read functions or polling related issues. So far, I have realized the playback part and noticed some aspects which are not clear to me from the ALSA documentation: a) What is the most efficient way to realize duplex audio processing, the async way with mmap'ed read/write that I follow? b) At first, I created the pcm handles as follows: "snd_pcm_open (.., SND_PCM_ASYNC);" When starting to process audio (call of "snd_pcm_start"), I realized that the registered callback functions do not get called. I had to change this to "snd_pcm_open (.., 0);". Is that really intended, it seems contradictory? c) The function "snd_pcm_info_get_sync" is supposed to return a description of the synchronization behavior of a soundcard. In my case, I called this function for two soundcards (one USB and the laptop integrated soundcard). In both cases, the returned content is all zeros. Should not this be different for both devices? d) By default, it seems that the callbacks for audio frames come within a thread with normal priority. On Windows OS, I am used to increase the thread priority whenever starting my threads, but it is commonly not a good idea to increase the process priority. In the ALSA latency-example, the PROCESS priority is increased (which can be done only with superuser priv.). What is the recommended way in Linux to achieve lower latencies? In the future I will have to deal with synchronization of input and output since the samples arrive/leave my application in two independent callback functions. So what will I do: Once input samples are available I will store these in one buffer, and these samples will be output the next time when there is space in the output ring buffer. In order to minimize the latency, I would need to know more about the intended exact behavior of the ALSA lib which I did not find in the documentation: I) If linking input and output with "snd_pcm_link", I have understood that the changes of state for input and output PCM handle will occur synchronously. That is, when doing the operation such as "snd_pcm_prepare" on one of the handles, both handles will be affected. However, what does this means for audio processing on the frame level: If I use two callbacks for signal processing for input and output respectively installed based on the function "snd_async_add_pcm_handler", will these callbacks occur simultaneously? On Windows OS (speaking of ASIO sound) there is one callback in which input and output is handled simultaneously. Can I somehow setup ALSA to have a similar behavor? Thank you for any assistance and best regards HK

3 7

[alsa-devel] [PATCH 1/2] ASoC: Use dai_fmt in afeb9260 machine driver
by Axel Lin 01 Feb '12

01 Feb '12

Signed-off-by: Axel Lin <axel.lin(a)gmail.com> --- sound/soc/atmel/snd-soc-afeb9260.c | 23 ++--------------------- 1 files changed, 2 insertions(+), 21 deletions(-) diff --git a/sound/soc/atmel/snd-soc-afeb9260.c b/sound/soc/atmel/snd-soc-afeb9260.c index 4ca667d..cb0130c 100644 --- a/sound/soc/atmel/snd-soc-afeb9260.c +++ b/sound/soc/atmel/snd-soc-afeb9260.c @@ -46,29 +46,8 @@ static int afeb9260_hw_params(struct snd_pcm_substream *substream, { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct snd_soc_dai *codec_dai = rtd->codec_dai; - struct snd_soc_dai *cpu_dai = rtd->cpu_dai; int err; - /* Set codec DAI configuration */ - err = snd_soc_dai_set_fmt(codec_dai, - SND_SOC_DAIFMT_I2S| - SND_SOC_DAIFMT_NB_IF | - SND_SOC_DAIFMT_CBM_CFM); - if (err < 0) { - printk(KERN_ERR "can't set codec DAI configuration\n"); - return err; - } - - /* Set cpu DAI configuration */ - err = snd_soc_dai_set_fmt(cpu_dai, - SND_SOC_DAIFMT_I2S | - SND_SOC_DAIFMT_NB_IF | - SND_SOC_DAIFMT_CBM_CFM); - if (err < 0) { - printk(KERN_ERR "can't set cpu DAI configuration\n"); - return err; - } - /* Set the codec system clock for DAC and ADC */ err = snd_soc_dai_set_sysclk(codec_dai, 0, CODEC_CLOCK, SND_SOC_CLOCK_IN); @@ -129,6 +108,8 @@ static struct snd_soc_dai_link afeb9260_dai = { .platform_name = "atmel_pcm-audio", .codec_name = "tlv320aic23-codec.0-001a", .init = afeb9260_tlv320aic23_init, + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_IF | + SND_SOC_DAIFMT_CBM_CFM, .ops = &afeb9260_ops, }; -- 1.7.5.4

2 2

[alsa-devel] [PATCH 2/3] ARM: ux500: Add DMA-channels for MSP
by Ola Lilja 01 Feb '12

01 Feb '12

Add DMA-channels for MSP0, MSP1, MSP2 and MSP3. Signed-off-by: Ola Lilja <ola.o.lilja(a)stericsson.com> --- arch/arm/mach-ux500/devices-db8500.c | 6 ++++++ arch/arm/mach-ux500/include/mach/hardware.h | 2 ++ 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c index a7c6cdc..6e66d37 100644 --- a/arch/arm/mach-ux500/devices-db8500.c +++ b/arch/arm/mach-ux500/devices-db8500.c @@ -101,6 +101,9 @@ static const dma_addr_t dma40_tx_map[DB8500_DMA_NR_DEV] = { [DB8500_DMA_DEV41_SD_MM3_TX] = -1, [DB8500_DMA_DEV42_SD_MM4_TX] = -1, [DB8500_DMA_DEV43_SD_MM5_TX] = -1, + [DB8500_DMA_DEV14_MSP2_TX] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET, + [DB8500_DMA_DEV30_MSP1_TX] = U8500_MSP1_BASE + MSP_TX_RX_REG_OFFSET, + [DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET, }; /* Mapping between source event lines and physical device address */ @@ -133,6 +136,9 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = { [DB8500_DMA_DEV41_SD_MM3_RX] = -1, [DB8500_DMA_DEV42_SD_MM4_RX] = -1, [DB8500_DMA_DEV43_SD_MM5_RX] = -1, + [DB8500_DMA_DEV14_MSP2_RX] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET, + [DB8500_DMA_DEV30_MSP3_RX] = U8500_MSP3_BASE + MSP_TX_RX_REG_OFFSET, + [DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET, }; /* Reserved event lines for memcpy only */ diff --git a/arch/arm/mach-ux500/include/mach/hardware.h b/arch/arm/mach-ux500/include/mach/hardware.h index b6ba26a..d93d6db 100644 --- a/arch/arm/mach-ux500/include/mach/hardware.h +++ b/arch/arm/mach-ux500/include/mach/hardware.h @@ -30,6 +30,8 @@ #include <mach/db8500-regs.h> #include <mach/db5500-regs.h> +#define MSP_TX_RX_REG_OFFSET 0 + #ifndef __ASSEMBLY__ #include <mach/id.h> -- 1.7.8.3

2 1

[alsa-devel] [PATCH 1/3] ARM: ux500: Add placeholder for clk_set_parent
by Ola Lilja 01 Feb '12

01 Feb '12

Calling clk_set_parent (e.g. from Ux500 ASoC-driver) generates build-errors. Signed-off-by: Ola Lilja <ola.o.lilja(a)stericsson.com> --- arch/arm/mach-ux500/clock.c | 7 +++++++ arch/arm/mach-ux500/clock.h | 1 + 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-ux500/clock.c b/arch/arm/mach-ux500/clock.c index 7379075..ec35f0a 100644 --- a/arch/arm/mach-ux500/clock.c +++ b/arch/arm/mach-ux500/clock.c @@ -223,6 +223,13 @@ int clk_set_rate(struct clk *clk, unsigned long rate) } EXPORT_SYMBOL(clk_set_rate); +int clk_set_parent(struct clk *clk, struct clk *parent) +{ + /*TODO*/ + return -ENOSYS; +} +EXPORT_SYMBOL(clk_set_parent); + static void clk_prcmu_enable(struct clk *clk) { void __iomem *cg_set_reg = __io_address(U8500_PRCMU_BASE) diff --git a/arch/arm/mach-ux500/clock.h b/arch/arm/mach-ux500/clock.h index 0744907..d776ada 100644 --- a/arch/arm/mach-ux500/clock.h +++ b/arch/arm/mach-ux500/clock.h @@ -21,6 +21,7 @@ struct clkops { void (*enable) (struct clk *); void (*disable) (struct clk *); unsigned long (*get_rate) (struct clk *); + int (*set_parent)(struct clk *, struct clk *); }; /** -- 1.7.8.3

2 1

[alsa-devel] [PATCH] ALSA: HDA: Remove unconnected PCM devices for Intel HDMI
by David Henningsson 01 Feb '12

01 Feb '12

Since I'm a little new in HDMI land and the patch is non-trivial, I wouldn't mind some comments on this one. Also thanks to Jaroslav who cleared a few things out about the logical and physical devices which helped me figure out what I should do about it :-) Anyway, here's the patch. Some newer chips have more than one HDMI output, but usually not all of them are exposed as physical jacks. Removing the unused PCM devices (as indicated by BIOS in the pin config default) will reduce user confusion as they currently have to choose between several HDMI devices, some of them not working anyway. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

4 14

[alsa-devel] [RFC][PATCH] ASoC: cs42l73: Fix Output [X|A|V]SP_SCLK Sourcing Mode setting for master mode
by Axel Lin 01 Feb '12

01 Feb '12

For master mode, set Output [X|A|V]SP_SCLK Sourcing Mode to MCLK Mode. Signed-off-by: Axel Lin <axel.lin(a)gmail.com> --- Hi Brian, I think current code of setting priv->config[id].spc for master mode is wrong: priv->config[id].spc &= MCK_SCLK_64FS; will set priv->config[id].spc to be 0. I don't have this hardware, I'd appreciate you can review and test this patch. Regards, Axel sound/soc/codecs/cs42l73.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/cs42l73.c b/sound/soc/codecs/cs42l73.c index 9d38db8..78979b3 100644 --- a/sound/soc/codecs/cs42l73.c +++ b/sound/soc/codecs/cs42l73.c @@ -1113,7 +1113,7 @@ static int cs42l73_pcm_hw_params(struct snd_pcm_substream *substream, priv->config[id].mmcc &= 0xC0; priv->config[id].mmcc |= cs42l73_mclk_coeffs[mclk_coeff].mmcc; priv->config[id].spc &= 0xFC; - priv->config[id].spc &= MCK_SCLK_64FS; + priv->config[id].spc |= MCK_SCLK_MCLK; } else { /* CS42L73 Slave */ priv->config[id].spc &= 0xFC; -- 1.7.5.4

3 2

Re: [alsa-devel] soc-dsp programming model for loopbacks
by Liam Girdwood 01 Feb '12

01 Feb '12

On Tue, 2012-01-24 at 13:36 -0800, Pierre-Louis Bossart wrote: > Hi, > I've been doing some work on audio loopback (FM radio, BT, Modem -> audio > codec), and I am somewhat confused by the soc-dsp programming model. Let me > take the FM radio example: > > If the FM radio is directly connected to the audio codec, my understanding > is that changing the routing with codec controls will trigger the DAPM > logic, which will turn on everything that needs to be on. Very simple, no > matter if the FM-codec link is analog or digital. > Yep, this is correct. soc-dsp (now know as Dynamic PCM) takes care of any digital links that require the host CPU to perform any PCM or DAI operations (based again on DAPM graph status). i.e. on OMAP we can start the McBSP to FM Digital DAI based on the DAPM graph status and then configure the link format, speed etc to optimal values for the ABE and FM. It's not required for the analog path as DAPM will switch on the correct components for FM analog to be played on the CODEC Speaker output. > Now if the FM radio routing is handled with a digital loopback on the > application processor audio dsp (omap-abe, Intel SST, etc), then soc-dsp > will need to be used. And for a simple FM playback, I need to > 1. configure the audio codec routing for output selection > 2. open a virtual front-end for FM capture > 3. configure the DSP routing to link capture front-end to I2S1 backend (FM > interface) > 4. open a virtual front-end for FM playback > 5. configure the DSP routing to link playback front-end to I2S2 backend > (codec interface) > Using Dynamic PCM here really depends on your hardware capabilities. On OMAP, the host CPU configures and manages all DAIs so Dynamic PCM manages the DAI and PCM operations. We also have the need to re-write the hw_params and DAI formats between the FEs and BEs for optimum performance. > That seems complicated. To some extent, having the ability to have two > back-ends connected together would make more sense, and would simplify the > programming model a great deal. User-space code would be similar for > loopbacks internal to the codecs or handled on the application processor. > This would apply to Bluetooth and modem connections as well. Without this > capability, we will end-up with multiple 'virtual' front-ends (6 in my > case), making user-space code quite complex. It's not really that much extra code, it's really just open(), hw_params() and pcm_start() on the FE. Steps 1,3 & 5 are compulsory anyway for any audio device, but we need to configure format, rate, DAI clocking for the loopback. Having the FE PCM gives us this capability, although we dont transfer any data to or from the host with the FE so it's use is only for configuration. We could eventually remove steps 2 and 4 for the FE DAI link, and look at hard coding the hw_params() in the mach driver for the loopback link. That way the only user space driven actions would be to configure the mixers in the CODEC and DSP for the correct route. DAPM would then detect the path and Dynamic PCM would use the hard coded configuration or bespoke mach driver logic to configure the loopback DAI link based on use case. This would have to be done after the basic Dynamic PCM infrastructure was upstream though (unless you have a patch atm). > Looking at the current soc-dsp code, I saw that each back-end is supposed to > have at least one front-end client, and the impact of my proposal seems > fairly important. Before I start looking further into code changes, I wanted > to see if my understanding is correct and if there are other ideas to > simplify loopbacks. Atm with the current code base we can support routing many FE PCMs to many BE PCMs. We can support the BE loopback, but this does require the FE to be opened atm in order to configure the DAI link. Regards Liam

4 5

[alsa-devel] [PATCH] ALSA: hda - Fix calling cs_automic twice for Cirrus codecs.
by Dylan Reid 01 Feb '12

01 Feb '12

If cs_automic is called twice (like it is during init) while the mic is present, it will over-write the last_input with the new one, causing it to switch back to the automic input when the mic is unplugged. This leaves the driver in a state (cur_input, last_input, and automix_idx the same) where the internal mic can not be selected until it is rebooted without the mic attached. Check that the mic hasn't already been switched to before setting last_input. Signed-off-by: Dylan Reid <dgreid(a)chromium.org> --- sound/pci/hda/patch_cirrus.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c index 0e99357..bc5a993 100644 --- a/sound/pci/hda/patch_cirrus.c +++ b/sound/pci/hda/patch_cirrus.c @@ -988,8 +988,10 @@ static void cs_automic(struct hda_codec *codec) change_cur_input(codec, !spec->automic_idx, 0); } else { if (present) { - spec->last_input = spec->cur_input; - spec->cur_input = spec->automic_idx; + if (spec->cur_input != spec->automic_idx) { + spec->last_input = spec->cur_input; + spec->cur_input = spec->automic_idx; + } } else { spec->cur_input = spec->last_input; } -- 1.7.9.rc0

2 1

[alsa-devel] [PATCH] ALSA: HDA: Fix jack creation for codecs with front and rear Line In
by David Henningsson 01 Feb '12

01 Feb '12

If a codec has both a front and a rear Line In, two controls both named "Line Jack" will be created, which causes parsing to fail. While a long term solution might be to name the jacks differently, this extra check is consistent with what is already being done in many auto-parsers, and will also protect against other cases when two inputs have the same label. BugLink: https://bugs.launchpad.net/bugs/923409 Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/hda_jack.c | 24 +++++++++++++++--------- 1 files changed, 15 insertions(+), 9 deletions(-) diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c index d8a35da..9d819c4 100644 --- a/sound/pci/hda/hda_jack.c +++ b/sound/pci/hda/hda_jack.c @@ -282,7 +282,8 @@ int snd_hda_jack_add_kctl(struct hda_codec *codec, hda_nid_t nid, EXPORT_SYMBOL_HDA(snd_hda_jack_add_kctl); static int add_jack_kctl(struct hda_codec *codec, hda_nid_t nid, - const struct auto_pin_cfg *cfg) + const struct auto_pin_cfg *cfg, + char *lastname, int *lastidx) { unsigned int def_conf, conn; char name[44]; @@ -298,6 +299,10 @@ static int add_jack_kctl(struct hda_codec *codec, hda_nid_t nid, return 0; snd_hda_get_pin_label(codec, nid, cfg, name, sizeof(name), &idx); + if (!strcmp(name, lastname) && idx == *lastidx) + idx++; + strncpy(lastname, name, 44); + *lastidx = idx; err = snd_hda_jack_add_kctl(codec, nid, name, idx); if (err < 0) return err; @@ -311,41 +316,42 @@ int snd_hda_jack_add_kctls(struct hda_codec *codec, const struct auto_pin_cfg *cfg) { const hda_nid_t *p; - int i, err; + int i, err, lastidx = 0; + char lastname[44] = ""; for (i = 0, p = cfg->line_out_pins; i < cfg->line_outs; i++, p++) { - err = add_jack_kctl(codec, *p, cfg); + err = add_jack_kctl(codec, *p, cfg, lastname, &lastidx); if (err < 0) return err; } for (i = 0, p = cfg->hp_pins; i < cfg->hp_outs; i++, p++) { if (*p == *cfg->line_out_pins) /* might be duplicated */ break; - err = add_jack_kctl(codec, *p, cfg); + err = add_jack_kctl(codec, *p, cfg, lastname, &lastidx); if (err < 0) return err; } for (i = 0, p = cfg->speaker_pins; i < cfg->speaker_outs; i++, p++) { if (*p == *cfg->line_out_pins) /* might be duplicated */ break; - err = add_jack_kctl(codec, *p, cfg); + err = add_jack_kctl(codec, *p, cfg, lastname, &lastidx); if (err < 0) return err; } for (i = 0; i < cfg->num_inputs; i++) { - err = add_jack_kctl(codec, cfg->inputs[i].pin, cfg); + err = add_jack_kctl(codec, cfg->inputs[i].pin, cfg, lastname, &lastidx); if (err < 0) return err; } for (i = 0, p = cfg->dig_out_pins; i < cfg->dig_outs; i++, p++) { - err = add_jack_kctl(codec, *p, cfg); + err = add_jack_kctl(codec, *p, cfg, lastname, &lastidx); if (err < 0) return err; } - err = add_jack_kctl(codec, cfg->dig_in_pin, cfg); + err = add_jack_kctl(codec, cfg->dig_in_pin, cfg, lastname, &lastidx); if (err < 0) return err; - err = add_jack_kctl(codec, cfg->mono_out_pin, cfg); + err = add_jack_kctl(codec, cfg->mono_out_pin, cfg, lastname, &lastidx); if (err < 0) return err; return 0; -- 1.7.8.3

3 8