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

[alsa-devel] AC97 on S3C6410
by Marco Sinigaglia 13 Jul '11

13 Jul '11

Hi All, I am still trying to implement the AC97, on S3C6410, using the WM9714. I have done some big step forward but I am now hitting another issue. The kernel can see the WM9714: <6>ALSA device list: <6> #0: SMDK (WM9713) Anyway, after that, i cannot see anymore activity on the AC97 bus. I got, indeed, these errors: <3>s3c-ac97: req addr = 12, rep addr = 00 [...] <3>s3c-ac97: req addr = 12, rep addr = 00 When I try to play something, i got this (I enabled the DEBUG on dma.c): <7>asoc: AC97 HiFi <-> s3c-ac97 info: <7>asoc: rate mask 0xd6 <7>asoc: min ch 2 max ch 2 <7>asoc: min rate 8000 max rate 48000 <7>dma22: s3c2410_request_dma: client=AC97 PCMOut, dev=(null) <7>DMA8: 00000000->00000000 L 00000000 C 00000000,00000000 S 00000000 <7>s3c2410_dma_request: channel initialised, c06779c8 <7>s3c2410_dma_devconfig: channel 22, source 1, dev 7f001018, chan c06779c8 <7>s3c2410_dma_devconfig: peripheral 6 <7>s3c2410_dma_devconfig: config 0000c980 <7>DMA8: 00000000->00000000 L 00000000 C 00000000,00000000 S 0000c980 <7>s3c64xx_dma_flush: flushing channel <7>s3c2410_dma_enqueue: buff c9dcfac0, dp 5e740000 lli (ffcd6000, 57241000) 8192 <7>enquing onto empty channel <7>s3c64xx_lli_to_regs: LLI ffcd6000 => regs <7>LLI[ffcd6000] 5e740000->7f001018, NL 00000000 C 96480000,00000800 <7>LLI[ffcd6000] 5e740000->7f001018, NL 00000000 C 96480000,00000800 <7>DMA8: 5e740000->7f001018 L 00000000 C 96480000,00000000 S 0000c980 <7>DMA8: buffs next c9dcfac0, curr c9dcfac0, end c9dcfac0 <7>s3c2410_dma_enqueue: buff c9dcfa60, dp 5e742000 lli (ffcd6020, 57241020) 8192 <7>enquing onto channel <7>LLI[ffcd6000] 5e740000->7f001018, NL 57241020 C 96480000,00000800 <7>LLI[ffcd6020] 5e742000->7f001018, NL 57241000 C 96480000,00000800 <7>DMA8: 5e740000->7f001018 L 57241020 C 96480000,00000000 S 0000c980 <7>DMA8: buffs next c9dcfa60, curr c9dcfac0, end c9dcfa60 <7>s3c2410_dma_enqueue: buff c9dcfa40, dp 5e744000 lli (ffcd6040, 57241040) 8192 <7>enquing onto channel <7>LLI[ffcd6020] 5e742000->7f001018, NL 57241040 C 96480000,00000800 <7>LLI[ffcd6040] 5e744000->7f001018, NL 57241000 C 96480000,00000800 <7>DMA8: 5e740000->7f001018 L 57241020 C 96480000,00000000 S 0000c980 <7>DMA8: buffs next c9dcfa60, curr c9dcfac0, end c9dcfa40 <7>s3c2410_dma_enqueue: buff c9dcfa20, dp 5e746000 lli (ffcd6060, 57241060) 8192 <7>enquing onto channel <7>LLI[ffcd6040] 5e744000->7f001018, NL 57241060 C 96480000,00000800 <7>LLI[ffcd6060] 5e746000->7f001018, NL 57241000 C 96480000,00000800 <7>DMA8: 5e740000->7f001018 L 57241020 C 96480000,00000000 S 0000c980 <7>DMA8: buffs next c9dcfa60, curr c9dcfac0, end c9dcfa20 <7>s3c2410_dma_enqueue: buff c9dcfa00, dp 5e748000 lli (ffcd6080, 57241080) 8192 <7>enquing onto channel <7>LLI[ffcd6060] 5e746000->7f001018, NL 57241080 C 96480000,00000800 <7>LLI[ffcd6080] 5e748000->7f001018, NL 57241000 C 96480000,00000800 <7>DMA8: 5e740000->7f001018 L 57241020 C 96480000,00000000 S 0000c980 <7>DMA8: buffs next c9dcfa60, curr c9dcfac0, end c9dcfa00 <7>s3c2410_dma_enqueue: buff c9dcf9e0, dp 5e74a000 lli (ffcd60a0, 572410a0) 8192 <7>enquing onto channel <7>LLI[ffcd6080] 5e748000->7f001018, NL 572410a0 C 96480000,00000800 <7>LLI[ffcd60a0] 5e74a000->7f001018, NL 57241000 C 96480000,00000800 <7>DMA8: 5e740000->7f001018 L 57241020 C 96480000,00000000 S 0000c980 <7>DMA8: buffs next c9dcfa60, curr c9dcfac0, end c9dcf9e0 <7>s3c2410_dma_enqueue: buff c9dcf9c0, dp 5e74c000 lli (ffcd60c0, 572410c0) 8192 <7>enquing onto channel <7>LLI[ffcd60a0] 5e74a000->7f001018, NL 572410c0 C 96480000,00000800 <7>LLI[ffcd60c0] 5e74c000->7f001018, NL 57241000 C 96480000,00000800 <7>DMA8: 5e740000->7f001018 L 57241020 C 96480000,00000000 S 0000c980 <7>DMA8: buffs next c9dcfa60, curr c9dcfac0, end c9dcf9c0 <7>s3c2410_dma_enqueue: buff c9dcf9a0, dp 5e74e000 lli (ffcd60e0, 572410e0) 8192 <7>enquing onto channel <7>LLI[ffcd60c0] 5e74c000->7f001018, NL 572410e0 C 96480000,00000800 <7>LLI[ffcd60e0] 5e74e000->7f001018, NL 57241000 C 96480000,00000800 <7>DMA8: 5e740000->7f001018 L 57241020 C 96480000,00000000 S 0000c980 <7>DMA8: buffs next c9dcfa60, curr c9dcfac0, end c9dcf9a0 <7>s3c2410_dma_enqueue: buff c9dcf980, dp 5e750000 lli (ffcd6100, 57241100) 8192 <7>enquing onto channel <7>LLI[ffcd60e0] 5e74e000->7f001018, NL 57241100 C 96480000,00000800 <7>LLI[ffcd6100] 5e750000->7f001018, NL 57241000 C 96480000,00000800 <7>DMA8: 5e740000->7f001018 L 57241020 C 96480000,00000000 S 0000c980 <7>DMA8: buffs next c9dcfa60, curr c9dcfac0, end c9dcf980 <7>s3c2410_dma_enqueue: buff c9dcf960, dp 5e752000 lli (ffcd6120, 57241120) 8192 <7>enquing onto channel <7>LLI[ffcd6100] 5e750000->7f001018, NL 57241120 C 96480000,00000800 <7>LLI[ffcd6120] 5e752000->7f001018, NL 57241000 C 96480000,00000800 <7>DMA8: 5e740000->7f001018 L 57241020 C 96480000,00000000 S 0000c980 <7>DMA8: buffs next c9dcfa60, curr c9dcfac0, end c9dcf960 <7>s3c2410_dma_enqueue: buff c7242940, dp 5e754000 lli (ffcd6140, 57241140) 8192 <7>enquing onto channel <7>LLI[ffcd6120] 5e752000->7f001018, NL 57241140 C 96480000,00000800 <7>LLI[ffcd6140] 5e754000->7f001018, NL 57241000 C 96480000,00000800 <7>DMA8: 5e740000->7f001018 L 57241020 C 96480000,00000000 S 0000c980 <7>DMA8: buffs next c9dcfa60, curr c9dcfac0, end c7242940 <7>DMA8: 5e740000->7f001018 L 57241020 C 96480000,00000000 S 0000c980 <3> clearing interrupts <7>s3c64xx_dma_start: clearing interrupts <7>s3c64xx_dma_start: starting channel <7>s3c64xx_dma_start: writing config 0000c981 <7>ALSA sound/core/pcm_lib.c:1755: playback write error (DMA or IRQ trouble?) <7>ALSA sound/core/pcm_lib.c:1755: playback write error (DMA or IRQ trouble?) <7>s3c64xx_dma_stop: stopping channel <7>DMA8: 5e740010->7f001018 L 57241020 C 96480000,00000800 S 0002c981 I have the feeling that, for some reasons, the DMA is not doing its job. I have added the following line on dma.c but it does not fix the error: s3c64xx_dma_init1(8, DMACH_AC97_PCMOUT, IRQ_DMA1, 0x75100000); Can someone, please, give me some feedback? I am using kernel 2.6.35 and the head of Android. Cheers Marco Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

