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

[alsa-devel] skype and old alsa RC4 symbols
by Jon Smirl 27 May '09

27 May '09

I would like to run pulseaudio 9.15 contained in this ubuntu repository since it fixes my problems with S/PDIF https://launchpad.net/~themuso/+archive/ppa However, the 32b compatibility library in this build don't work with skype since it is missing some RC4 obsolete symbols. jonsmirl@terra:/home/apps/alsa-lib-1.0.19/debian/lib32asound2/usr/lib32$ readelf -W -s libasound.so.2.0.0 | grep snd_pcm_hw_params_get_channels_min 174: 0004a970 58 FUNC WEAK DEFAULT 12 snd_pcm_hw_params_get_channels_min@@ALSA_0.9 454: 0004a970 58 FUNC GLOBAL DEFAULT 12 __snd_pcm_hw_params_get_channels_min@@ALSA_0.9 The 64b library has the missing RC4 symbols. jonsmirl@terra:/home/apps/alsa-lib-1.0.19/debian/libasound2/usr/lib$ readelf -W -s libasound.so.2.0.0 | grep snd_pcm_hw_params_get_channels_min 173: 000000000004ff10 15 FUNC GLOBAL DEFAULT 12 snd_pcm_hw_params_get_channels_min@@ALSA_0.9.0rc4 177: 000000000004ff20 31 FUNC GLOBAL DEFAULT 12 snd_pcm_hw_params_get_channels_min(a)ALSA_0.9 462: 000000000004ff10 15 FUNC GLOBAL DEFAULT 12 __snd_pcm_hw_params_get_channels_min@@ALSA_0.9 jonsmirl@terra:/home/apps/alsa-lib-1.0.19/debian/libasound2/usr/lib$ How do I get the RC4 symbols into the 32 library? I can pull down the source for this and build without problem. I just can't identify what needs to be changed to make the symbols appear in the 32b compat lib. -- Jon Smirl jonsmirl(a)gmail.com

2 2

Re: [alsa-devel] spdif/iec958 outputs at VT1708S not recognized
by Takashi Iwai 27 May '09

27 May '09

At Wed, 27 May 2009 12:35:49 -0400, Sentinel wrote: > > Yeah it didn't work. > > I am lost and generally I can find the answers quickly. I cant use the > "kernel" alsa due to the spdif out and for some reason those undefined > messages just wont go away. I looked into the kernel source and they both > do exist in sound core. I can't imagine what could be wrong. If it's really an ALSA module (not soundcore), it's often because you didn't unload some old modules before loading a new one. Also, if the old modules are also update modules located in /lib/modules/$VERSION/update or so, then the old modules will still win over the newly installed one in /lib/modules/$VERSION/kernel/sound/*. IIRC, Ubuntu or some others install the update modules there. In such a case, you'll need to specify the installation path explicitly via configure option, too. If it's the sound core, you need to make sure that this is really built in, either into the kernel or as a module. And, the kernel tree really points to the version you are running. There are symbols to be referred, so it's not only the source you need to build external modules. At best, you should consult on user forum (or such) for your own distro, since this topic is really distro-specific. Takashi > > -----Original Message----- > From: Takashi Iwai [mailto:tiwai@suse.de] > Sent: Wednesday, May 27, 2009 1:35 AM > To: Sentinel > Cc: alsa-devel(a)alsa-project.org > Subject: Re: [alsa-devel] spdif/iec958 outputs at VT1708S not recognized > > At Tue, 26 May 2009 22:57:31 -0400, > Sentinel wrote: > > > > Okay I figured out my own problem. > > > > > > > > This is specific to those who run 64bit OS. > > > > > > > > for anyone who is getting register_sound_special_device error when > > attempting to compile ALSA, on a 64 bit OS make sure your running your > > configure properly. Most likely your distro has ALSA libraries located in > > the /usr/lib64 path not in /usr/lib and most likely the ld.so.conf is set > to > > look in /usr/lib64 before it searches /usr/lib which is the default for > the > > configure script. As a warning I'd not try to change that order > especially > > if you have built any 32bit compatibility drivers into /usr/lib > > I guess you are looking at a wrong place. > The fix must be coincident :) > > Basically alsa-driver (and kernel) compilation doesn't use any > user-space library, so libpath is irrelevant. The only important > location is the kernel source tree and its build stub. If these > aren't set up properly, such an error (version mismatch or so) may > happen. > > Note that sound_register_special() and co aren't defined in the ALSA > driver, but it's defined in sound_core.c in the kernel. > > > Takashi > >

