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

[alsa-devel] Procedure to add files in /usr/share/alsa/cards/
by Nitin PAI 26 Feb '10

26 Feb '10

Hi, What is the procedure to add a new conf file in /usr/share/alsa/cards ? What should be the name of the file and any other changes i need to make so that aplay -L displayes all the devices. Thanks, Nitin

1 0

[alsa-devel] [PATCH] [patch 2/2] AC97: add full duplex support for atmel AT91 and AVR.
by Sedji Gaouaou 26 Feb '10

26 Feb '10

This patch add full duplex support on AT91 and AVR. It was a bug: we needed to check first if there are some chips opened so we could enable both reception and sending of the data. Signed-off-by: Sedji Gaouaou <sedji.gaouaou(a)atmel.com> --- sound/atmel/ac97c.c | 16 ++++++++++++---- 1 files changed, 12 insertions(+), 4 deletions(-) diff --git a/sound/atmel/ac97c.c b/sound/atmel/ac97c.c index d48a59a..6f5e22c 100644 --- a/sound/atmel/ac97c.c +++ b/sound/atmel/ac97c.c @@ -339,7 +339,11 @@ static int atmel_ac97c_playback_prepare(struct snd_pcm_substream *substream) ac97c_writel(chip, OCA, word); /* configure sample format and size */ - word = AC97C_CMR_DMAEN | AC97C_CMR_SIZE_16; + word = ac97c_readl(chip, CAMR); + if (chip->opened <= 1) + word = AC97C_CMR_DMAEN | AC97C_CMR_SIZE_16; + else + word |= AC97C_CMR_DMAEN | AC97C_CMR_SIZE_16; switch (runtime->format) { case SNDRV_PCM_FORMAT_S16_LE: @@ -426,7 +430,11 @@ static int atmel_ac97c_capture_prepare(struct snd_pcm_substream *substream) ac97c_writel(chip, ICA, word); /* configure sample format and size */ - word = AC97C_CMR_DMAEN | AC97C_CMR_SIZE_16; + word = ac97c_readl(chip, CAMR); + if (chip->opened <= 1) + word = AC97C_CMR_DMAEN | AC97C_CMR_SIZE_16; + else + word |= AC97C_CMR_DMAEN | AC97C_CMR_SIZE_16; switch (runtime->format) { case SNDRV_PCM_FORMAT_S16_LE: @@ -506,7 +514,7 @@ atmel_ac97c_playback_trigger(struct snd_pcm_substream *substream, int cmd) } else { ptcr = ATMEL_PDC_TXTEN; } - camr |= AC97C_CMR_CENA; + camr |= AC97C_CMR_CENA | AC97C_CSR_ENDTX; break; case SNDRV_PCM_TRIGGER_PAUSE_PUSH: /* fall through */ case SNDRV_PCM_TRIGGER_SUSPEND: /* fall through */ @@ -551,7 +559,7 @@ atmel_ac97c_capture_trigger(struct snd_pcm_substream *substream, int cmd) } else { ptcr = ATMEL_PDC_RXTEN; } - camr |= AC97C_CMR_CENA; + camr |= AC97C_CMR_CENA | AC97C_CSR_ENDRX; break; case SNDRV_PCM_TRIGGER_PAUSE_PUSH: /* fall through */ case SNDRV_PCM_TRIGGER_SUSPEND: /* fall through */ -- 1.5.6.5

3 2

[alsa-devel] Why use spin_lock or spin_lock_irq in trigger callback (audio capture)?
by Yiliang Bao 26 Feb '10

26 Feb '10

Hi, I looked at some PCI audio capture driver like BT878 (sound/pci/bt87x.c) or SAA7134 (drivers/media/video/saa7134-alsa.c), I found that spin_lock instead of spin_lock_irq (or spin_lock_irqsave) is used in trigger function. Is there any reason for that? Thanks, Yiliang

2 1

Re: [alsa-devel] [alsa-cvslog] alsa-kernel: Official ALSA project GIT repository for Linux 2.6 branch, master now at v2.6.31-rc8-407-gfc9e4a3
by Takashi Iwai 26 Feb '10

26 Feb '10

