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

[alsa-devel] problems in getting rid of set_xfer_align
by Kai Vehmanen 19 Oct '09

19 Oct '09

Hello all, here's one problem that I stumbled on with the deprecated snd_pcm_sw_params_set_xfer_align() function. I'm not sure if anything needs to be done to this, but at least FYI for other app developers that might hit the same issue. In short, ecasound-2.7.0 was just released, and as one of the last commits, I dropped the call to snd_pcm_sw_params_set_xfer_align() as it has been deprecated since early 2008 in ALSA. Previously Ecasound had always set the xfer_align to 1. Anyways, right after the release I got an error report (from Pierre, cc'ed) about bad glitches in audio with the new release, and the problem now appears to be deprecation of set_xfer_align. To summarize: - app relies on xfer_align=1, and has previously set it explicitly - in kernels before 2.6.25, the xfer_align is initialized to period_size in pcm_native.c and to 1 in pcm_oss.c; but in 2.6.25 the field was removed altogether: http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=d948035a928400ae1… - similar change was done to alsa-lib 1.0.16: http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=cf15e49d8460d9b56005… Now the problematic combination is: - new application (not anymore calling set_xfer_align()) - old alsa-lib and kernel (still initializing xfer_size) - application used with an ALSA PCM that is strict about what period-sizes can be used (e.g. in the specific case we found out, ALSA PCM wouldn't accept a power-of-two period size) This is common enough that some workaround is needed in apps, an in Ecasound's case case, I'll add some ifdef-magic to 2.7.1 so that xfer_align is still set if compiled against an older alsa-lib. That should cover majority of the cases...

1 0

[alsa-devel] [PATCH v2] Fix possible codec_dai->ops NULL pointer problems
by Barry Song 19 Oct '09

19 Oct '09

From: Barry Song <barry.song(a)gmail.com> Some codec DAIs like stac9766, wm9712, wm9713, ad1980 don't register themselves then it loses to the chance to be given a null_dai_ops in snd_soc_register_dai if they have no ops. When functions like soc_pcm_open, soc_pcm_hw_params etc. access the ops field in these DAIs, panic will happen. Signed-off-by: Barry Song <21cnbao(a)gmail.com> --- sound/soc/soc-core.c | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index fa0da3c..2d190df 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -795,6 +795,9 @@ static int soc_resume(struct device *dev) #define soc_resume NULL #endif +static struct snd_soc_dai_ops null_dai_ops = { +}; + static void snd_soc_instantiate_card(struct snd_soc_card *card) { struct platform_device *pdev = container_of(card->dev, @@ -838,6 +841,11 @@ static void snd_soc_instantiate_card(struct snd_soc_card *card) ac97 = 1; } + for (i = 0; i < card->num_links; i++) { + if (!card->dai_link[i].codec_dai->ops) + card->dai_link[i].codec_dai->ops = &null_dai_ops; + } + /* If we have AC97 in the system then don't wait for the * codec. This will need revisiting if we have to handle * systems with mixed AC97 and non-AC97 parts. Only check for @@ -2332,9 +2340,6 @@ static int snd_soc_unregister_card(struct snd_soc_card *card) return 0; } -static struct snd_soc_dai_ops null_dai_ops = { -}; - /** * snd_soc_register_dai - Register a DAI with the ASoC core * -- 1.5.6.3

2 2

[alsa-devel] [PATCH 1/2] ASoC: au1x: psc-ac97: verify correct codec register was read
by Manuel Lauss 19 Oct '09

19 Oct '09

Verify that the correct register has been received from the codec. Signed-off-by: Manuel Lauss <manuel.lauss(a)gmail.com> --- sound/soc/au1x/psc-ac97.c | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/sound/soc/au1x/psc-ac97.c b/sound/soc/au1x/psc-ac97.c index a521aa9..efe2afd 100644 --- a/sound/soc/au1x/psc-ac97.c +++ b/sound/soc/au1x/psc-ac97.c @@ -61,7 +61,8 @@ static unsigned short au1xpsc_ac97_read(struct snd_ac97 *ac97, { /* FIXME */ struct au1xpsc_audio_data *pscdata = au1xpsc_ac97_workdata; - unsigned short data, retry, tmo; + unsigned short retry, tmo; + unsigned long data; au_writel(PSC_AC97EVNT_CD, AC97_EVNT(pscdata)); au_sync(); @@ -79,15 +80,19 @@ static unsigned short au1xpsc_ac97_read(struct snd_ac97 *ac97, && --tmo) udelay(2); - data = au_readl(AC97_CDC(pscdata)) & 0xffff; + data = au_readl(AC97_CDC(pscdata)); au_writel(PSC_AC97EVNT_CD, AC97_EVNT(pscdata)); au_sync(); mutex_unlock(&pscdata->lock); + + if (reg != ((data >> 16) & 0x7f)) + tmo = 1; /* wrong register, try again */ + } while (--retry && !tmo); - return retry ? data : 0xffff; + return retry ? data & 0xffff : 0xffff; } /* AC97 controller writes to codec register */ -- 1.6.5

