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

[alsa-devel] pulseaudio module-udev-detect failure on 2.6.34-rc1
by Wu Fengguang 31 Mar '10

31 Mar '10

Greetings, Pulseaudio can no longer detect sound cards on kernel 2.6.34-rc1. Note that 2.6.33 is OK. I noticed that the related sysfs directories/files changed. Note that the card0/ directory is gone in new kernel: 2.6.33 wfg@hp ~% ll /sys/class/sound total 0 lrwxrwxrwx 1 root root 0 2010-03-31 12:23 timer -> ../../devices/virtual/sound/timer lrwxrwxrwx 1 root root 0 2010-03-31 12:23 pcmC0D1p -> ../../devices/pci0000:00/0000:00:1b.0/sound/card0/pcmC0D1p lrwxrwxrwx 1 root root 0 2010-03-31 12:23 pcmC0D0p -> ../../devices/pci0000:00/0000:00:1b.0/sound/card0/pcmC0D0p lrwxrwxrwx 1 root root 0 2010-03-31 12:23 pcmC0D0c -> ../../devices/pci0000:00/0000:00:1b.0/sound/card0/pcmC0D0c lrwxrwxrwx 1 root root 0 2010-03-31 12:23 mixer5 -> ../../devices/platform/thinkpad_acpi/sound/card5/mixer5 lrwxrwxrwx 1 root root 0 2010-03-31 12:23 mixer -> ../../devices/pci0000:00/0000:00:1b.0/sound/card0/mixer lrwxrwxrwx 1 root root 0 2010-03-31 12:23 hwC0D0 -> ../../devices/pci0000:00/0000:00:1b.0/sound/card0/hwC0D0 lrwxrwxrwx 1 root root 0 2010-03-31 12:23 dsp -> ../../devices/pci0000:00/0000:00:1b.0/sound/card0/dsp lrwxrwxrwx 1 root root 0 2010-03-31 12:23 controlC5 -> ../../devices/platform/thinkpad_acpi/sound/card5/controlC5 lrwxrwxrwx 1 root root 0 2010-03-31 12:23 controlC0 -> ../../devices/pci0000:00/0000:00:1b.0/sound/card0/controlC0 lrwxrwxrwx 1 root root 0 2010-03-31 12:23 card5 -> ../../devices/platform/thinkpad_acpi/sound/card5 lrwxrwxrwx 1 root root 0 2010-03-31 12:23 card0 -> ../../devices/pci0000:00/0000:00:1b.0/sound/card0 lrwxrwxrwx 1 root root 0 2010-03-31 12:23 audio -> ../../devices/pci0000:00/0000:00:1b.0/sound/card0/audio lrwxrwxrwx 1 root root 0 2010-03-31 12:23 adsp -> ../../devices/pci0000:00/0000:00:1b.0/sound/card0/adsp 2.6.34-rc1 wfg@hp ~% ll /sys/class/sound total 0 drwxr-xr-x 3 root root 0 2010-03-31 19:27 timer drwxr-xr-x 3 root root 0 2010-03-31 19:27 pcmC0D7p drwxr-xr-x 3 root root 0 2010-03-31 19:27 pcmC0D3p drwxr-xr-x 3 root root 0 2010-03-31 19:27 pcmC0D0p drwxr-xr-x 3 root root 0 2010-03-31 19:27 pcmC0D0c drwxr-xr-x 3 root root 0 2010-03-31 19:27 hwC0D3 drwxr-xr-x 3 root root 0 2010-03-31 19:27 hwC0D0 drwxr-xr-x 3 root root 0 2010-03-31 19:27 controlC0 Any ideas? Thanks, Fengguang

2 2

[alsa-devel] [PATCH] ALSA: hda: Fix 0 dB offset for Lenovo Thinkpad models using AD1981
by Daniel Chen 31 Mar '10

31 Mar '10

Hi, Attached is a patch against sound-2.6 master HEAD (applicable to 2.6.32.y and 2.6.33.y) that clamps the 0 dB offset accordingly. Best, -Dan

2 1

Re: [alsa-devel] mx31 snd and mc13783 codec status
by Mark Brown 31 Mar '10

31 Mar '10