At Tue, 6 Oct 2009 08:36:04 +0200 (CEST), noreply-git(a)alsa-project.org wrote: > commit fc9e4a3811567f8d1d4c263a89e27b52c90d6098 > Author: Clemens Ladisch <clemens(a)ladisch.de> > AuthorDate: Tue Oct 6 08:21:04 2009 +0200 > Commit: Clemens Ladisch <clemens(a)ladisch.de> > CommitDate: Tue Oct 6 08:21:04 2009 +0200 > > sound: via82xx: move DXS volume controls to PCM interface > > The "VIA DXS" controls are actually volume controls that apply to the > four PCM substreams, so we better indicate this connection by moving the > controls to the PCM interface. > > Commit b452e08e73c0e3dbb0be82130217be4b7084299e in 2.6.30 broke the > restoring of these volumes by "amixer restore" that most distributions > use; the renaming in this patch cures that regression by preventing > amixer from applying the old, wrong volume levels to the new controls. > http://bugzilla.kernel.org/show_bug.cgi?id=14151 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532613 > > Signed-off-by: Clemens Ladisch <clemens(a)ladisch.de> > Cc: <stable(a)kernel.org> Well, this control was once removed, and then revived due to complains by users who have used it in mixer. Moving this to PCM iface does almost the same thing, disabling an easy way to access it. I'm afraid that this patch might be regarded as another "regression". For such an old driver, the compatibility is the most important item. If any, we must provide a way to back to the old behavior. thanks, Takashi > > ----------------------------------------------------------------------- > > Diffstat: > sound/pci/via82xx.c | 27 ++++++++++++++++++--------- > 1 files changed, 18 insertions(+), 9 deletions(-) > > > Patch -------------- (max 1500 lines) > diff --git a/sound/pci/via82xx.c b/sound/pci/via82xx.c > index acfa476..91683a3 100644 > --- a/sound/pci/via82xx.c > +++ b/sound/pci/via82xx.c > @@ -1626,7 +1626,7 @@ static int snd_via8233_dxs_volume_get(struct snd_kcontrol *kcontrol, > struct snd_ctl_elem_value *ucontrol) > { > struct via82xx *chip = snd_kcontrol_chip(kcontrol); > - unsigned int idx = snd_ctl_get_ioff(kcontrol, &ucontrol->id); > + unsigned int idx = kcontrol->id.subdevice; > > ucontrol->value.integer.value[0] = VIA_DXS_MAX_VOLUME - chip->playback_volume[idx][0]; > ucontrol->value.integer.value[1] = VIA_DXS_MAX_VOLUME - chip->playback_volume[idx][1]; > @@ -1646,7 +1646,7 @@ static int snd_via8233_dxs_volume_put(struct snd_kcontrol *kcontrol, > struct snd_ctl_elem_value *ucontrol) > { > struct via82xx *chip = snd_kcontrol_chip(kcontrol); > - unsigned int idx = snd_ctl_get_ioff(kcontrol, &ucontrol->id); > + unsigned int idx = kcontrol->id.subdevice; > unsigned long port = chip->port + 0x10 * idx; > unsigned char val; > int i, change = 0; > @@ -1705,11 +1705,12 @@ static struct snd_kcontrol_new snd_via8233_pcmdxs_volume_control __devinitdata = > }; > > static struct snd_kcontrol_new snd_via8233_dxs_volume_control __devinitdata = { > - .name = "VIA DXS Playback Volume", > - .iface = SNDRV_CTL_ELEM_IFACE_MIXER, > + .iface = SNDRV_CTL_ELEM_IFACE_PCM, > + .device = 0, > + /* .subdevice set later */ > + .name = "PCM Playback Volume", > .access = (SNDRV_CTL_ELEM_ACCESS_READWRITE | > SNDRV_CTL_ELEM_ACCESS_TLV_READ), > - .count = 4, > .info = snd_via8233_dxs_volume_info, > .get = snd_via8233_dxs_volume_get, > .put = snd_via8233_dxs_volume_put, > @@ -1936,10 +1937,18 @@ static int __devinit snd_via8233_init_misc(struct via82xx *chip) > } > else /* Using DXS when PCM emulation is enabled is really weird */ > { > - /* Standalone DXS controls */ > - err = snd_ctl_add(chip->card, snd_ctl_new1(&snd_via8233_dxs_volume_control, chip)); > - if (err < 0) > - return err; > + for (i = 0; i < 4; ++i) { > + struct snd_kcontrol *kctl; > + > + kctl = snd_ctl_new1( > + &snd_via8233_dxs_volume_control, chip); > + if (!kctl) > + return -ENOMEM; > + kctl->id.subdevice = i; > + err = snd_ctl_add(chip->card, kctl); > + if (err < 0) > + return err; > + } > } > } > /* select spdif data slot 10/11 */ > ------- End of patch > > hooks/update > --- > Git Source Code Management System > hooks/update refs/heads/master \ > 62f08ef9739c5cb5fff5b5bdec3bc02d522b9a12 \ > fc9e4a3811567f8d1d4c263a89e27b52c90d6098 > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Alsa-cvslog mailing list > Alsa-cvslog(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/alsa-cvslog >