2 2

[alsa-devel] [PATCH 1/14] sound/soc: Move dereference after NULL test
by Julia Lawall 19 Oct '09

19 Oct '09

From: Julia Lawall <julia(a)diku.dk> If the NULL test on jack is needed, then the derefernce should be after the NULL test. A simplified version of the semantic match that detects this problem is as follows (http://coccinelle.lip6.fr/): // <smpl> @match exists@ expression x, E; identifier fld; @@ * x->fld ... when != \(x = E\|&x\) * x == NULL // </smpl> Signed-off-by: Julia Lawall <julia(a)diku.dk> --- sound/soc/soc-jack.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c index 1d455ab..1212414 100644 --- a/sound/soc/soc-jack.c +++ b/sound/soc/soc-jack.c @@ -58,7 +58,7 @@ EXPORT_SYMBOL_GPL(snd_soc_jack_new); */ void snd_soc_jack_report(struct snd_soc_jack *jack, int status, int mask) { - struct snd_soc_codec *codec = jack->card->codec; + struct snd_soc_codec *codec; struct snd_soc_jack_pin *pin; int enable; int oldstatus; @@ -67,6 +67,7 @@ void snd_soc_jack_report(struct snd_soc_jack *jack, int status, int mask) WARN_ON_ONCE(!jack); return; } + codec = jack->card->codec; mutex_lock(&codec->mutex);

2 1

[alsa-devel] [PATCH 0/8] RX-51 audio drivers
by Eduardo Valentin 19 Oct '09

19 Oct '09

Hello everyone, Here is a patch series with most of audio support for RX51. Basically it includes asoc machine driver for rx51, tpa6130a2 amplifier driver (asoc version), board file configuration and setup and the sidetone feature of mcbsp. On top of that, there are few patches to use regulator framework to control vmmc2. This series is based on linux-omap. So basically after applying it, you can boot the device and have sound support. Even though this patches were tested using linux-omap, the series is applicable on top of sound-2.6 tree as well. Please review. And as usual, comments are welcome. BR, --- Eduardo Valentin Eduardo Valentin (6): ASoC: OMAP: RX-51 Machine driver and AIC34b_dummy driver OMAP: RX51: Add audio board file board-rx51-peripherals: split vaux3 and vmmc2 supplies RX-51: Audio: Add usage of regulator framework to control VMMC2 ASoC: tlv320aic3x: add initial usage of regulator framework to control avdd_dac ASoC: tpa6130a2: Control vdd using regulator framework Eero Nurkkala (1): McBSP: OMAP3: Add Sidetone feature Peter Ujfalusi (1): ASoC: TPA6130A2 amplifier driver arch/arm/mach-omap2/Makefile | 1 + arch/arm/mach-omap2/board-rx51-audio.c | 132 +++++ arch/arm/mach-omap2/board-rx51-peripherals.c | 22 +- arch/arm/mach-omap2/mcbsp.c | 2 + arch/arm/plat-omap/include/mach/mcbsp.h | 43 ++ arch/arm/plat-omap/mcbsp.c | 379 ++++++++++++- include/sound/tpa6130a2-plat.h | 30 + sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tlv320aic3x.c | 26 + sound/soc/codecs/tpa6130a2.c | 396 +++++++++++++ sound/soc/codecs/tpa6130a2.h | 62 ++ sound/soc/omap/Kconfig | 10 + sound/soc/omap/Makefile | 2 + sound/soc/omap/aic34b_dummy.c | 271 +++++++++ sound/soc/omap/aic34b_dummy.h | 32 + sound/soc/omap/rx51.c | 793 ++++++++++++++++++++++++++ sound/soc/omap/rx51.h | 29 + 18 files changed, 2225 insertions(+), 11 deletions(-) create mode 100644 arch/arm/mach-omap2/board-rx51-audio.c create mode 100644 include/sound/tpa6130a2-plat.h create mode 100644 sound/soc/codecs/tpa6130a2.c create mode 100644 sound/soc/codecs/tpa6130a2.h create mode 100644 sound/soc/omap/aic34b_dummy.c create mode 100644 sound/soc/omap/aic34b_dummy.h create mode 100644 sound/soc/omap/rx51.c create mode 100644 sound/soc/omap/rx51.h -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

7 57

[alsa-devel] Problems with newest alsa driver on 2.6.30 kernel - unknown symbols
by Christian Steffen 19 Oct '09

19 Oct '09

Hi there, while an older version of alsa drivers is working fine with my kernel 2.6.30, the newly compiled modules can't be inserted properly. I compiled snd-had-intel modules for my kernel 2.6.30 and tried to insert/start them. dmesg returns me: [ 106.209451] snd_hda_codec: Unknown symbol __snd_printk [ 106.210340] snd_hda_codec: Unknown symbol snd_hwdep_new [ 106.212211] snd_hda_codec: disagrees about version of symbol snd_pcm_hw_constraint_step [ 106.212217] snd_hda_codec: Unknown symbol snd_pcm_hw_constraint_step Any idea? Thanks, Christian

3 3

[alsa-devel] Questions on locking, snd-usb-caiaq
by Mark Hills 18 Oct '09

18 Oct '09

I fixed some race issues in snd-usb-caiaq, but have some questions on the interface between the driver and ALSA. First fix is a lock in pointer(), which caused snd_pcm_update_hw_ptr_pos() to report an out of range buffer position (even though it was sucessfully corrected to zero). Second is a lock as part of trigger(). On testing, this appears to fix an issue where white noise could sometimes be transferred by the driver. According to the documentation, trigger() and pointer() are called with local interrupts disabled. This means they should really be non-irqsave locks? (http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch05s08.html) Even for callbacks documented as atomic, if read_completed() and write_completed() can be called at any time interrupts are enabled (eg. on another CPU) it seems that additional locking my be required. Candidates are: snd_usb_caiaq_substream_open snd_usb_caiaq_substream_close snd_usb_caiaq_pcm_hw_free snd_usb_caiaq_pcm_prepare Are there any guarantees on these functions which mean the lock is not required? To lock in prepare() would (I think) require demoting a spin_lock_irqsave() to a spin_lock() to send initialisation commands. If so, what is the best design for this? Thanks, -- Mark diff --git a/sound/usb/caiaq/audio.c b/sound/usb/caiaq/audio.c index 121af06..c659f81 100644 --- a/sound/usb/caiaq/audio.c +++ b/sound/usb/caiaq/audio.c @@ -62,10 +62,15 @@ static void activate_substream(struct snd_usb_caiaqdev *dev, struct snd_pcm_substream *sub) { + unsigned long flags; + spin_lock_irqsave(&dev->spinlock, flags); + if (sub->stream == SNDRV_PCM_STREAM_PLAYBACK) dev->sub_playback[sub->number] = sub; else dev->sub_capture[sub->number] = sub; + + spin_unlock_irqrestore(&dev->spinlock, flags); } static void @@ -269,16 +274,23 @@ snd_usb_caiaq_pcm_pointer(struct snd_pcm_substream *sub) { int index = sub->number; struct snd_usb_caiaqdev *dev = snd_pcm_substream_chip(sub); + unsigned long flags; + snd_pcm_uframes_t ptr; + + spin_lock_irqsave(&dev->spinlock, flags); if (dev->input_panic || dev->output_panic) - return SNDRV_PCM_POS_XRUN; + ptr = SNDRV_PCM_POS_XRUN; if (sub->stream == SNDRV_PCM_STREAM_PLAYBACK) - return bytes_to_frames(sub->runtime, + ptr = bytes_to_frames(sub->runtime, dev->audio_out_buf_pos[index]); else - return bytes_to_frames(sub->runtime, + ptr = bytes_to_frames(sub->runtime, dev->audio_in_buf_pos[index]); + + spin_unlock_irqrestore(&dev->spinlock, flags); + return ptr; } /* operators for both playback and capture */

3 12

[alsa-devel] How to close ALSA device nodes?
by Rémi Denis-Courmont 18 Oct '09

18 Oct '09

Hello, I'm getting a bug report against VLC media player whereby ALSA sound output stops working when the screensaver is inhibited. It turns out that VLC is leaking any file descriptor open through ALSA-lib into child processes. The exact same issue was already raised by mplayer... 6 years ago: http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg06249.html In other cases (V4L, OSS, DVB, DVD, sockets, even regular files...), VLC would open the device nodes with O_CLOEXEC flag (if supported by kernel and libc) and fallback to setting FD_CLOEXEC via fcntl(). Then the descriptor is automatically, and in the earlier case, thread-safely, closed whenever VLC - forks and- execs. With ALSA-lib, I cannot figure any way to achieve that... From the earlier thread, I reckon that ALSA developers consider that this is an upper-layer issue. Maybe so, but then how is the upper-layer supposed to find which file descriptors ALSA-lib has opened - if any? Conversely, if ALSA- lib won't tell while file descriptors it is using, what could possibly be the use case for not closing those on exec? Best regards, -- Rémi Denis-Courmont http://www.remlab.net/

2 1

[alsa-devel] alsa-driver compile error (1.0.21 and latest snapshot)
by Stephen Stocker 18 Oct '09

18 Oct '09

Hi, Using Slackware and gcc 3.3.6, I'm getting the following error compiling the alsa-driver for intel8x0. This is on a 2.4.24-ck1 kernel, if that helps. make[1]: Entering directory `/home/lpar/alsa-driver-1.0.21.1.g098ab.13.g15db1/pc i' gcc -D__KERNEL__ -DMODULE=1 -I/home/lpar/alsa-driver-1.0.21.1.g098ab.13.g15db1/i nclude -I/usr/src/linux-2.4.24-ck1/include -O2 -mpreferred-stack-boundary=2 -ma rch=i586 -DLINUX -Wall -Wstrict-prototypes -fomit-frame-pointer -Wno-trigraphs - O2 -fno-strict-aliasing -fno-common -pipe -DALSA_BUILD -nostdinc -iwithprefix in clude -DMODVERSIONS -include /usr/src/linux-2.4.24-ck1/include/linux/modversions .h -DKBUILD_BASENAME=intel8x0 -c -o intel8x0.o intel8x0.c In file included from intel8x0.c:39: /home/lpar/alsa-driver-1.0.21.1.g098ab.13.g15db1/include/sound/ac97_codec.h: In function `snd_ac97_dev_add_pdata': /home/lpar/alsa-driver-1.0.21.1.g098ab.13.g15db1/include/sound/ac97_codec.h:651: error: structure has no member named `platform_data' intel8x0.c: At top level: pci_iomap_compat.c:62: warning: `ioport_unmap' defined but not used intel8x0.c:103: warning: `enable' defined but not used intel8x0.c:105: warning: `joystick' defined but not used make[1]: *** [intel8x0.o] Error 1 make[1]: Leaving directory `/home/lpar/alsa-driver-1.0.21.1.g098ab.13.g15db1/pci ' make: *** [compile] Error 1 Thanks in advance for any help you can offer. :) Steve -- Hope, Despair and the Triumph of Life http://www.hdtl.org Abuse Prevention/Survivor Support

1 0

[alsa-devel] [patch] snd-pcsp: fix nforce_wa
by Stas Sergeev 17 Oct '09

17 Oct '09

Hi. In this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdi… the nforce workaround (nforce_wa option) was broken, because the introduced "pointer_update" variable was forgotten to use. Also, the "ns" became u64 in some places and "long" in others, which is not the same, AFAIK. I revert that to u64-everywhere. Also, the log says: --- With the callback mode HRTIMER_CB_IRQSAFE_UNLOCK, the start of the stream with zero delay doesn't work. --- but the attached patch, that reverts to the "zero-delay start", works for me... So, while I like the cleanups made, I wonder what was the reason behind that changes? How can I reproduce the breakage of the zero-delay start? Oh, and it would be nice to CC me the changes in that driver, if possible. :)

1 0