On Tue, Mar 30, 2010 at 06:23:18PM +0200, Valentin Longchamp wrote: > I have quickly hacked something based on what you had done for > pcm037 with the MC13783 codec in some of your first sound patches. I > know that this is not ready for mainline and I'm still struggling to > debug my code, but I would like to have results quite soon so that > my colleague could see what sounds (especially regarding to the > volume) our system is capable to produce. If you're struggling to find time to do full support for the CODEC a good technique is often to get just very basic fixed function support (say just DAC to headphone support) implemented and merged, then go back and implement I'd also suggest looking at the current Freescale BSPs - obviously this device is used on a lot of Freescale reference boards and I believe there's a reasonably mainlineish driver in the BSPs they have for current devices.

2 1

Re: [alsa-devel] mx31 snd and mc13783 codec status
by Sascha Hauer 31 Mar '10

31 Mar '10

Hi Valentin, On Tue, Mar 30, 2010 at 06:23:18PM +0200, Valentin Longchamp wrote: > Hi Sascha, > > For one of our experiments where our robots need to produce sound, I > would need a sound driver for mx31moboard platform. > > I have quickly hacked something based on what you had done for pcm037 > with the MC13783 codec in some of your first sound patches. I know that > this is not ready for mainline and I'm still struggling to debug my > code, but I would like to have results quite soon so that my colleague > could see what sounds (especially regarding to the volume) our system is > capable to produce. > > I would like to know if by any chance you have some updates on this code > ? Find the latest version of my code here: The following changes since commit 01e77706cdde7c0b47e5ca1f4284a795504c7c40: Linus Torvalds (1): Merge branch 'for-linus' of git://gitorious.org/linux-omap-dss2/linux are available in the git repository at: git://git.pengutronix.de/git/sha/linux-2.6.git mc13783 Sascha Hauer (3): add a mc13783 codec driver add phycore-mc13783 sound support pcm038: add sound support arch/arm/mach-mx2/mach-pcm038.c | 23 ++- sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/mc13783.c | 727 +++++++++++++++++++++++++++++++++++++++ sound/soc/codecs/mc13783.h | 32 ++ sound/soc/imx/Kconfig | 9 + sound/soc/imx/Makefile | 3 + sound/soc/imx/phycore-mc13783.c | 160 +++++++++ 8 files changed, 959 insertions(+), 1 deletions(-) create mode 100644 sound/soc/codecs/mc13783.c create mode 100644 sound/soc/codecs/mc13783.h create mode 100644 sound/soc/imx/phycore-mc13783.c > And do you know if your initial mc13783 codec support coupled with > mx31 had some limitations ? Our setup is quite straightforward, we have > direct connection from the mx31 to the mc13783 on a single SSI. Our board uses both SSI channels of the MC13783 which we then mux into one channel in the DAM unit. I don't know how this affects you. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

1 0

[alsa-devel] ASoC updates for 2.6.35
by Mark Brown 30 Mar '10

30 Mar '10

The following changes since commit 923a00427a141a6d1c83f1b151221a2458b2de8d: Tejun Heo (1): ASoC: update gfp/slab.h includes are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.35 Barry Song (1): ASoC: ad193x: move codec register/unregister to bus probe/remove Dan Carpenter (1): ASoC: wm8994: playback => capture Graham Gower (1): ASoC: Fix passing platform_data to ac97 bus users and fix a leak Kuninori Morimoto (4): ASoC: fsi: ensures process inside master lock ASoC: fsi: IRQ related process had be united ASoC: fsi: Add FIFO size calculate ASoC: fsi: Add FSI2 device support Mark Brown (2): Merge branch 'topic/asoc' of git://git.kernel.org/.../tiwai/sound-2.6 into for-2.6.35 Merge branch 'for-2.6.34' into for-2.6.35 sound/soc/codecs/ac97.c | 15 ++-- sound/soc/codecs/ad193x.c | 102 ++++++++++-------------- sound/soc/codecs/wm8994.c | 2 +- sound/soc/sh/Kconfig | 3 +- sound/soc/sh/fsi.c | 191 ++++++++++++++++++++++++++++++++------------- sound/soc/soc-core.c | 3 +- 6 files changed, 192 insertions(+), 124 deletions(-)

2 1

[alsa-devel] ASoC updates for 2.6.34
by Mark Brown 30 Mar '10

30 Mar '10

The following changes since commit 3cc4e53f86dab635166929bfa47cc68d59b28c26: Mark Brown (1): ASoC: Remove BROKEN from i.MX audio after dependencies merged are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.34 A couple of fairly straightforward bug fixes. The ac97 patch is mildly invasive but it tested OK for me (and should be very obvious if it fails). Dan Carpenter (1): ASoC: wm8994: playback => capture Graham Gower (1): ASoC: Fix passing platform_data to ac97 bus users and fix a leak sound/soc/codecs/ac97.c | 15 +++++++++------ sound/soc/codecs/wm8994.c | 2 +- sound/soc/soc-core.c | 3 ++- 3 files changed, 12 insertions(+), 8 deletions(-)