6 22

[alsa-devel] issues porting codec to s3c2443
by Austin, Brian 26 Feb '10

26 Feb '10

Hello, I have forward ported the CS42L52 from 2.6.26.2 to the current asoc git tree. The codec and smdk2443-cs42l52 drivers load correctly, at least I think so, and would like to submit the CS42L52 driver but am having some issues with s3c2412-i2s. From my previous kernel version to the latest there has been significant changes to the S3C architecture and I pretty sure that I am missing something because of that. The question is, is it ok to submit the codec standalone and have someone look at it to make sure I made the correct changes. No compiler warnings occur. My port was based off of the WM8750 if that helps any Here is the output from my SMDK2443 Simtec Advanced Linux Sound Architecture Driver Version 1.0.18a. No device for DAI CS42L52 No device for DAI s3c2412-i2s SMDK2443 cs42l52 ALSA SoC driver ver1.1 10/2008 soc-audio soc-audio: RXEN: Invalid MODE in IISMOD CS42L52: Cirrus Logic ALSA SoC codec cs42l52 driver verison 1.1 10/2008 ALSA device list: No soundcards found. It seems that the S3C2412 I2S is not setup correctly for my platform. Thanks, Brian Austin

4 6

[alsa-devel] aplay: possible circular locking dependency detected
by Daniel Mack 25 Feb '10

25 Feb '10

