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

[alsa-devel] bug report: using snd_BUG_ON() instead of WARN_ON()
by Dan Carpenter 19 Feb '10

19 Feb '10

Smatch found a couple places try use the return value for snd_BUG_ON() without realizing it's always zero or that it can be defined away entirely under certain configs. sound/core/info_oss.c 46 if (snd_BUG_ON(dev < 0 || dev >= SNDRV_OSS_INFO_DEV_COUNT)) 47 return -ENXIO; 48 if (snd_BUG_ON(num < 0 || num >= SNDRV_CARDS)) 49 return -ENXIO; sound/drivers/opl3/opl3_midi.c +652 snd_opl3_kill_voice(34) warn: buffer overflow 'opl3->voices' 18 <= 20 opl3_midi.c checks the range with snd_BUG_ON() and then adds 3 so it possibly goes out of bounds. I'm not sure the situation there. sound/core/seq/seq_midi.c +403 snd_seq_midisynth_register_port(126) error: buffer overflow 'client->ports_per_device' 8 <= 8 sound/core/seq/seq_midi.c +404 snd_seq_midisynth_register_port(127) error: buffer overflow 'client->ports' 8 <= 8 sound/core/info_oss.c +52 snd_oss_info_register(10) error: buffer overflow 'snd_sndstat_strings[num]' 6 <= 6 sound/core/info_oss.c +52 snd_oss_info_register(10) error: buffer overflow 'snd_sndstat_strings' 32 <= 32 sound/core/info_oss.c +63 snd_oss_info_register(21) error: buffer overflow 'snd_sndstat_strings[num]' 6 <= 6 sound/core/info_oss.c +63 snd_oss_info_register(21) error: buffer overflow 'snd_sndstat_strings' 32 <= 32 sound/pci/cs46xx/dsp_spos_scb_lib.c +1497 cs46xx_dsp_destroy_pcm_channel(28) error: buffer overflow 'ins->src_scb_slots' 14 <= 14 regards, dan carpenter

2 2

Re: [alsa-devel] [patch] oxygen: clean up. make precedence explicit
by Dan Carpenter 19 Feb '10

19 Feb '10