1 0

[alsa-devel] ASoC updates for 2.6.31
by Mark Brown 27 May '09

27 May '09

The following changes since commit 0f89bdcac61536c5cb2a095a514657019573afb4: Peter Ujfalusi (1): ASoC: TWL4030: HandsfreeL/R mute DAPM switch are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.31 Jon Smirl (4): ASoC: Main rewite of the mpc5200 audio DMA code ASoC: AC97 driver for mpc5200 ASoC: Support for AC97 on Phytec pmc030 base board. ASoC: Fabric bindings for STAC9766 on the Efika Mark Brown (2): ASoC: Mark MPC5200 AC97 as BROKEN until PowerPC merge issues are resolved ASoC: Switch FSL SSI DAI over to symmetric_rates sound/soc/fsl/Kconfig | 28 +++- sound/soc/fsl/Makefile | 5 + sound/soc/fsl/efika-audio-fabric.c | 90 +++++++ sound/soc/fsl/fsl_ssi.c | 9 +- sound/soc/fsl/mpc5200_dma.c | 442 ++++++++++++++++++++++------------- sound/soc/fsl/mpc5200_dma.h | 33 ++-- sound/soc/fsl/mpc5200_psc_ac97.c | 331 ++++++++++++++++++++++++++ sound/soc/fsl/mpc5200_psc_ac97.h | 15 ++ sound/soc/fsl/mpc5200_psc_i2s.c | 247 ++++---------------- sound/soc/fsl/mpc5200_psc_i2s.h | 12 + sound/soc/fsl/pcm030-audio-fabric.c | 90 +++++++ 11 files changed, 905 insertions(+), 397 deletions(-) create mode 100644 sound/soc/fsl/efika-audio-fabric.c create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.c create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.h create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h create mode 100644 sound/soc/fsl/pcm030-audio-fabric.c

2 1

Re: [alsa-devel] 2.6.30: xruns caused by "ALSA: pcm - Safer boundary checks"
by Takashi Iwai 27 May '09

27 May '09