I got this once while testing an USB audio device. Appeareantly not reproducable. Daniel Feb 21 14:26:29 jup kernel: [69661.385427] Feb 21 14:26:29 jup kernel: [69661.385430] ======================================================= Feb 21 14:26:29 jup kernel: [69661.385435] [ INFO: possible circular locking dependency detected ] Feb 21 14:26:29 jup kernel: [69661.385439] 2.6.33-rc8 #21 Feb 21 14:26:29 jup kernel: [69661.385441] ------------------------------------------------------- Feb 21 14:26:29 jup kernel: [69661.385444] aplay/11761 is trying to acquire lock: Feb 21 14:26:29 jup kernel: [69661.385446] (sysfs_mutex){+.+.+.}, at: [<c10f0668>] sysfs_get_dirent+0x15/0x4c Feb 21 14:26:29 jup kernel: [69661.385457] Feb 21 14:26:29 jup kernel: [69661.385457] but task is already holding lock: Feb 21 14:26:29 jup kernel: [69661.385460] (&pcm->open_mutex){+.+.+.}, at: [<fb68bc8e>] snd_pcm_release+0x55/0x9e [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385474] Feb 21 14:26:29 jup kernel: [69661.385474] which lock already depends on the new lock. Feb 21 14:26:29 jup kernel: [69661.385476] Feb 21 14:26:29 jup kernel: [69661.385478] Feb 21 14:26:29 jup kernel: [69661.385479] the existing dependency chain (in reverse order) is: Feb 21 14:26:29 jup kernel: [69661.385481] Feb 21 14:26:29 jup kernel: [69661.385482] -> #2 (&pcm->open_mutex){+.+.+.}: Feb 21 14:26:29 jup kernel: [69661.385487] [<c1059070>] __lock_acquire+0x10ff/0x1422 Feb 21 14:26:29 jup kernel: [69661.385493] [<c105943b>] lock_acquire+0xa8/0xbf Feb 21 14:26:29 jup kernel: [69661.385498] [<c13720d3>] mutex_lock_nested+0x47/0x2b2 Feb 21 14:26:29 jup kernel: [69661.385503] [<fb68bc8e>] snd_pcm_release+0x55/0x9e [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385513] [<c10aabe9>] __fput+0xeb/0x196 Feb 21 14:26:29 jup kernel: [69661.385517] [<c10aacad>] fput+0x19/0x1b Feb 21 14:26:29 jup kernel: [69661.385522] [<c109ae3b>] remove_vma+0x39/0x58 Feb 21 14:26:29 jup kernel: [69661.385528] [<c109bab3>] do_munmap+0x23c/0x259 Feb 21 14:26:29 jup kernel: [69661.385532] [<c109bb00>] sys_munmap+0x30/0x3f Feb 21 14:26:29 jup kernel: [69661.385536] [<c10028d0>] sysenter_do_call+0x12/0x36 Feb 21 14:26:29 jup kernel: [69661.385541] Feb 21 14:26:29 jup kernel: [69661.385542] -> #1 (&mm->mmap_sem){++++++}: Feb 21 14:26:29 jup kernel: [69661.385547] [<c1059070>] __lock_acquire+0x10ff/0x1422 Feb 21 14:26:29 jup kernel: [69661.385551] [<c105943b>] lock_acquire+0xa8/0xbf Feb 21 14:26:29 jup kernel: [69661.385556] [<c10968db>] might_fault+0x6b/0x88 Feb 21 14:26:29 jup kernel: [69661.385561] [<c11b3cf0>] copy_to_user+0x2c/0xfc Feb 21 14:26:29 jup kernel: [69661.385565] [<c10b5e73>] filldir64+0x97/0xcd Feb 21 14:26:29 jup kernel: [69661.385570] [<c10f0534>] sysfs_readdir+0x117/0x14b Feb 21 14:26:29 jup kernel: [69661.385574] [<c10b6085>] vfs_readdir+0x68/0x94 Feb 21 14:26:29 jup kernel: [69661.385578] [<c10b6114>] sys_getdents64+0x63/0xa0 Feb 21 14:26:29 jup kernel: [69661.385582] [<c10028d0>] sysenter_do_call+0x12/0x36 Feb 21 14:26:29 jup kernel: [69661.385587] Feb 21 14:26:29 jup kernel: [69661.385587] -> #0 (sysfs_mutex){+.+.+.}: Feb 21 14:26:29 jup kernel: [69661.385592] [<c1058dc6>] __lock_acquire+0xe55/0x1422 Feb 21 14:26:29 jup kernel: [69661.385597] [<c105943b>] lock_acquire+0xa8/0xbf Feb 21 14:26:29 jup kernel: [69661.385601] [<c13720d3>] mutex_lock_nested+0x47/0x2b2 Feb 21 14:26:29 jup kernel: [69661.385605] [<c10f0668>] sysfs_get_dirent+0x15/0x4c Feb 21 14:26:29 jup kernel: [69661.385609] [<c10f1b4a>] sysfs_remove_group+0x1e/0xa3 Feb 21 14:26:29 jup kernel: [69661.385614] [<c12359b8>] dpm_sysfs_remove+0x10/0x12 Feb 21 14:26:29 jup kernel: [69661.385619] [<c123114c>] device_del+0x33/0x154 Feb 21 14:26:29 jup kernel: [69661.385625] [<c1231278>] device_unregister+0xb/0x15 Feb 21 14:26:29 jup kernel: [69661.385629] [<c129a209>] usb_remove_ep_devs+0x15/0x1f Feb 21 14:26:29 jup kernel: [69661.385635] [<c12943ff>] remove_intf_ep_devs+0x21/0x32 Feb 21 14:26:29 jup kernel: [69661.385640] [<c12954ea>] usb_set_interface+0x18c/0x22c Feb 21 14:26:29 jup kernel: [69661.385644] [<fc703cd7>] snd_usb_playback_close+0x20/0x33 [snd_usb_audio] Feb 21 14:26:29 jup kernel: [69661.385654] [<fb68bc10>] snd_pcm_release_substream+0x3d/0x66 [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385664] [<fb68bc95>] snd_pcm_release+0x5c/0x9e [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385673] [<c10aabe9>] __fput+0xeb/0x196 Feb 21 14:26:29 jup kernel: [69661.385677] [<c10aacad>] fput+0x19/0x1b Feb 21 14:26:29 jup kernel: [69661.385681] [<c109ae3b>] remove_vma+0x39/0x58 Feb 21 14:26:29 jup kernel: [69661.385685] [<c109bab3>] do_munmap+0x23c/0x259 Feb 21 14:26:29 jup kernel: [69661.385689] [<c109bb00>] sys_munmap+0x30/0x3f Feb 21 14:26:29 jup kernel: [69661.385693] [<c10028d0>] sysenter_do_call+0x12/0x36 Feb 21 14:26:29 jup kernel: [69661.385698] Feb 21 14:26:29 jup kernel: [69661.385698] other info that might help us debug this: Feb 21 14:26:29 jup kernel: [69661.385700] Feb 21 14:26:29 jup kernel: [69661.385702] 2 locks held by aplay/11761: Feb 21 14:26:29 jup kernel: [69661.385705] #0: (&mm->mmap_sem){++++++}, at: [<c109baf3>] sys_munmap+0x23/0x3f Feb 21 14:26:29 jup kernel: [69661.385711] #1: (&pcm->open_mutex){+.+.+.}, at: [<fb68bc8e>] snd_pcm_release+0x55/0x9e [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385723] Feb 21 14:26:29 jup kernel: [69661.385724] stack backtrace: Feb 21 14:26:29 jup kernel: [69661.385727] Pid: 11761, comm: aplay Not tainted 2.6.33-rc8 #21 Feb 21 14:26:29 jup kernel: [69661.385730] Call Trace: Feb 21 14:26:29 jup kernel: [69661.385735] [<c137062c>] ? printk+0xf/0x11 Feb 21 14:26:29 jup kernel: [69661.385740] [<c1057b26>] print_circular_bug+0x90/0x9c Feb 21 14:26:29 jup kernel: [69661.385744] [<c1058dc6>] __lock_acquire+0xe55/0x1422 Feb 21 14:26:29 jup kernel: [69661.385748] [<c105917f>] ? __lock_acquire+0x120e/0x1422 Feb 21 14:26:29 jup kernel: [69661.385753] [<c103d4d3>] ? try_to_del_timer_sync+0x9c/0xa4 Feb 21 14:26:29 jup kernel: [69661.385758] [<c105943b>] lock_acquire+0xa8/0xbf Feb 21 14:26:29 jup kernel: [69661.385762] [<c10f0668>] ? sysfs_get_dirent+0x15/0x4c Feb 21 14:26:29 jup kernel: [69661.385766] [<c10f0668>] ? sysfs_get_dirent+0x15/0x4c Feb 21 14:26:29 jup kernel: [69661.385769] [<c13720d3>] mutex_lock_nested+0x47/0x2b2 Feb 21 14:26:29 jup kernel: [69661.385773] [<c10f0668>] ? sysfs_get_dirent+0x15/0x4c Feb 21 14:26:29 jup kernel: [69661.385777] [<c137187f>] ? __mutex_unlock_slowpath+0xe9/0x105 Feb 21 14:26:29 jup kernel: [69661.385781] [<c10572e5>] ? trace_hardirqs_on_caller+0xff/0x120 Feb 21 14:26:29 jup kernel: [69661.385785] [<c10f0668>] sysfs_get_dirent+0x15/0x4c Feb 21 14:26:29 jup kernel: [69661.385789] [<c10f1b4a>] sysfs_remove_group+0x1e/0xa3 Feb 21 14:26:29 jup kernel: [69661.385793] [<c12359b8>] dpm_sysfs_remove+0x10/0x12 Feb 21 14:26:29 jup kernel: [69661.385797] [<c123114c>] device_del+0x33/0x154 Feb 21 14:26:29 jup kernel: [69661.385801] [<c1231278>] device_unregister+0xb/0x15 Feb 21 14:26:29 jup kernel: [69661.385805] [<c129a209>] usb_remove_ep_devs+0x15/0x1f Feb 21 14:26:29 jup kernel: [69661.385809] [<c12943ff>] remove_intf_ep_devs+0x21/0x32 Feb 21 14:26:29 jup kernel: [69661.385813] [<c12954ea>] usb_set_interface+0x18c/0x22c Feb 21 14:26:29 jup kernel: [69661.385822] [<fc703cd7>] snd_usb_playback_close+0x20/0x33 [snd_usb_audio] Feb 21 14:26:29 jup kernel: [69661.385830] [<fb68bc10>] snd_pcm_release_substream+0x3d/0x66 [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385839] [<fb68bc95>] snd_pcm_release+0x5c/0x9e [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385843] [<c10aabe9>] __fput+0xeb/0x196 Feb 21 14:26:29 jup kernel: [69661.385847] [<c10aacad>] fput+0x19/0x1b Feb 21 14:26:29 jup kernel: [69661.385851] [<c109ae3b>] remove_vma+0x39/0x58 Feb 21 14:26:29 jup kernel: [69661.385854] [<c109bab3>] do_munmap+0x23c/0x259 Feb 21 14:26:29 jup kernel: [69661.385858] [<c109bb00>] sys_munmap+0x30/0x3f Feb 21 14:26:29 jup kernel: [69661.385862] [<c10028d0>] sysenter_do_call+0x12/0x36