On Fri, Feb 19, 2010 at 11:33:30AM +0100, Bernd Petrovitsch wrote: > On Fre, 2010-02-19 at 13:10 +0300, Dan Carpenter wrote: > > On Fri, Feb 19, 2010 at 09:29:05AM +0100, Clemens Ladisch wrote: > > > > This doesn't change anything, but I think it makes the code clearer. > > > > It silences a smatch warning: > > > > sound/pci/oxygen/oxygen_mixer.c +91 dac_mute_put(7) warn: add some parenthesis here? > > > > > > That message doesn't say why some parentheses should be added. > > > And it's a question; how do I give it the answer "no"? :-) > > > > > > > - changed = !value->value.integer.value[0] != chip->dac_mute; > > > > + changed = (!value->value.integer.value[0]) != chip->dac_mute; > > > > > > This doesn't look any clearer to me; I don't think that the unary > > > negation operator could be thought to have lower precedence than "!=". > > > > Well, it's hard to argue that it's more ambiguous. :P > But it doesn't make the code clearer - unless you are a C novice. Unary > operators generally bind stronger than others - be it "+", "-", "!", > "~", "*". > I would expect kernel programmers to know that (and I don't assume > in-depth knowledge of operator precedence rules). > > > > Why does smatch warn about this combination? Do such errors actually > > > happen: > > > > Yep. I have made some myself when writing smatch. > > > > For example here are some related bugs in the current kernel. > > > > drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c > > 721 if (!ext->ext_flags & IW_ENCODE_EXT_GROUP_KEY && > Well, I see potential bugs here and the if() should have been > a) if (!(ext->ext_flags & IW_ENCODE_EXT_GROUP_KEY) && Yep. This is clearly what the code should say. The problem in the original code is that IW_ENCODE_EXT_GROUP_KEY is not equal to either 1 or to 0. (So that means the condition in the original code is always false). > b) if (!ext->ext_flags && IW_ENCODE_EXT_GROUP_KEY && > So you one has to look at the driver for the correct fix (and perhaps > both of above are wrong). > > And I don't see what parenthesis around a logical negations can help > with the above error example. > Basically often when people write: if (!foo == bar) { ... What they mean is: if (!(foo == bar)) { ... But if they really do mean the original code they could just write this so it's clear to everyone: if ((!foo) == bar) { ... To me it's like "==" vs "=". Of course, every programmer knows the what the difference is but it helps to have gcc warn about adding the extra parenthesis. Maybe I suck, but it definitely has helped me in then past. I don't have strong feelings about this btw. The original code in oxygyn_mixer works fine. I just was making some changes to smatch and that was a new warning today. There is no method to my madness. regards, dan carpenter > Bernd > -- > Bernd Petrovitsch Email : bernd(a)petrovitsch.priv.at > LUGA : http://www.luga.at

1 1

[alsa-devel] alsamixer crashes with SIGFPE
by Florian Faber 19 Feb '10

19 Feb '10

Hi, there are several spots in alsamixer's mixer_display.c that cause SIGFPE through division by zero if (max-min) is zero: bar_height = ((volumes[c] - min) * volume_height + max - min - 1) / (max - min); value = ((volumes[0] - min) * 100 + (max - min) / 2) / (max - min); etc. Flo -- Machines can do the work, so people have time to think. public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net

2 3

[alsa-devel] [PATCH v3 1/3] ASoC: OMAP: data_type and sync_mode configurable in audio dma
by Candelaria Villareal, Jorge 19 Feb '10

19 Feb '10

From: Misael Lopez Cruz <x0052729(a)ti.com> Allow client drivers to set the data_type (16, 32) and the sync_mode (element, packet, etc) of the audio dma transferences. McBSP dai driver configures it for a data type of 16 bits and element sync mode. Signed-off-by: Misael Lopez Cruz <x0052729(a)ti.com> Signed-off-by: Jorge Eduardo Candelaria <jorge.candelaria(a)ti.com> --- sound/soc/omap/omap-mcbsp.c | 2 ++ sound/soc/omap/omap-pcm.c | 15 ++++++++------- sound/soc/omap/omap-pcm.h | 4 +++- 3 files changed, 13 insertions(+), 8 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 6bbbd2a..d297256 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -287,6 +287,8 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, omap_mcbsp_dai_dma_params[id][substream->stream].dma_req = dma; omap_mcbsp_dai_dma_params[id][substream->stream].port_addr = port; omap_mcbsp_dai_dma_params[id][substream->stream].sync_mode = sync_mode; + omap_mcbsp_dai_dma_params[id][substream->stream].data_type = + OMAP_DMA_DATA_TYPE_S16; cpu_dai->dma_data = &omap_mcbsp_dai_dma_params[id][substream->stream]; if (mcbsp_data->configured) { diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index 9db2770..825db38 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -37,7 +37,8 @@ static const struct snd_pcm_hardware omap_pcm_hardware = { SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME, - .formats = SNDRV_PCM_FMTBIT_S16_LE, + .formats = SNDRV_PCM_FMTBIT_S16_LE | + SNDRV_PCM_FMTBIT_S32_LE, .period_bytes_min = 32, .period_bytes_max = 64 * 1024, .periods_min = 2, @@ -149,6 +150,7 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) struct omap_runtime_data *prtd = runtime->private_data; struct omap_pcm_dma_data *dma_data = prtd->dma_data; struct omap_dma_channel_params dma_params; + int bytes; /* return if this is a bufferless transfer e.g. * codec <--> BT codec or GSM modem -- lg FIXME */ @@ -156,11 +158,7 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) return 0; memset(&dma_params, 0, sizeof(dma_params)); - /* - * Note: Regardless of interface data formats supported by OMAP McBSP - * or EAC blocks, internal representation is always fixed 16-bit/sample - */ - dma_params.data_type = OMAP_DMA_DATA_TYPE_S16; + dma_params.data_type = dma_data->data_type; dma_params.trigger = dma_data->dma_req; dma_params.sync_mode = dma_data->sync_mode; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { @@ -170,6 +168,7 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) dma_params.src_start = runtime->dma_addr; dma_params.dst_start = dma_data->port_addr; dma_params.dst_port = OMAP_DMA_PORT_MPUI; + dma_params.dst_fi = dma_data->packet_size; } else { dma_params.src_amode = OMAP_DMA_AMODE_CONSTANT; dma_params.dst_amode = OMAP_DMA_AMODE_POST_INC; @@ -177,6 +176,7 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) dma_params.src_start = dma_data->port_addr; dma_params.dst_start = runtime->dma_addr; dma_params.src_port = OMAP_DMA_PORT_MPUI; + dma_params.src_fi = dma_data->packet_size; } /* * Set DMA transfer frame size equal to ALSA period size and frame @@ -184,7 +184,8 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) * we can transfer the whole ALSA buffer with single DMA transfer but * still can get an interrupt at each period bounary */ - dma_params.elem_count = snd_pcm_lib_period_bytes(substream) / 2; + bytes = snd_pcm_lib_period_bytes(substream); + dma_params.elem_count = bytes >> dma_data->data_type; dma_params.frame_count = runtime->periods; omap_set_dma_params(prtd->dma_ch, &dma_params); diff --git a/sound/soc/omap/omap-pcm.h b/sound/soc/omap/omap-pcm.h index 38a821d..b19975d 100644 --- a/sound/soc/omap/omap-pcm.h +++ b/sound/soc/omap/omap-pcm.h @@ -29,8 +29,10 @@ struct omap_pcm_dma_data { char *name; /* stream identifier */ int dma_req; /* DMA request line */ unsigned long port_addr; /* transmit/receive register */ - int sync_mode; /* DMA sync mode */ void (*set_threshold)(struct snd_pcm_substream *substream); + int data_type; /* data type 8,16,32 */ + int sync_mode; /* DMA sync mode */ + int packet_size; /* packet size only in PACKET mode */ }; extern struct snd_soc_platform omap_soc_platform; -- 1.6.0.4

3 3

[alsa-devel] Since kernel-2.6.32, alsactl fails to restore defaults
by Pacho Ramos 19 Feb '10

19 Feb '10

I originally reported this issue downstream to: http://bugs.gentoo.org/show_bug.cgi?id=299362 Later to kernel: http://bugzilla.kernel.org/show_bug.cgi?id=15107 And they told me that this is an alsactl issue, since it's not exiting with 0 when it notices that the device doesn't need special quirks: # alsactl -f /var/lib/alsa/asound.state restore Unknown hardware: "VIA8237" "Realtek ALC658D" "AC97a:414c4781" "0x147b" "0x1415" Hardware is initialized using a guess method # echo $? 157 What could I do? Thanks for helping me, if you need more information, simply ask me for it :-)

2 5

[alsa-devel] [PATCH v3 3/3] ASoC: OMAP4: Add McPDM platform driver
by Candelaria Villareal, Jorge 19 Feb '10

19 Feb '10

From: Misael Lopez Cruz <x0052729(a)ti.com> McPDM platform driver is configured to use sDMA in order to transfer to/from memory. Support for interfacing with ABE will be added later. McPDM dai currently supports up to 4 downlink channels and 2 uplink channels simultaneously, as well as 88.2 and 96 KHz, and a sample size of 32 bits. Signed-off-by: Misael Lopez Cruz <x0052729(a)ti.com> Signed-off-by: Margarita Olaya <x0080101(a)ti.com> Signed-off-by: Jorge Eduardo Candelaria <jorge.candelaria(a)ti.com> --- sound/soc/omap/Makefile | 2 +- sound/soc/omap/omap-mcpdm.c | 251 +++++++++++++++++++++++++++++++++++++++++++ sound/soc/omap/omap-mcpdm.h | 29 +++++ 3 files changed, 281 insertions(+), 1 deletions(-) create mode 100644 sound/soc/omap/omap-mcpdm.c create mode 100644 sound/soc/omap/omap-mcpdm.h diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index bf8b388..d6382fa 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -1,7 +1,7 @@ # OMAP Platform Support snd-soc-omap-objs := omap-pcm.o snd-soc-omap-mcbsp-objs := omap-mcbsp.o -snd-soc-omap-mcpdm-objs := mcpdm.o +snd-soc-omap-mcpdm-objs := mcpdm.o omap-mcpdm.o obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c new file mode 100644 index 0000000..25f19e4 --- /dev/null +++ b/sound/soc/omap/omap-mcpdm.c @@ -0,0 +1,251 @@ +/* + * omap-mcpdm.c -- OMAP ALSA SoC DAI driver using McPDM port + * + * Copyright (C) 2009 Texas Instruments + * + * Author: Misael Lopez Cruz <x0052729(a)ti.com> + * Contact: Jorge Eduardo Candelaria <x0107209(a)ti.com> + * Margarita Olaya <magi.olaya(a)ti.com> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include <linux/init.h> +#include <linux/module.h> +#include <linux/device.h> +#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/initval.h> +#include <sound/soc.h> + +#include <plat/control.h> +#include <plat/dma.h> +#include <plat/mcbsp.h> +#include "mcpdm.h" +#include "omap-mcpdm.h" +#include "omap-pcm.h" + +struct omap_mcpdm_data { + struct omap_mcpdm_link *links; + int active; +}; + +static struct omap_mcpdm_link omap_mcpdm_links[] = { + /* downlink */ + { + .irq_mask = MCPDM_DN_IRQ_EMPTY | MCPDM_DN_IRQ_FULL, + .threshold = 1, + .format = PDMOUTFORMAT_LJUST, + }, + /* uplink */ + { + .irq_mask = MCPDM_UP_IRQ_EMPTY | MCPDM_UP_IRQ_FULL, + .threshold = 1, + .format = PDMOUTFORMAT_LJUST, + }, +}; + +static struct omap_mcpdm_data mcpdm_data = { + .links = omap_mcpdm_links, + .active = 0, +}; + +/* + * Stream DMA parameters + */ +static struct omap_pcm_dma_data omap_mcpdm_dai_dma_params[] = { + { + .name = "Audio playback", + .dma_req = OMAP44XX_DMA_MCPDM_DL, + .data_type = OMAP_DMA_DATA_TYPE_S32, + .sync_mode = OMAP_DMA_SYNC_PACKET, + .packet_size = 16, + .port_addr = OMAP44XX_MCPDM_L3_BASE + MCPDM_DN_DATA, + }, + { + .name = "Audio capture", + .dma_req = OMAP44XX_DMA_MCPDM_UP, + .data_type = OMAP_DMA_DATA_TYPE_S32, + .sync_mode = OMAP_DMA_SYNC_PACKET, + .packet_size = 16, + .port_addr = OMAP44XX_MCPDM_L3_BASE + MCPDM_UP_DATA, + }, +}; + +static int omap_mcpdm_dai_startup(struct snd_pcm_substream *substream, + struct snd_soc_dai *dai) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; + int err = 0; + + if (!cpu_dai->active) + err = omap_mcpdm_request(); + + return err; +} + +static void omap_mcpdm_dai_shutdown(struct snd_pcm_substream *substream, + struct snd_soc_dai *dai) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; + + if (!cpu_dai->active) + omap_mcpdm_free(); +} + +static int omap_mcpdm_dai_trigger(struct snd_pcm_substream *substream, int cmd, + struct snd_soc_dai *dai) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; + struct omap_mcpdm_data *mcpdm_priv = cpu_dai->private_data; + int stream = substream->stream; + int err = 0; + + switch (cmd) { + case SNDRV_PCM_TRIGGER_START: + case SNDRV_PCM_TRIGGER_RESUME: + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: + if (!mcpdm_priv->active++) + omap_mcpdm_start(stream); + break; + + case SNDRV_PCM_TRIGGER_STOP: + case SNDRV_PCM_TRIGGER_SUSPEND: + case SNDRV_PCM_TRIGGER_PAUSE_PUSH: + if (!--mcpdm_priv->active) + omap_mcpdm_stop(stream); + break; + default: + err = -EINVAL; + } + + return err; +} + +static int omap_mcpdm_dai_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params, + struct snd_soc_dai *dai) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; + struct omap_mcpdm_data *mcpdm_priv = cpu_dai->private_data; + struct omap_mcpdm_link *mcpdm_links = mcpdm_priv->links; + int stream = substream->stream; + int channels, err, link_mask = 0; + + cpu_dai->dma_data = &omap_mcpdm_dai_dma_params[stream]; + + channels = params_channels(params); + switch (channels) { + case 4: + if (stream == SNDRV_PCM_STREAM_CAPTURE) + /* up to 2 channels for capture */ + return -EINVAL; + link_mask |= 1 << 3; + case 3: + if (stream == SNDRV_PCM_STREAM_CAPTURE) + /* up to 2 channels for capture */ + return -EINVAL; + link_mask |= 1 << 2; + case 2: + link_mask |= 1 << 1; + case 1: + link_mask |= 1 << 0; + break; + default: + /* unsupported number of channels */ + return -EINVAL; + } + + if (stream == SNDRV_PCM_STREAM_PLAYBACK) { + mcpdm_links[stream].channels = link_mask << 3; + err = omap_mcpdm_playback_open(&mcpdm_links[stream]); + } else { + mcpdm_links[stream].channels = link_mask << 0; + err = omap_mcpdm_capture_open(&mcpdm_links[stream]); + } + + return err; +} + +static int omap_mcpdm_dai_hw_free(struct snd_pcm_substream *substream, + struct snd_soc_dai *dai) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; + struct omap_mcpdm_data *mcpdm_priv = cpu_dai->private_data; + struct omap_mcpdm_link *mcpdm_links = mcpdm_priv->links; + int stream = substream->stream; + int err; + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + err = omap_mcpdm_playback_close(&mcpdm_links[stream]); + else + err = omap_mcpdm_capture_close(&mcpdm_links[stream]); + + return err; +} + +static struct snd_soc_dai_ops omap_mcpdm_dai_ops = { + .startup = omap_mcpdm_dai_startup, + .shutdown = omap_mcpdm_dai_shutdown, + .trigger = omap_mcpdm_dai_trigger, + .hw_params = omap_mcpdm_dai_hw_params, + .hw_free = omap_mcpdm_dai_hw_free, +}; + +#define OMAP_MCPDM_RATES (SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000) +#define OMAP_MCPDM_FORMATS (SNDRV_PCM_FMTBIT_S32_LE) + +struct snd_soc_dai omap_mcpdm_dai = { + .name = "omap-mcpdm", + .id = -1, + .playback = { + .channels_min = 1, + .channels_max = 4, + .rates = OMAP_MCPDM_RATES, + .formats = OMAP_MCPDM_FORMATS, + }, + .capture = { + .channels_min = 1, + .channels_max = 2, + .rates = OMAP_MCPDM_RATES, + .formats = OMAP_MCPDM_FORMATS, + }, + .ops = &omap_mcpdm_dai_ops, + .private_data = &mcpdm_data, +}; +EXPORT_SYMBOL_GPL(omap_mcpdm_dai); + +static int __init snd_omap_mcpdm_init(void) +{ + return snd_soc_register_dai(&omap_mcpdm_dai); +} +module_init(snd_omap_mcpdm_init); + +static void __exit snd_omap_mcpdm_exit(void) +{ + snd_soc_unregister_dai(&omap_mcpdm_dai); +} +module_exit(snd_omap_mcpdm_exit); + +MODULE_AUTHOR("Misael Lopez Cruz <x0052729(a)ti.com>"); +MODULE_DESCRIPTION("OMAP PDM SoC Interface"); +MODULE_LICENSE("GPL"); diff --git a/sound/soc/omap/omap-mcpdm.h b/sound/soc/omap/omap-mcpdm.h new file mode 100644 index 0000000..73b80d5 --- /dev/null +++ b/sound/soc/omap/omap-mcpdm.h @@ -0,0 +1,29 @@ +/* + * omap-mcpdm.h + * + * Copyright (C) 2009 Texas Instruments + * + * Contact: Misael Lopez Cruz <x0052729(a)ti.com> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#ifndef __OMAP_MCPDM_H__ +#define __OMAP_MCPDM_H__ + +extern struct snd_soc_dai omap_mcpdm_dai; + +#endif /* End of __OMAP_MCPDM_H__ */ -- 1.6.0.4

2 1

Re: [alsa-devel] [patch] oxygen: clean up. make precedence explicit
by Clemens Ladisch 19 Feb '10

19 Feb '10

> This doesn't change anything, but I think it makes the code clearer. > It silences a smatch warning: > sound/pci/oxygen/oxygen_mixer.c +91 dac_mute_put(7) warn: add some parenthesis here? That message doesn't say why some parentheses should be added. And it's a question; how do I give it the answer "no"? :-) > - changed = !value->value.integer.value[0] != chip->dac_mute; > + changed = (!value->value.integer.value[0]) != chip->dac_mute; This doesn't look any clearer to me; I don't think that the unary negation operator could be thought to have lower precedence than "!=". Why does smatch warn about this combination? Do such errors actually happen? Regards, Clemens

2 1

[alsa-devel] [patch] oxygen: clean up. make precedence explicit
by Dan Carpenter 19 Feb '10

19 Feb '10

This doesn't change anything, but I think it makes the code clearer. It silences a smatch warning: sound/pci/oxygen/oxygen_mixer.c +91 dac_mute_put(7) warn: add some parenthesis here? Signed-off-by: Dan Carpenter <error27(a)gmail.com> --- Compile tested. diff --git a/sound/pci/oxygen/oxygen_mixer.c b/sound/pci/oxygen/oxygen_mixer.c index f375b8a..28590b9 100644 --- a/sound/pci/oxygen/oxygen_mixer.c +++ b/sound/pci/oxygen/oxygen_mixer.c @@ -88,7 +88,7 @@ static int dac_mute_put(struct snd_kcontrol *ctl, int changed; mutex_lock(&chip->mutex); - changed = !value->value.integer.value[0] != chip->dac_mute; + changed = (!value->value.integer.value[0]) != chip->dac_mute; if (changed) { chip->dac_mute = !value->value.integer.value[0]; chip->model.update_dac_mute(chip);

1 0

[alsa-devel] [PATCH v3 0/3] McPDM driver patches series
by Candelaria Villareal, Jorge 19 Feb '10

19 Feb '10

McPDM module is the interface between the OMAP and TWL6030 audio codec. The interface supports the following: * Up to 5 downlink channels and 3 uplink channels * 88.2 and 96 KHz * 32 bit sample size Currently, driver is set to support up to 4 downlink channels. If 2 channels are selected, output will go to the headset, and if 4 channels are selected, output will go to the headset and speakers. Functionality to select the output at runtime will be added afterwards. Command and status mode is not supported in current patches. Changes from v2: - Functions have been renamed using playback/capture convention -- Jorge Eduardo Candelaria (1): ASoC: OMAP4: Add support for McPDM Misael Lopez Cruz (2): ASoC: OMAP: data_type and sync_mode configurable in audio dma ASoC: OMAP4: Add McPDM platform driver sound/soc/omap/Kconfig | 3 + sound/soc/omap/Makefile | 2 + sound/soc/omap/mcpdm.c | 490 +++++++++++++++++++++++++++++++++++++++++++ sound/soc/omap/mcpdm.h | 151 +++++++++++++ sound/soc/omap/omap-mcbsp.c | 2 + sound/soc/omap/omap-mcpdm.c | 251 ++++++++++++++++++++++ sound/soc/omap/omap-mcpdm.h | 29 +++ sound/soc/omap/omap-pcm.c | 15 +- sound/soc/omap/omap-pcm.h | 4 +- 9 files changed, 939 insertions(+), 8 deletions(-) create mode 100644 sound/soc/omap/mcpdm.c create mode 100644 sound/soc/omap/mcpdm.h create mode 100644 sound/soc/omap/omap-mcpdm.c create mode 100644 sound/soc/omap/omap-mcpdm.h

1 0

[alsa-devel] Troubles using the external SDK
by Hans-Kristian Arntzen 18 Feb '10

18 Feb '10

I am trying to make an alsa output plugin that streams the audio over network (something like esd, just even more simplistic) using the external SDK, however, I am having trouble implementing some things correctly it seems, and the docs weren't descriptive enough. So far, it works quite well with music playback that doesn't really care about audio blocking, etc. The main problem is audio sync and blocking with more complex applications like MPlayer. As far as I can see in the MPlayer source, to retain audio sync, it uses snd_pcm_delay() for delay, and snd_pcm_status_get_avail() to figure out how much it can write without audio blocking. This is fine, but how can snd_pcm_status_get_avail() get the data it needs from the plugins? It doesn't seem to call on any callbacks to do this. It seems so far that snd_pcm_status_get_avail() always returns buffer_size, since I seem to get working audio, but the video starts to stutter. The stuttering goes away when I force a really small maximum buffer size (we're talking 512-ish bytes), but this is really, really bad, and doesn't work too well on my netbook (performance/timing issues I guess). Is it possible to define a snd_pcm_status_get_avail() callback in the SDK in some way? Anyways. I want to know how you'd do this. The OSS driver for example doesn't even seem to define a delay() callback, which strikes me as odd. How can it know about the delay? Also, I want to know the reasoning behind the pointer() function. It seems to be called all the time. I don't know what it really does, and what good it does. Is it supposed to represent where in the buffer we are? As in, it's supposed to stay somewhere between 0 and buffer_size? If so, my experience with it doesn't make sense at all. If I return that actual value, the programs simply stop up and loop endlessly over the pointer() function. The temporary "hack" (as in probably very wrong) was to return the total amount of data that's been sent since the start. Can anyone help a frustrated programmer? :P -- Themaister

1 0