1 0

[alsa-devel] [PATCH 1/5] ALSA: snd-usb: don't fail hard if mixer creation fails
by Daniel Mack 13 Jul '11

13 Jul '11

There are cards that the mixer code fails to create controls for, and currently, the whole sound device creation fails in such cases. This patch changes the code so that it just spits out warnings and continues looking at other functions of the descriptor set which might work just fine. The worst thing that can happen now is that people see soundcards that don't have all funcions supported, but rejecting the whole device is not any better. Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- sound/usb/card.c | 5 ++--- sound/usb/mixer.c | 9 ++++++--- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/sound/usb/card.c b/sound/usb/card.c index 220c616..8990b49 100644 --- a/sound/usb/card.c +++ b/sound/usb/card.c @@ -512,9 +512,8 @@ static void *snd_usb_audio_probe(struct usb_device *dev, if (err > 0) { /* create normal USB audio interfaces */ if (snd_usb_create_streams(chip, ifnum) < 0 || - snd_usb_create_mixer(chip, ifnum, ignore_ctl_error) < 0) { - goto __error; - } + snd_usb_create_mixer(chip, ifnum, ignore_ctl_error) < 0) + snd_printk(KERN_WARNING "snd_usb_create_mixer() failed\n"); } /* we are allowed to call snd_card_register() many times */ diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index c22fa76..c43dbea 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -1967,7 +1967,8 @@ static int snd_usb_mixer_controls(struct usb_mixer_interface *mixer) state.oterm.name = desc->iTerminal; err = parse_audio_unit(&state, desc->bSourceID); if (err < 0) - return err; + snd_printk(KERN_WARNING "Unable to parse terminal with bSourceID %d\n", + desc->bSourceID); } else { /* UAC_VERSION_2 */ struct uac2_output_terminal_descriptor *desc = p; @@ -1979,12 +1980,14 @@ static int snd_usb_mixer_controls(struct usb_mixer_interface *mixer) state.oterm.name = desc->iTerminal; err = parse_audio_unit(&state, desc->bSourceID); if (err < 0) - return err; + snd_printk(KERN_WARNING "Unable to parse terminal with bSourceID %d\n", + desc->bSourceID); /* for UAC2, use the same approach to also add the clock selectors */ err = parse_audio_unit(&state, desc->bCSourceID); if (err < 0) - return err; + snd_printk(KERN_WARNING "Unable to parse clock terminal with bCSourceID %d\n", + desc->bCSourceID); } } -- 1.7.5.4