2 2

[alsa-devel] ASoC updates for 2.6.34
by Mark Brown 25 Feb '10

25 Feb '10

The following changes since commit d62abe563fa4718e7f85f3e871655434db92366d: Misael Lopez Cruz (1): OMAP4: PMIC: Add support for twl6030 codec are available in the git repository at: git://opensource.wolfsonmicro.com/linux-2.6-asoc.git for-2.6.34 These wind up being a bug fix, without fixing the reporting of the periods a lot of hardware is going to get lots of clock domain issues. Mark Brown (2): ASoC: Remove a unused variables from i.MX FIQ runtime data ASoC: Check progress when reporting periods from i.MX FIQ handler sound/soc/imx/imx-pcm-fiq.c | 40 ++++++++++++++++++++++++++++++---------- 1 files changed, 30 insertions(+), 10 deletions(-)

2 3

[alsa-devel] [PATCHv4 0/7] TWL6030 audio codec initial support
by Olaya, Margarita 25 Feb '10

25 Feb '10

Following patch series add initial support for TWL6030 codec driver. The patch set is based on the series sent from Misael Lopez in October 2009. Changes from v3: - Remove snd_soc_init_card function - Adapt to latest twl core changes based on Balaji's comment Regards, Margarita --- Misael Lopez Cruz (7): OMAP4: PMIC: Add support for twl6030 codec ASoC: TWL6030: Add twl6030 codec driver ASoC: TWL6030: Manual power-up/down sequences ASoC: TWL6030: Add support for low-power PLL ASoC: TWL6030: Add restrictions for low-power playback mode ASoC: TWL6030: Enable audio interrupt ASoC: TWL6030: Detect power-up sequence completion drivers/mfd/twl-core.c | 18 +- include/linux/i2c/twl.h | 4 + sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/twl6030.c | 1241 ++++++++++++++++++++++++++++++++++++++++++++ sound/soc/codecs/twl6030.h | 141 +++++ 6 files changed, 1407 insertions(+), 3 deletions(-) create mode 100644 sound/soc/codecs/twl6030.c create mode 100644 sound/soc/codecs/twl6030.h

