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

[alsa-devel] [PATCH] ALSA: hda - Add model quirk for Sony VAIO VGN-NR21E
by Ozan Caglayan 11 Mar '09

11 Mar '09

One of our users reported that its laptop doesn't mute the internal speakers when a jack is inserted into headphones without model=hippo. Here's the alsa-info output for reference: http://www.alsa-project.org/db/?f=8dae188ec2db110b9e6804c60f4659f0cb606c62 Signed-off-by: Ozan Caglayan <ozan(a)pardus.org.tr> --- sound/pci/hda/patch_realtek.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index b794cba..6e79770 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10874,6 +10874,7 @@ static struct snd_pci_quirk alc262_cfg_tbl[] = { SND_PCI_QUIRK(0x103c, 0x2817, "HP RP5700", ALC262_HP_RP5700), SND_PCI_QUIRK(0x104d, 0x1f00, "Sony ASSAMD", ALC262_SONY_ASSAMD), SND_PCI_QUIRK(0x104d, 0x8203, "Sony UX-90", ALC262_HIPPO), + SND_PCI_QUIRK(0x104d, 0x902d, "Sony VAIO VGN-NR21E", ALC262_HIPPO), SND_PCI_QUIRK(0x104d, 0x820f, "Sony ASSAMD", ALC262_SONY_ASSAMD), SND_PCI_QUIRK(0x104d, 0x9016, "Sony VAIO", ALC262_AUTO), /* dig-only */ SND_PCI_QUIRK_MASK(0x104d, 0xff00, 0x9000, "Sony VAIO", -- 1.6.2

2 4

[alsa-devel] Accuracy of substream->ops->pointer?
by Timur Tabi 11 Mar '09

11 Mar '09

During capture, my hardware can take up to two milliseconds for the DMA to start transferring data to the buffer. This is because the internal FIFO needs to fill up before DMA starts. Today, my .trigger function (during a START request) just waits until the FIFO is full before returning control back to ALSA. This seems to work, except that I wait by using a busy-loop. As you can imagine, a 2ms busy loop is not a good idea. An alternative idea is to have my .pointer function return 0 if DMA has not yet started. This appears to work, but I want to make sure it's a good idea. My concern is that I might confuse ALSA because it is expecting some data in the buffer after capture has started. Is my approach correct? -- Timur Tabi Linux kernel developer at Freescale

2 1

[alsa-devel] Fix audio for Lyrtech SFFSDR board
by Hugo Villeneuve 10 Mar '09

10 Mar '09

These patches make the audio work again on the SFFSDR

4 18

[alsa-devel] PXA SSP and external clocked I2S again
by Daniel Mack 10 Mar '09

10 Mar '09

Hi, as denoted yesterday, we've spend some more time on the PXA/SSP/I2S issue and would like to share conclusions about out utterly frustrating trial-and-error sessions during the last days, especially as reference for everyone who tries to get a similar setup running. The situation on our board is: we have a tunable master clock generator, a CS4270 codec and an PXA303 connected to each other. In order to use the master clock, the PXA needs to be set to an external clock mode and for the CS4270 to operate properly, we need to provide a full 64 bits I2S stream, even though not all of the data bits (in fact, currently only 16 of them per channel) carry data. The above thing was not possible with the pxa-ssp's current approach as it entirely relyed on the network mode and the time slots mechanism which is - according to the datasheets - supposed to do exactly this, but which simply doesn't work at all. It might work for existing boards without our constrains, but that's more or less due to coincidence. Hence, we switched over to non-network mode and fiddled around with the PSP bits a lot until we found a mode that fits our needs, at least as long as we let the PXA be master in the game (which we did for test purposes). As soon as the clock direction changes (codec takes over control for LRCLK and bitclk), the PSP feature fails badly again. The final solution is now to never ever set the PXA to a real slave mode (DAIFMT_CBM_CFM) but only provide the master clock to its input pin (SSPEXTCLK), set the clock config to SSP_CLK_EXT and let the PXA derive the other clocks from that one internally. Another thing is: ALSA doesn't currently provide a way to configure a DAI format where the I2S protocol has more clock bits than data bits. One of the upcoming series of 4 patches adds them. Best regards, Daniel

4 27

[PATCH 2/2] pxa-ssp: don't touch registers if stream is running
by Daniel Mack 10 Mar '09

10 Mar '09