2 7

Re: [alsa-devel] Drop 2.2/2.4 kernel support in alsa-driver
by Tom Watson 13 Jul '11

13 Jul '11

Jaroslav Kysela <perex(a)perex.cz> Wrote: >Date 12.7.2011 18:12, Takashi Iwai wrote: >> [This is resent since I haven't seen my original post due to >> alsa-project.org site down. If you have already read it, please >> disregard.] >> >> Hi, >> >> in upcoming 3.0-kernel era, I believe it's high time to drop the >> support of old 2.2/2.4 kernels in alsa-driver external builds. >> Recently I changed some PCI drivers to use KBUILD_MODNAME, and this >> isn't supported by the old kernels, i.e. it's currently broken for >> these kernels. But I have no more gut to patch alsa-driver/* codes. >> >> Is there any active user of such kernels with the latest alsa-driver? >> If not, let's clean up the whole things. >> 2.2/2.4 kernel users can still use 1.0.24, and we can release 1.0.24.x >> series if really needed. > > I agree. I believe that these kernels are using minimum users now. > Almost all embeded devices are using 2.6 kernels, too. > > Jaroslav While this IS a good idea, I would suggest that ALSA take a cue from the kernel people and bump the version up a major number. It would make lots of sense that ALSA 2.0 go with kernel version 3.0. An alternative might be to skip version 2.0 and go to ALSA 3.0 to match kernel version 3.0. This won't change any code, but it would be a little clearer. That way when you drop support for older kernels, you can easily tell what version should be used. "Just a suggestion" worth the paper it is written on. -- Tom Watson tsw(a)johana.com

1 0

[alsa-devel] [PATCH] ASoC: Don't warn on low WM8994/58 AIFnCLKs
by Mark Brown 13 Jul '11

13 Jul '11

We can have valid but very low clocks in accessory detection modes. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8994.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index e5f3f50..5af1535 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -195,10 +195,6 @@ static int configure_aif_clock(struct snd_soc_codec *codec, int aif) aif + 1, rate); } - if (rate && rate < 3000000) - dev_warn(codec->dev, "AIF%dCLK is %dHz, should be >=3MHz for optimal performance\n", - aif + 1, rate); - wm8994->aifclk[aif] = rate; snd_soc_update_bits(codec, WM8994_AIF1_CLOCKING_1 + offset, -- 1.7.5.4

1 0

[alsa-devel] [PATCH 00/10] ARM: mxs: add audio support
by Dong Aisheng 13 Jul '11

13 Jul '11

This patch series is to add audio support based on saif for mxs platform. The driver only supports playback currently. For capturing, due to hardware limitation that we have to use two saif instances to implement full duplex (playback & recording), we need to figure out a good design to fit in ASoC as the following work. In addition, we simply just support master mode since saif tx can only work in master mode due to hw limitation(rx can work in both master & slave mode). Dong Aisheng (10): ASoc: mxs: add mxs-pcm driver ASoc: mxs: add mxs-saif driver ASoc: mxs: add mxs-sgtl5000 machine driver ASoc: mxs: add asoc configuration files ARM: mxs: add saif clock ARM: mxs: add saif device ARM: mxs: add sgtl5000 i2c device ARM: mxs: add mxs-sgtl5000 device ARM: mxs: correct the using of frac div for saif ARM: mxs-dma: include <linux/dmaengine.h> arch/arm/mach-mxs/Kconfig | 1 + arch/arm/mach-mxs/clock-mx28.c | 8 +- arch/arm/mach-mxs/devices-mx28.h | 7 + arch/arm/mach-mxs/devices/Kconfig | 3 + arch/arm/mach-mxs/devices/Makefile | 1 + arch/arm/mach-mxs/devices/platform-mxs-saif.c | 60 +++ arch/arm/mach-mxs/include/mach/audio.h | 18 + arch/arm/mach-mxs/include/mach/devices-common.h | 12 + arch/arm/mach-mxs/include/mach/dma.h | 2 + arch/arm/mach-mxs/mach-mx28evk.c | 39 ++ sound/soc/Kconfig | 1 + sound/soc/Makefile | 1 + sound/soc/mxs/Kconfig | 20 + sound/soc/mxs/Makefile | 10 + sound/soc/mxs/mxs-pcm.c | 377 ++++++++++++++++ sound/soc/mxs/mxs-pcm.h | 43 ++ sound/soc/mxs/mxs-saif.c | 523 +++++++++++++++++++++++ sound/soc/mxs/mxs-saif.h | 132 ++++++ sound/soc/mxs/mxs-sgtl5000.c | 181 ++++++++ 19 files changed, 1437 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-mxs/devices/platform-mxs-saif.c create mode 100644 arch/arm/mach-mxs/include/mach/audio.h create mode 100644 sound/soc/mxs/Kconfig create mode 100644 sound/soc/mxs/Makefile create mode 100644 sound/soc/mxs/mxs-pcm.c create mode 100644 sound/soc/mxs/mxs-pcm.h create mode 100644 sound/soc/mxs/mxs-saif.c create mode 100644 sound/soc/mxs/mxs-saif.h create mode 100644 sound/soc/mxs/mxs-sgtl5000.c

6 29

Re: [alsa-devel] Bug#631963: linux-image-3.0.0-rc4-686-pae: no sound out the rear plugs
by Ben Hutchings 13 Jul '11

13 Jul '11

On Fri, 2011-07-01 at 23:41 +0200, Toni Mueller wrote: > Hi Ben, > > On Fri, 01.07.2011 at 22:22:01 +0100, Ben Hutchings <ben(a)decadent.org.uk> wrote: > > On Fri, Jul 01, 2011 at 11:06:56PM +0200, Toni Mueller wrote: > > > On Thu, 30.06.2011 at 07:59:19 +0200, Takashi Iwai <tiwai(a)suse.de> wrote: > > > > I guess this must be the new feature, "Auto-Mute Mode". > > > it turns out that you're right - I just had the opportunity to verify > > > that. > > > > Can we consider this closed, then? Or should that feature be > > disabled by default? > > good question - I didn't see it. Don't know offhand where to easily > find it: Upstream's changelog isn't included in the package, so... > > I'd be fine either way, but think that the feature deserves more > advertising, or, alternatively (?), being disabled by default, to > prevent bogus bug reports like mine. What do you think of this? Ben. -- Ben Hutchings All extremists should be taken out and shot.

1 0

[alsa-devel] [PATCH 0/3] OMAP4/ASoC: New McPDM driver
by Peter Ujfalusi 13 Jul '11

13 Jul '11

Hello, The following series replaces the current driver for McPDM port. The current McPDM driver design is not suitable to support both the ABE and Legacy DMA operating modes. Therefore remove most of the old driver (and mcpdm.c) and replace it with a re-designed driver to support both Legacy and ABE modes of operation. As part of the work the McPDM driver has been converted to omap device, and from now on it is going to use hwmod. Patch 2, and 3 was originated from Jorge, and Margarita, but their @ti.com mail address does not work anymore, so I took those two patch under my name, but added them as s-o-b without e-mail address. For the McPDM driver replacement, I forced git to create a complete rewrite patch to help with the review. Regards, Peter --- Misael Lopez Cruz (1): ASoC: omap-mcpdm: Replace legacy driver Peter Ujfalusi (2): OMAP: McPDM: Convert McPDM device to omap_device OMAP4: hwmod: enable mcpdm hwmod device. arch/arm/mach-omap2/devices.c | 33 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +- arch/arm/plat-omap/devices.c | 36 -- sound/soc/omap/Makefile | 2 +- sound/soc/omap/mcpdm.c | 470 ---------------- sound/soc/omap/mcpdm.h | 153 ----- sound/soc/omap/omap-mcpdm.c | 828 +++++++++++++++++++--------- sound/soc/omap/omap-mcpdm.h | 109 ++++ sound/soc/omap/sdp4430.c | 4 +- 9 files changed, 702 insertions(+), 935 deletions(-) delete mode 100644 sound/soc/omap/mcpdm.c delete mode 100644 sound/soc/omap/mcpdm.h rewrite sound/soc/omap/omap-mcpdm.c (42%) create mode 100644 sound/soc/omap/omap-mcpdm.h -- 1.7.6

3 15

Re: [alsa-devel] Sound BoF in LinuxCon Europe?
by David Henningsson 13 Jul '11

13 Jul '11

On 2011-07-08 12:36, Takashi Iwai wrote: > Hi, > > just wondering how about holding a sound-BoF in LinuxCon Europe in > October? > > I know ELCE will be held at the very same time, so it may need the > adjustment of schedule. But in general what do you think? > > I know some guys will attend LPC in September, too. If the topic is > redundant again after one month, it's fine, no much need for that. > OTOH, it's a conference in Europe, so people there may have more > chance to attend (like me :-) > > An alternative is a workshop in KS2011 day 1, but I think KS suits > better for more broader topics, e.g. the discussions on the media- > notification support or the jack implementation like a thread in the > last month. I like the initiative and I'm all for having a sound BoF! Unfortunately, the timing is bad. Ubuntu's biggest event, the Ubuntu Developer Summit, is in Florida 24-28 October and my attendance is required... -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

2 2

[alsa-devel] Drop 2.2/2.4 kernel support in alsa-driver build?
by Takashi Iwai 12 Jul '11

12 Jul '11

[This is resent since I haven't seen my original post due to alsa-project.org site down. If you have already read it, please disregard.] Hi, in upcoming 3.0-kernel era, I believe it's high time to drop the support of old 2.2/2.4 kernels in alsa-driver external builds. Recently I changed some PCI drivers to use KBUILD_MODNAME, and this isn't supported by the old kernels, i.e. it's currently broken for these kernels. But I have no more gut to patch alsa-driver/* codes. Is there any active user of such kernels with the latest alsa-driver? If not, let's clean up the whole things. 2.2/2.4 kernel users can still use 1.0.24, and we can release 1.0.24.x series if really needed. thanks, Takashi

3 2

[alsa-devel] Playback through softvol locks mixer
by Martin Bailey 12 Jul '11

12 Jul '11

Hi, I setup an ALSA plugin chain to allow individual volume-controlled mono access to a 4-channel sound card. I'm including the asound.conf only for the first channel. Whenever I open "plug:playback1" and play audio, it appears the "playback1" softvol mixer goes locked and any attempt to change its value within the same or another application results in "Operation not permitted". Can you think of something I might be missing? pcm.playback8k { type dmix ipc_key 666 ipc_perm 0666 slave { pcm "hw:0" format S16_LE channels 4 rate 8000 buffer_size 8192 period_size 1024 } bindings.0 0 bindings.1 1 bindings.2 2 bindings.3 3 } pcm.playback8k1 { type route slave { pcm "playback8k" format S16_LE channels 4 } ttable.0.0 1 } pcm.playback1 { type softvol slave.pcm "playback8k1" control.name "playback1" control.card 0 control.count 1 min_dB -51.0 max_dB 0.0 resolution 256 } ctl.playback1 { type hw card 0 }

1 0