2 4

[alsa-devel] No sound on Dell Optiplex 380
by Dale Blount 25 Feb '10

25 Feb '10

Hello, I've been having issues with this new PC and sound since I got it last week. I'm not getting any sound out of the speakers. I've tried both rear speaker and front headphone jacks. It does "pop" when the snd-hda-intel module is loaded, though. I've tried all the model=X options listed for my Realtek chipset and made sure that everything is unmuted and non-zero volume. My alsa-info.sh report can be found here: http://www.alsa-project.org/db/?f=fa4aacb98b85d5a02e05df5e9bffa400409b0c21 Please let me know if I can help testing a possible fix or if any other information is needed. Thanks, Dale

1 0

[alsa-devel] [PATCH 1/2] ASoC: Remove a unused variables from i.MX FIQ runtime data
by Mark Brown 25 Feb '10

25 Feb '10

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/imx/imx-pcm-fiq.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/sound/soc/imx/imx-pcm-fiq.c b/sound/soc/imx/imx-pcm-fiq.c index 5532579..a1c4ce6 100644 --- a/sound/soc/imx/imx-pcm-fiq.c +++ b/sound/soc/imx/imx-pcm-fiq.c @@ -35,12 +35,8 @@ struct imx_pcm_runtime_data { int period; int periods; - unsigned long dma_addr; - int dma; unsigned long offset; unsigned long size; - unsigned long period_cnt; - void *buf; struct timer_list timer; int period_time; }; -- 1.7.0

3 3