At Tue, 26 May 2009 13:16:49 -0400, Robert Krakora wrote: > > On Tue, May 26, 2009 at 11:41 AM, Takashi Iwai <tiwai(a)suse.de> wrote: > > At Tue, 26 May 2009 10:28:26 -0400, > > Robert Krakora wrote: > >> > >> On Tue, May 26, 2009 at 4:03 AM, Takashi Iwai <tiwai(a)suse.de> wrote: > >> > At Sun, 24 May 2009 23:56:40 -0700, > >> > Nathan Grennan wrote: > >> >> > >> >> Takashi Iwai wrote: > >> >> > Testing the patch would be helpful :) > >> >> > > >> >> > >> >> Will do > >> > > >> > Did you get any positive / negative result? > >> > > >> > We are in the late rc stage, so a fix should be merged ASAP... > >> > > >> > > >> > thanks, > >> > > >> > Takashi > >> > _______________________________________________ > >> > Alsa-devel mailing list > >> > Alsa-devel(a)alsa-project.org > >> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > >> > > >> > > >> > >> Takashi: > >> > >> I cannot speak for the other person experiencing this problem. > >> However, neither your snapshot or Jarloslav's patch corrected the > >> problem which I am experiencing. > > > > So, did you get the same kernel messages when xrun_debug is set? > > > >> I have not looked at the code much > >> in pcm_lib.c or pcm_native.c but it seems as though you are trying to > >> manage FIFO overflow and underflow scenarios. Is my assumption > >> correct? ;-) > > > > No. The problem appears like an invalid check of jiffies in > > snd_pcm_hw_ptr_update*(). After the pause, jiffies isn't recorded > > properly, thus it gets screwed up. > > > > To be sure, could you try the patch below? This will disable the > > jiffies check completely. If the problem still happens, then it's > > somewhere else where we need to check. > > > > > > thanks, > > > > Takashi > > > > --- > > diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c > > index a2a792c..47837a6 100644 > > --- a/sound/core/pcm_lib.c > > +++ b/sound/core/pcm_lib.c > > @@ -249,6 +249,7 @@ static int snd_pcm_update_hw_ptr_interrupt(struct snd_pcm_substream *substream) > > new_hw_ptr = hw_base + pos; > > } > > } > > +#if 0 /* no jiffies check */ > > /* Skip the jiffies check for hardwares with BATCH flag. > > * Such hardware usually just increases the position at each IRQ, > > * thus it can't give any strange position. > > @@ -279,6 +280,7 @@ static int snd_pcm_update_hw_ptr_interrupt(struct snd_pcm_substream *substream) > > delta = 0; > > } > > no_jiffies_check: > > +#endif /* no jiffies check */ > > if (delta > runtime->period_size + runtime->period_size / 2) { > > hw_ptr_error(substream, > > "Lost interrupts? " > > @@ -336,6 +338,7 @@ int snd_pcm_update_hw_ptr(struct snd_pcm_substream *substream) > > hw_base = 0; > > new_hw_ptr = hw_base + pos; > > } > > +#if 0 /* no jiffies check */ > > if (((delta * HZ) / runtime->rate) > jdelta + HZ/100) { > > hw_ptr_error(substream, > > "hw_ptr skipping! " > > @@ -345,6 +348,7 @@ int snd_pcm_update_hw_ptr(struct snd_pcm_substream *substream) > > ((delta * HZ) / runtime->rate)); > > return 0; > > } > > +#endif /* no jiffies check */ > > if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK && > > runtime->silence_size > 0) > > snd_pcm_playback_silence(substream, new_hw_ptr); > > > > > > Takashi: > > Your patch worked. jiffies seems to be the cause. xrun_debug is on > and I do not see any of the error messages. [Re-added some dropped addresses to Cc] Thanks for testing! I have an impression that the jiffies check can behave pretty buggy in cases the hardware doesn't give a smooth pointer update. It's supposed to filter out spontaneous invalid pointer values. That'll work indeed (although I don't think the check in snd_pcm_period_elapsed() is worth). But what if a hardware returns the pointer value that is not always updated smoothly? Assume a hardware returning only spontaneously updated values, 0 at t=0, 1000 at t=100, 2000 at t=200, and so on. If snd_pcm_update_hw_ptr() is called at t=99, it gets still position 0. Then when it's called at t=100, it suddenly increases to position 1000 while jiffies delta is only 1. The current code would filter out this update because it appears as if too much. The problem continues, if snd_pcm_update_hw_ptr() is constantly called at each t=100, 101, ... At each call, jiffies delta is 1, but the position delta is still 1000 because it wasn't updated. That is, as long as the app keeps calling snd_pcm_update_hw_ptr(), the position won't be updated. This is pretty possible especially with an app like pulseaudio. I have a feeling that we should disable the jiffies check in that part, at least for 2.6.30, until a better solution is found. The jiffies check is already done and works pretty well in the driver side (hda-intel and intel8x0). But this check in the PCM core can be (not always, though) buggy, and actually gives problems sometimes. Takashi

3 3

[alsa-devel] [PATCH V2] Modify mpc5200 AC97 driver to use V9 of spin_event_timeout()
by Jon Smirl 27 May '09

27 May '09