2 1

[alsa-devel] digiface vs. multiface vs. jack vs. other cards
by Fernando Lopez-Lezcano 30 Mar '10

30 Mar '10

At CCRMA we have several studios with linux computers in them (in addition to computers sprinkled throughout the building). Some of the studios have digiface interfaces, some multiface. All of them are connected to the sound system or mixer digitally through adat lightpipes. Workstations have Delta 66 or Gina3G soundcards. It would be nice for a user to be able to play, say, a stereo Ardour session in any of them without any changes to the session or routing. The digifaces send channels 1-24 out the adat ports. The multifaces on the other hand send 9-16 on the adat port. Deltas and Ginas send out stuff on channels 1-4 or 1-6. You can see the multiface interfaces are a problem. To get sound out of them you have to send on channels 9-16 which is different from _all_ others! I tried several workarounds without much success: a) fix this at the alsa level. Should be the way to go, right? Create an /etc/asound.conf that uses ttable to translate channels for the multifaces so that the digital out is actually sent through channels 1-8 (and create the same name plug interface in all other computers that does nothing so that the user can set that name as the default in qjackctl and will get the same behavior in all computers). Works, but not quite. When I try to use that "fake" plug interface with jack2 I get a warning that I'm using a plug interface (sort of fair) and jack only opens it with _2_ i/o channels (even though the ttable is 18 channels wide!). If I _force_ input and output channels in jack to 18 it does work fine. But now it will _not_ work on other computers that have less (or more) than 18 channels. Argh. b) fix it in hdspmixer. Well, it turns out that hdspmixer does not read the default matrix gains from a file so I can't really override the default. AFAICT the gains are calculated algorithmically in the code and there is no command line option to load presets from a file. Or I could write a small script that will set the right gains for 1-8 to go out through 9-16 but if a user starts hdspmixer that gets undone with no warning. And, of course: c) give up and connect an 8 channel analog snake to the analog outputs of the multifaces and do away with a digital connection to the mixer... Anyone has any other suggestions?? This should be easy to fix, right? :-) -- Fernando

2 1

[alsa-devel] [PATCH] ad193x: move codec register/unregister to bus probe/remove
by Barry Song 29 Mar '10

29 Mar '10