In pxa_ssp_set_dai_fmt(), check whether there is anything to do at all. If there would be but the SSP port is in use already, bail out. Signed-off-by: Daniel Mack <daniel(a)caiaq.de> Cc: Philipp Zabel <philipp.zabel(a)gmail.com> Cc: Liam Girdwood <lrg(a)kernel.org> --- sound/soc/pxa/pxa-ssp.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c index 1b3a81c..569c0a6 100644 --- a/sound/soc/pxa/pxa-ssp.c +++ b/sound/soc/pxa/pxa-ssp.c @@ -525,6 +525,17 @@ static int pxa_ssp_set_dai_fmt(struct snd_soc_dai *cpu_dai, u32 sscr1; u32 sspsp; + /* check if we need to change anything at all */ + if (priv->dai_fmt == fmt) + return 0; + + /* we can only change the settings if the port is not in use */ + if (ssp_read_reg(ssp, SSCR0) & SSCR0_SSE) { + dev_err(&ssp->pdev->dev, + "can't change hardware dai format: stream is in use"); + return -EINVAL; + } + /* reset port settings */ sscr0 = ssp_read_reg(ssp, SSCR0) & (SSCR0_ECS | SSCR0_NCS | SSCR0_MOD | SSCR0_ACS); -- 1.6.2

1 0

[PATCH 1/2] pxa-ssp: switch from network mode to PSP
by Daniel Mack 10 Mar '09

10 Mar '09

This switches the pxa ssp port usage from network mode to PSP mode. Removed some comments and checks for configured TDM channels. A special case is added to support configuration where BCLK = 64fs. We need to do some black magic in this case which doesn't look nice but there is unfortunately no other option than that. Signed-off-by: Daniel Mack <daniel(a)caiaq.de> --- sound/soc/pxa/pxa-ssp.c | 56 ++++++++++++++++++++++++++++++---------------- 1 files changed, 36 insertions(+), 20 deletions(-) diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c index 7fc13f0..1b3a81c 100644 --- a/sound/soc/pxa/pxa-ssp.c +++ b/sound/soc/pxa/pxa-ssp.c @@ -45,6 +45,7 @@ struct ssp_priv { struct ssp_dev dev; unsigned int sysclk; + unsigned int scr_div; int dai_fmt; #ifdef CONFIG_PM struct ssp_state state; @@ -281,11 +282,13 @@ static int pxa_ssp_resume(struct snd_soc_dai *cpu_dai) * ssp_set_clkdiv - set SSP clock divider * @div: serial clock rate divider */ -static void ssp_set_scr(struct ssp_dev *dev, u32 div) +static void ssp_set_scr(struct ssp_priv *priv, u32 div) { + struct ssp_dev *dev = &priv->dev; struct ssp_device *ssp = dev->ssp; u32 sscr0 = ssp_read_reg(dev->ssp, SSCR0) & ~SSCR0_SCR; + priv->scr_div = div; ssp_write_reg(ssp, SSCR0, (sscr0 | SSCR0_SerClkDiv(div))); } @@ -327,7 +330,7 @@ static int pxa_ssp_set_dai_sysclk(struct snd_soc_dai *cpu_dai, break; case PXA_SSP_CLK_AUDIO: priv->sysclk = 0; - ssp_set_scr(&priv->dev, 1); + ssp_set_scr(priv, 1); sscr0 |= SSCR0_ACS; break; default: @@ -388,7 +391,7 @@ static int pxa_ssp_set_dai_clkdiv(struct snd_soc_dai *cpu_dai, ssp_write_reg(ssp, SSACD, val); break; case PXA_SSP_DIV_SCR: - ssp_set_scr(&priv->dev, div); + ssp_set_scr(priv, div); break; default: return -ENODEV; @@ -547,18 +550,17 @@ static int pxa_ssp_set_dai_fmt(struct snd_soc_dai *cpu_dai, switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) { case SND_SOC_DAIFMT_I2S: - sscr0 |= SSCR0_MOD | SSCR0_PSP; + sscr0 |= SSCR0_PSP; sscr1 |= SSCR1_RWOT | SSCR1_TRAIL; switch (fmt & SND_SOC_DAIFMT_INV_MASK) { case SND_SOC_DAIFMT_NB_NF: - sspsp |= SSPSP_FSRT; break; case SND_SOC_DAIFMT_NB_IF: - sspsp |= SSPSP_SFRMP | SSPSP_FSRT; + sspsp |= SSPSP_SFRMP; break; case SND_SOC_DAIFMT_IB_IF: - sspsp |= SSPSP_SFRMP; + sspsp |= SSPSP_SFRMP | SSPSP_SCMODE(3); break; default: return -EINVAL; @@ -644,37 +646,51 @@ static int pxa_ssp_hw_params(struct snd_pcm_substream *substream, sscr0 |= SSCR0_FPCKE; #endif sscr0 |= SSCR0_DataSize(16); - /* use network mode (2 slots) for 16 bit stereo */ break; case SNDRV_PCM_FORMAT_S24_LE: sscr0 |= (SSCR0_EDSS | SSCR0_DataSize(8)); - /* we must be in network mode (2 slots) for 24 bit stereo */ break; case SNDRV_PCM_FORMAT_S32_LE: sscr0 |= (SSCR0_EDSS | SSCR0_DataSize(16)); - /* we must be in network mode (2 slots) for 32 bit stereo */ break; } ssp_write_reg(ssp, SSCR0, sscr0); switch (priv->dai_fmt & SND_SOC_DAIFMT_FORMAT_MASK) { case SND_SOC_DAIFMT_I2S: - /* Cleared when the DAI format is set */ - sspsp = ssp_read_reg(ssp, SSPSP) | SSPSP_SFRMWDTH(width); + sspsp = ssp_read_reg(ssp, SSPSP); + + if ((priv->scr_div == 4) && (width == 16)) { + /* This is a special case where the bitclk is 64fs + * and we're not dealing with 2*32 bits of audio + * samples. + * + * The SSP values used for that are all found out by + * trying and failing a lot; some of the registers + * needed for that mode are only available on PXA3xx. + */ + +#ifdef CONFIG_PXA3xx + if (!cpu_is_pxa3xx()) + return -EINVAL; + + sspsp |= SSPSP_SFRMWDTH(width * 2); + sspsp |= SSPSP_SFRMDLY(width * 4); + sspsp |= SSPSP_EDMYSTOP(3); + sspsp |= SSPSP_DMYSTOP(3); + sspsp |= SSPSP_DMYSTRT(1); +#else + return -EINVAL; +#endif + } else + sspsp |= SSPSP_SFRMWDTH(width); + ssp_write_reg(ssp, SSPSP, sspsp); break; default: break; } - /* We always use a network mode so we always require TDM slots - * - complain loudly and fail if they've not been set up yet. - */ - if (!(ssp_read_reg(ssp, SSTSA) & 0xf)) { - dev_err(&ssp->pdev->dev, "No TDM timeslot configured\n"); - return -EINVAL; - } - dump_registers(ssp); return 0; -- 1.6.2

1 0

[alsa-devel] [PATCH] [SOUND] Fixes recording gain control
by Viral Mehta 10 Mar '09

10 Mar '09

Sorry for resending it again and again. This is since submitting a patch first time. Please never mind. Consider the below thing. Have tested two usb audio mic devices. At the time of initialization, SNDRV_MIXER_OSS_PRESENT_PVOLUME bit is not set for MIC (slot 7). So, the same should not be checked when an application tries to do gain control for audio recording devices. Just check slot->present for SNDRV_MIXER_OSS_PRESENT_CVOLUME independently. Verified with a simple application which opens /dev/dsp for recording and /dev/mixer for volume control. Signed-off-by: Viral Mehta <viral.mehta(a)einfochips.com> --- sound/core/oss/mixer_oss.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- sound/core/oss/mixer_oss.org.c 2009-03-10 18:37:49.000000000 +0530 +++ sound/core/oss/mixer_oss.c 2009-03-10 18:37:07.000000000 +0530 @@ -692,6 +692,8 @@ static int snd_mixer_oss_put_volume1(str snd_mixer_oss_put_volume1_vol(fmixer, pslot, slot->numid[SNDRV_MIXER_OSS_ITEM_PVOLUME], left, right); if (slot->present & SNDRV_MIXER_OSS_PRESENT_CVOLUME) snd_mixer_oss_put_volume1_vol(fmixer, pslot, slot->numid[SNDRV_MIXER_OSS_ITEM_CVOLUME], left, right); + } else if (slot->present & SNDRV_MIXER_OSS_PRESENT_CVOLUME) { + snd_mixer_oss_put_volume1_vol(fmixer, pslot, slot->numid[SNDRV_MIXER_OSS_ITEM_CVOLUME], left, right); } else if (slot->present & SNDRV_MIXER_OSS_PRESENT_GVOLUME) { snd_mixer_oss_put_volume1_vol(fmixer, pslot, slot->numid[SNDRV_MIXER_OSS_ITEM_GVOLUME], left, right); } else if (slot->present & SNDRV_MIXER_OSS_PRESENT_GLOBAL) { -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________

2 1

[alsa-devel] [PATCH] [SOUND] Fixes recording gain control
by Viral Mehta 10 Mar '09

10 Mar '09

Have tested two usb audio mic devices. At the time of initialization, SNDRV_MIXER_OSS_PRESENT_PVOLUME bit is not set for MIC (slot 7). So, the same should not be checked when an application tries to do gain control for audio recording devices. Just check slot->present for SNDRV_MIXER_OSS_PRESENT_CVOLUME independently. Verified with a simple application which opens /dev/dsp for recording and /dev/mixer for volume control. Signed-off-by: Viral Mehta <viral.mehta(a)einfochips.com> --- sound/core/oss/mixer_oss.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/core/oss/mixer_oss.c b/sound/core/oss/mixer_oss.c index 4690b8b..919c7eb 100644 --- a/sound/core/oss/mixer_oss.c +++ b/sound/core/oss/mixer_oss.c @@ -690,7 +690,7 @@ static int snd_mixer_oss_put_volume1(struct snd_mixer_oss_file *fmixer, if (slot->present & SNDRV_MIXER_OSS_PRESENT_PVOLUME) { snd_mixer_oss_put_volume1_vol(fmixer, pslot, slot->numid[SNDRV_MIXER_OSS_ITEM_PVOLUME], left, right); - if (slot->present & SNDRV_MIXER_OSS_PRESENT_CVOLUME) + } else if (slot->present & SNDRV_MIXER_OSS_PRESENT_CVOLUME) { snd_mixer_oss_put_volume1_vol(fmixer, pslot, slot->numid[SNDRV_MIXER_OSS_ITEM_CVOLUME], left, right); } else if (slot->present & SNDRV_MIXER_OSS_PRESENT_GVOLUME) { snd_mixer_oss_put_volume1_vol(fmixer, pslot, slot->numid[SNDRV_MIXER_OSS_ITEM_GVOLUME], left, right); -- 1.6.0.2.GIT -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________

1 0

Re: [alsa-devel] [PATCH] [SOUND] recording gain control
by Clemens Ladisch 10 Mar '09

10 Mar '09

(CC alsa-devel) Viral Mehta wrote: > Hi, > > I am trying to do gain control while RECORDING for my Audio Mic device. > > My application opens /dev/mixer device and calls ioctl(fdmixer, > MIXER_WRITE(SOUND_MIXER_MIC), ...) > > But, the call fails. It traces to sound/core/oss/mixer_oss.c file and > snd_mixer_oss_put_volume1() function. > It never falls in "if (slot->present & SNDRV_MIXER_OSS_PRESENT_CVOLUME)" > as condition "if (slot->present & SNDRV_MIXER_OSS_PRESENT_PVOLUME) " > comes as false. > > I think there is a bug in kernel and I think it should be like as below, > > --- sound/core/oss/mixer_oss.c 2008-12-03 13:24:02.000000000 +0530 > +++ sound/core/oss/mixer_oss.c 2009-03-09 16:22:06.548766896 +0530 > @@ -688,7 +688,7 @@ static int snd_mixer_oss_put_volume1(str > > if (slot->present & SNDRV_MIXER_OSS_PRESENT_PVOLUME) { > snd_mixer_oss_put_volume1_vol(fmixer, pslot, > slot->numid[SNDRV_MIXER_OSS_ITEM_PVOLUME], left, right); > - if (slot->present & SNDRV_MIXER_OSS_PRESENT_CVOLUME) > + } else if (slot->present & SNDRV_MIXER_OSS_PRESENT_CVOLUME) { > snd_mixer_oss_put_volume1_vol(fmixer, pslot, > slot->numid[SNDRV_MIXER_OSS_ITEM_CVOLUME], left, right); > } else if (slot->present & SNDRV_MIXER_OSS_PRESENT_GVOLUME) { > snd_mixer_oss_put_volume1_vol(fmixer, pslot, > slot->numid[SNDRV_MIXER_OSS_ITEM_GVOLUME], left, right); Your mailer mangled the patch; see linux/Documentation/email-clients.txt. Best regards, Clemens

3 3

[alsa-devel] [PATCH 0/5] Blackfin ASoC fixing and updates
by Bryan Wu 10 Mar '09

10 Mar '09

Hi Mark, We have some patches for Blackfin ASoC updates. Please take a look. Thanks a lot -Bryan

4 17