The function signature for spin_event_timeout() has changed in version V9. Adjust the mpc5200 AC97 driver to use the new function. v2 - switch back to udelay() for fixed timeouts. Signed-off-by: Jon Smirl <jonsmirl(a)gmail.com> --- sound/soc/fsl/mpc5200_psc_ac97.c | 30 ++++++++++++++---------------- 1 files changed, 14 insertions(+), 16 deletions(-) diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c index 9f2df15..4342b51 100644 --- a/sound/soc/fsl/mpc5200_psc_ac97.c +++ b/sound/soc/fsl/mpc5200_psc_ac97.c @@ -31,13 +31,13 @@ static struct psc_dma *psc_dma; static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg) { - int rc; + int status; unsigned int val; /* Wait for command send status zero = ready */ - spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) & - MPC52xx_PSC_SR_CMDSEND), 100, 0, rc); - if (rc == 0) { + status= spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) & + MPC52xx_PSC_SR_CMDSEND), 100, 0); + if (status == 0) { pr_err("timeout on ac97 bus (rdy)\n"); return -ENODEV; } @@ -45,9 +45,9 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg) out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((reg & 0x7f) << 24)); /* Wait for the answer */ - spin_event_timeout((in_be16(&psc_dma->psc_regs->sr_csr.status) & - MPC52xx_PSC_SR_DATA_VAL), 100, 0, rc); - if (rc == 0) { + status = spin_event_timeout((in_be16(&psc_dma->psc_regs->sr_csr.status) & + MPC52xx_PSC_SR_DATA_VAL), 100, 0); + if (status == 0) { pr_err("timeout on ac97 read (val) %x\n", in_be16(&psc_dma->psc_regs->sr_csr.status)); return -ENODEV; @@ -66,12 +66,12 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg) static void psc_ac97_write(struct snd_ac97 *ac97, unsigned short reg, unsigned short val) { - int rc; + int status; /* Wait for command status zero = ready */ - spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) & - MPC52xx_PSC_SR_CMDSEND), 100, 0, rc); - if (rc == 0) { + status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) & + MPC52xx_PSC_SR_CMDSEND), 100, 0); + if (status == 0) { pr_err("timeout on ac97 bus (write)\n"); return; } @@ -82,24 +82,22 @@ static void psc_ac97_write(struct snd_ac97 *ac97, static void psc_ac97_warm_reset(struct snd_ac97 *ac97) { - int rc; struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs; out_be32(&regs->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_AWR); - spin_event_timeout(0, 3, 0, rc); + udelay(3); out_be32(&regs->sicr, psc_dma->sicr); } static void psc_ac97_cold_reset(struct snd_ac97 *ac97) { - int rc; struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs; /* Do a cold reset */ out_8(&regs->op1, MPC52xx_PSC_OP_RES); - spin_event_timeout(0, 10, 0, rc); + udelay(10); out_8(&regs->op0, MPC52xx_PSC_OP_RES); - spin_event_timeout(0, 50, 0, rc); + udelat(50); psc_ac97_warm_reset(ac97); }

2 1

[alsa-devel] spdif/iec958 outputs at VT1708S not recognized
by Sentinel 27 May '09

27 May '09

Okay I figured out my own problem. This is specific to those who run 64bit OS. for anyone who is getting register_sound_special_device error when attempting to compile ALSA, on a 64 bit OS make sure your running your configure properly. Most likely your distro has ALSA libraries located in the /usr/lib64 path not in /usr/lib and most likely the ld.so.conf is set to look in /usr/lib64 before it searches /usr/lib which is the default for the configure script. As a warning I'd not try to change that order especially if you have built any 32bit compatibility drivers into /usr/lib ./configure -prefix=/usr/lib64 Although it wouldn't be a bad idea for the configure to detect that if possible.

2 1

[alsa-devel] [PATCH V3] Modify mpc5200 AC97 driver to use V9 of spin_event_timeout()
by Jon Smirl 27 May '09

27 May '09

The function signature for spin_event_timeout() has changed in version V9. Adjust the mpc5200 AC97 driver to use the new function. v2 - switch back to udelay() for fixed timeouts. v3 - forgot about driver being market broken, fix typo Signed-off-by: Jon Smirl <jonsmirl(a)gmail.com> --- sound/soc/fsl/mpc5200_psc_ac97.c | 30 ++++++++++++++---------------- 1 files changed, 14 insertions(+), 16 deletions(-) diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c index 9f2df15..794a247 100644 --- a/sound/soc/fsl/mpc5200_psc_ac97.c +++ b/sound/soc/fsl/mpc5200_psc_ac97.c @@ -31,13 +31,13 @@ static struct psc_dma *psc_dma; static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg) { - int rc; + int status; unsigned int val; /* Wait for command send status zero = ready */ - spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) & - MPC52xx_PSC_SR_CMDSEND), 100, 0, rc); - if (rc == 0) { + status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) & + MPC52xx_PSC_SR_CMDSEND), 100, 0); + if (status == 0) { pr_err("timeout on ac97 bus (rdy)\n"); return -ENODEV; } @@ -45,9 +45,9 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg) out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((reg & 0x7f) << 24)); /* Wait for the answer */ - spin_event_timeout((in_be16(&psc_dma->psc_regs->sr_csr.status) & - MPC52xx_PSC_SR_DATA_VAL), 100, 0, rc); - if (rc == 0) { + status = spin_event_timeout((in_be16(&psc_dma->psc_regs->sr_csr.status) & + MPC52xx_PSC_SR_DATA_VAL), 100, 0); + if (status == 0) { pr_err("timeout on ac97 read (val) %x\n", in_be16(&psc_dma->psc_regs->sr_csr.status)); return -ENODEV; @@ -66,12 +66,12 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg) static void psc_ac97_write(struct snd_ac97 *ac97, unsigned short reg, unsigned short val) { - int rc; + int status; /* Wait for command status zero = ready */ - spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) & - MPC52xx_PSC_SR_CMDSEND), 100, 0, rc); - if (rc == 0) { + status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) & + MPC52xx_PSC_SR_CMDSEND), 100, 0); + if (status == 0) { pr_err("timeout on ac97 bus (write)\n"); return; } @@ -82,24 +82,22 @@ static void psc_ac97_write(struct snd_ac97 *ac97, static void psc_ac97_warm_reset(struct snd_ac97 *ac97) { - int rc; struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs; out_be32(&regs->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_AWR); - spin_event_timeout(0, 3, 0, rc); + udelay(3); out_be32(&regs->sicr, psc_dma->sicr); } static void psc_ac97_cold_reset(struct snd_ac97 *ac97) { - int rc; struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs; /* Do a cold reset */ out_8(&regs->op1, MPC52xx_PSC_OP_RES); - spin_event_timeout(0, 10, 0, rc); + udelay(10); out_8(&regs->op0, MPC52xx_PSC_OP_RES); - spin_event_timeout(0, 50, 0, rc); + udelay(50); psc_ac97_warm_reset(ac97); }

1 0

[alsa-devel] [PATCH] Modify mpc5200 AC97 driver to use V9 of spin_event_timeout()
by Jon Smirl 27 May '09

27 May '09

The function signature for spin_event_timeout() has changed in version V9. Adjust the mpc5200 AC97 driver to use the new function. Signed-off-by: Jon Smirl <jonsmirl(a)gmail.com> --- sound/soc/fsl/mpc5200_psc_ac97.c | 30 ++++++++++++++---------------- 1 files changed, 14 insertions(+), 16 deletions(-) diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c index 9f2df15..bab80ac 100644 --- a/sound/soc/fsl/mpc5200_psc_ac97.c +++ b/sound/soc/fsl/mpc5200_psc_ac97.c @@ -31,13 +31,13 @@ static struct psc_dma *psc_dma; static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg) { - int rc; + int status; unsigned int val; /* Wait for command send status zero = ready */ - spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) & - MPC52xx_PSC_SR_CMDSEND), 100, 0, rc); - if (rc == 0) { + status= spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) & + MPC52xx_PSC_SR_CMDSEND), 100, 0); + if (status == 0) { pr_err("timeout on ac97 bus (rdy)\n"); return -ENODEV; } @@ -45,9 +45,9 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg) out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((reg & 0x7f) << 24)); /* Wait for the answer */ - spin_event_timeout((in_be16(&psc_dma->psc_regs->sr_csr.status) & - MPC52xx_PSC_SR_DATA_VAL), 100, 0, rc); - if (rc == 0) { + status = spin_event_timeout((in_be16(&psc_dma->psc_regs->sr_csr.status) & + MPC52xx_PSC_SR_DATA_VAL), 100, 0); + if (status == 0) { pr_err("timeout on ac97 read (val) %x\n", in_be16(&psc_dma->psc_regs->sr_csr.status)); return -ENODEV; @@ -66,12 +66,12 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg) static void psc_ac97_write(struct snd_ac97 *ac97, unsigned short reg, unsigned short val) { - int rc; + int status; /* Wait for command status zero = ready */ - spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) & - MPC52xx_PSC_SR_CMDSEND), 100, 0, rc); - if (rc == 0) { + status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) & + MPC52xx_PSC_SR_CMDSEND), 100, 0); + if (status == 0) { pr_err("timeout on ac97 bus (write)\n"); return; } @@ -82,24 +82,22 @@ static void psc_ac97_write(struct snd_ac97 *ac97, static void psc_ac97_warm_reset(struct snd_ac97 *ac97) { - int rc; struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs; out_be32(&regs->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_AWR); - spin_event_timeout(0, 3, 0, rc); + spin_event_timeout(0, 3, 0); out_be32(&regs->sicr, psc_dma->sicr); } static void psc_ac97_cold_reset(struct snd_ac97 *ac97) { - int rc; struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs; /* Do a cold reset */ out_8(&regs->op1, MPC52xx_PSC_OP_RES); - spin_event_timeout(0, 10, 0, rc); + spin_event_timeout(0, 10, 0); out_8(&regs->op0, MPC52xx_PSC_OP_RES); - spin_event_timeout(0, 50, 0, rc); + spin_event_timeout(0, 50, 0); psc_ac97_warm_reset(ac97); }

3 8

[alsa-devel] spdif/iec958 outputs at VT1708S not recognized
by Sentinel 27 May '09

27 May '09

Well I guess not it still didn't work and its not -prefix= its -libdir=

1 0

[alsa-devel] [PATCH] ASoC: Switch FSL SSI DAI over to symmetric_rates
by Mark Brown 27 May '09

27 May '09

The effect of symmetric_constraints should provide a standard way to enforce the use of the same sample rate for both directions. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/fsl/fsl_ssi.c | 9 +++------ 1 files changed, 3 insertions(+), 6 deletions(-) diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 47afaa9..93f0f38 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -375,18 +375,14 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream, struct snd_pcm_runtime *first_runtime = ssi_private->first_stream->runtime; - if (!first_runtime->rate || !first_runtime->sample_bits) { + if (!first_runtime->sample_bits) { dev_err(substream->pcm->card->dev, - "set sample rate and size in %s stream first\n", + "set sample size in %s stream first\n", substream->stream == SNDRV_PCM_STREAM_PLAYBACK ? "capture" : "playback"); return -EAGAIN; } - snd_pcm_hw_constraint_minmax(substream->runtime, - SNDRV_PCM_HW_PARAM_RATE, - first_runtime->rate, first_runtime->rate); - /* If we're in synchronous mode, then we need to constrain * the sample size as well. We don't support independent sample * rates in asynchronous mode. @@ -693,6 +689,7 @@ struct snd_soc_dai *fsl_ssi_create_dai(struct fsl_ssi_info *ssi_info) fsl_ssi_dai->name = ssi_private->name; fsl_ssi_dai->id = ssi_info->id; fsl_ssi_dai->dev = ssi_info->dev; + fsl_ssi_dai->symmetric_rates = 1; ret = snd_soc_register_dai(fsl_ssi_dai); if (ret != 0) { -- 1.6.3.1

2 1