The way i've factored out the bus probe and removal functions so that there's no code in the individual I2C and SPI functions means that the register() and unregister() functions could just be squashed into the bus_probe() and bus_remove() functions. Signed-off-by: Barry Song <21cnbao(a)gmail.com> --- sound/soc/codecs/ad193x.c | 102 +++++++++++++++++++------------------------- 1 files changed, 44 insertions(+), 58 deletions(-) diff --git a/sound/soc/codecs/ad193x.c b/sound/soc/codecs/ad193x.c index d034464..e6fe8ac 100644 --- a/sound/soc/codecs/ad193x.c +++ b/sound/soc/codecs/ad193x.c @@ -34,8 +34,6 @@ static const u8 ad193x_reg[AD193X_NUM_REGS] = { static struct snd_soc_codec *ad193x_codec; struct snd_soc_codec_device soc_codec_dev_ad193x; -static int ad193x_register(struct ad193x_priv *ad193x, int bus_type); -static void ad193x_unregister(struct ad193x_priv *ad193x); /* * AD193X volume/mute/de-emphasis etc. controls @@ -289,69 +287,23 @@ static int ad193x_bus_probe(struct device *dev, void *ctrl_data, int bus_type) { struct snd_soc_codec *codec; struct ad193x_priv *ad193x; + int ret; + + if (ad193x_codec) { + dev_err(dev, "Another ad193x is registered\n"); + return -EINVAL; + } ad193x = kzalloc(sizeof(struct ad193x_priv), GFP_KERNEL); if (ad193x == NULL) return -ENOMEM; - codec = &ad193x->codec; - codec->control_data = ctrl_data; - codec->dev = dev; - dev_set_drvdata(dev, ad193x); - return ad193x_register(ad193x, bus_type); -} - -static int ad193x_bus_remove(struct device *dev) -{ - struct ad193x_priv *ad193x = dev_get_drvdata(dev); - - ad193x_unregister(ad193x); - return 0; -} - -static struct snd_soc_dai_ops ad193x_dai_ops = { - .hw_params = ad193x_hw_params, - .digital_mute = ad193x_mute, - .set_tdm_slot = ad193x_set_tdm_slot, - .set_fmt = ad193x_set_dai_fmt, -}; - -/* codec DAI instance */ -struct snd_soc_dai ad193x_dai = { - .name = "AD193X", - .playback = { - .stream_name = "Playback", - .channels_min = 2, - .channels_max = 8, - .rates = SNDRV_PCM_RATE_48000, - .formats = SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S16_LE | - SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S24_LE, - }, - .capture = { - .stream_name = "Capture", - .channels_min = 2, - .channels_max = 4, - .rates = SNDRV_PCM_RATE_48000, - .formats = SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S16_LE | - SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S24_LE, - }, - .ops = &ad193x_dai_ops, -}; -EXPORT_SYMBOL_GPL(ad193x_dai); - -static int ad193x_register(struct ad193x_priv *ad193x, int bus_type) -{ - int ret; - struct snd_soc_codec *codec = &ad193x->codec; - - if (ad193x_codec) { - dev_err(codec->dev, "Another ad193x is registered\n"); - return -EINVAL; - } - + codec = &ad193x->codec; mutex_init(&codec->mutex); + codec->control_data = ctrl_data; + codec->dev = dev; codec->private_data = ad193x; codec->reg_cache = ad193x->reg_cache; codec->reg_cache_size = AD193X_NUM_REGS; @@ -412,14 +364,48 @@ static int ad193x_register(struct ad193x_priv *ad193x, int bus_type) return 0; } -static void ad193x_unregister(struct ad193x_priv *ad193x) +static int ad193x_bus_remove(struct device *dev) { + struct ad193x_priv *ad193x = dev_get_drvdata(dev); + snd_soc_unregister_dai(&ad193x_dai); snd_soc_unregister_codec(&ad193x->codec); kfree(ad193x); ad193x_codec = NULL; + + return 0; } +static struct snd_soc_dai_ops ad193x_dai_ops = { + .hw_params = ad193x_hw_params, + .digital_mute = ad193x_mute, + .set_tdm_slot = ad193x_set_tdm_slot, + .set_fmt = ad193x_set_dai_fmt, +}; + +/* codec DAI instance */ +struct snd_soc_dai ad193x_dai = { + .name = "AD193X", + .playback = { + .stream_name = "Playback", + .channels_min = 2, + .channels_max = 8, + .rates = SNDRV_PCM_RATE_48000, + .formats = SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S16_LE | + SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S24_LE, + }, + .capture = { + .stream_name = "Capture", + .channels_min = 2, + .channels_max = 4, + .rates = SNDRV_PCM_RATE_48000, + .formats = SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S16_LE | + SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S24_LE, + }, + .ops = &ad193x_dai_ops, +}; +EXPORT_SYMBOL_GPL(ad193x_dai); + static int ad193x_probe(struct platform_device *pdev) { struct snd_soc_device *socdev = platform_get_drvdata(pdev); -- 1.5.6.3

3 2

[alsa-devel] Volume levels with Geode LX/CS5536
by Valentin 29 Mar '10

29 Mar '10

Hi, the maximum volume level (100%) on my soundcard for the PCM mixer is 12.0dB instead of 0.0dB. Is there a way for me to fix this, or help fixing it? crimsun on freenode/#alsa told me to ask you guys :) My alsa-info.sh output is at http://0au.de/~apo/p/ai.txt Cheers, Valentin

2 1

[alsa-devel] bug in spi and i2c dual buses codecs
by Barry Song 29 Mar '10

29 Mar '10

Hi Mark/Liam, I think there is really a bug in spi and i2c dual buses codecs drivers, for example, for any codec with two buses, if you config kernel like this: SPI MASTER built-in I2C module Codec built-in You will get a link error like this: sound/built-in.o: In function `i2c_add_driver': include/linux/i2c.h:423: undefined reference to `i2c_register_driver' sound/built-in.o: In function `ad193x_modexit': sound/soc/codecs/ad193x.c:537: undefined reference to `i2c_del_driver' make: *** [.tmp_vmlinux1] Error 1 I remember that is also one reason why we have splitted this kind of driver into three parts(codec core, i2c bus, spi bus). In fact, if any bus is compiled as module and code is built-in, link error will be reported. Thanks Barry

3 4