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

[alsa-devel] E-MU 0404 Support
by Kristian Lumme 27 Feb '09

27 Feb '09

Hi! I reported a bug (or what I think is a bug) with the E-MU 0404 USB driver (https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4410) (this probably concerns other E-MU cards as well). Now, the supported soundcards list states that E-MU (or Creative) have supplied ALSA developers with datasheets to help the development of the driver. Well... in my bug report I was referred to this discussion on the ALSA devel list: http://thread.gmane.org/gmane.linux.alsa.devel/56288/focus=56355 If I understand this correctly, people that are offering to help develop the driver can't get in touch with the person who has the datasheets (and there hasn't been any update from him in a long time... or so it seems--sorry if I'm mistaken). Surely, there's some way to make these specifications available to interested developers so the support for the E-MU cards can be improved?

3 3

Re: [alsa-devel] [PATCH] hda_intel: Add the Device IDs for MCP89 and remove IDs of MCP7B to/from hda_intel.c
by Takashi Iwai 27 Feb '09

27 Feb '09

At Fri, 27 Feb 2009 17:03:19 +0800, peerchen wrote: > > Added the Device IDs for MCP89 HD audio controller. > Removed the IDs of MCP7B cause this chipset had been cancelled. > > Signed-off-by: Peer Chen <peerchen(a)gmail.com> Applied now. Thanks! Takashi > --- > --- linux-2.6.29-rc6/sound/pci/hda/hda_intel.c.orig 2009-02-26 08:51:02.000000000 -0500 > +++ linux-2.6.29-rc6/sound/pci/hda/hda_intel.c 2009-02-26 08:51:23.000000000 -0500 > @@ -2442,10 +2442,10 @@ static struct pci_device_id azx_ids[] = > { PCI_DEVICE(0x10de, 0x0ac1), .driver_data = AZX_DRIVER_NVIDIA }, > { PCI_DEVICE(0x10de, 0x0ac2), .driver_data = AZX_DRIVER_NVIDIA }, > { PCI_DEVICE(0x10de, 0x0ac3), .driver_data = AZX_DRIVER_NVIDIA }, > - { PCI_DEVICE(0x10de, 0x0bd4), .driver_data = AZX_DRIVER_NVIDIA }, > - { PCI_DEVICE(0x10de, 0x0bd5), .driver_data = AZX_DRIVER_NVIDIA }, > - { PCI_DEVICE(0x10de, 0x0bd6), .driver_data = AZX_DRIVER_NVIDIA }, > - { PCI_DEVICE(0x10de, 0x0bd7), .driver_data = AZX_DRIVER_NVIDIA }, > + { PCI_DEVICE(0x10de, 0x0d94), .driver_data = AZX_DRIVER_NVIDIA }, > + { PCI_DEVICE(0x10de, 0x0d95), .driver_data = AZX_DRIVER_NVIDIA }, > + { PCI_DEVICE(0x10de, 0x0d96), .driver_data = AZX_DRIVER_NVIDIA }, > + { PCI_DEVICE(0x10de, 0x0d97), .driver_data = AZX_DRIVER_NVIDIA }, > /* Teradici */ > { PCI_DEVICE(0x6549, 0x1200), .driver_data = AZX_DRIVER_TERA }, > /* AMD Generic, PCI class code and Vendor ID for HD Audio */ > - >

1 0

[alsa-devel] ASoC updates for 2.6.30
by Mark Brown 26 Feb '09

26 Feb '09

The following changes since commit ce3bdaa8710c10eec5a6dae67aaf73088d0ced4f: Mark Brown (1): ASoC: Disable WM8731 line bypass by default are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.30 Mark Brown (7): ASoC: Report I/O errors from WM8753 reset ASoC: Only unregister drivers we registered for WM8753 ASoC: Improve WM9713 voice DAC shutdown procedure ASoC: Fix Zylonite voice interface stereo configurations ASoC: Shuffle WM8753 device registration code ASoC: Convert WM8753 to register via normal device probe ASoC: Only write back non-default registers when resuming WM8753 sound/soc/codecs/wm8753.c | 421 +++++++++++++++++------------------- sound/soc/codecs/wm8753.h | 6 - sound/soc/codecs/wm9713.c | 7 +- sound/soc/pxa/zylonite.c | 5 +- sound/soc/s3c24xx/neo1973_wm8753.c | 6 - 5 files changed, 210 insertions(+), 235 deletions(-)

5 14

[alsa-devel] [PATCH 3/3] ASoC: Add headset jack detection for SDP3430 machine driver
by Lopez Cruz, Misael 26 Feb '09

26 Feb '09

Add headset jack detection for SDP3430 boards using SoC jack reporting interface. Headset detection on SDP3430 board is achieved through TWL4030 GPIO_2 pin. Signed-off-by: Misael Lopez Cruz <x0052729(a)ti.com> --- sound/soc/omap/sdp3430.c | 31 ++++++++++++++++++++++++++++++- 1 files changed, 30 insertions(+), 1 deletions(-) diff --git a/sound/soc/omap/sdp3430.c b/sound/soc/omap/sdp3430.c index 7a996d9..7695675 100644 --- a/sound/soc/omap/sdp3430.c +++ b/sound/soc/omap/sdp3430.c @@ -28,6 +28,7 @@ #include <sound/pcm.h> #include <sound/soc.h> #include <sound/soc-dapm.h> +#include <sound/jack.h> #include <asm/mach-types.h> #include <mach/hardware.h> @@ -141,6 +142,18 @@ static int sdp3430_twl4030_init(struct snd_soc_codec *codec) return ret; } +/* Jack detection */ +struct snd_soc_jack *sdp3430_jack; + +struct snd_soc_jack_pin sdp3430_jack_pins[] = { + { + .pin = "Headset Jack", + .mask = SND_JACK_HEADSET, + .invert = 0, + .gpio = (OMAP_MAX_GPIO_LINES + 2), + }, +}; + /* Digital audio interface glue - connects codec <--> CPU */ static struct snd_soc_dai_link sdp3430_dai = { .name = "TWL4030", @@ -191,7 +204,23 @@ static int __init sdp3430_soc_init(void) if (ret) goto err1; - return 0; + /* Jack detection */ + sdp3430_jack = kzalloc(sizeof(struct snd_soc_jack), GFP_KERNEL); + if (!sdp3430_jack) { + printk(KERN_ERR "SDP3430 SoC Jack allocation failed\n"); + return -ENOMEM; + } + + snd_soc_jack_new(&snd_soc_sdp3430, "SDP3430 SoC Jack", + SND_JACK_HEADSET, sdp3430_jack); + if (ret) + return ret; + + ret = snd_soc_jack_add_pins(sdp3430_jack, + ARRAY_SIZE(sdp3430_jack_pins), + sdp3430_jack_pins); + + return ret; err1: printk(KERN_ERR "Unable to add platform device\n"); -- 1.5.4.3

1 0

[alsa-devel] [PATCH 2/3] ASoC: Add DAPM machine widgets to SDP3430 driver
by Lopez Cruz, Misael 26 Feb '09

26 Feb '09

Add DAPM machine domain widgets to SDP3430 machine driver. Current interconection: * Ext Mic: MAINMIC, SUBMIC * Ext Spk: HFL, HFR * Headset Jack: HSMIC, HSOL, HSOR Signed-off-by: Misael Lopez Cruz <x0052729(a)ti.com> --- sound/soc/omap/sdp3430.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 61 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/sdp3430.c b/sound/soc/omap/sdp3430.c index e226fa7..7a996d9 100644 --- a/sound/soc/omap/sdp3430.c +++ b/sound/soc/omap/sdp3430.c @@ -81,12 +81,73 @@ static struct snd_soc_ops sdp3430_ops = { .hw_params = sdp3430_hw_params, }; +/* SDP3430 machine DAPM */ +static const struct snd_soc_dapm_widget sdp3430_twl4030_dapm_widgets[] = { + SND_SOC_DAPM_MIC("Ext Mic", NULL), + SND_SOC_DAPM_SPK("Ext Spk", NULL), + SND_SOC_DAPM_HP("Headset Jack", NULL), +}; + +static const struct snd_soc_dapm_route audio_map[] = { + /* External Mics: MAINMIC, SUBMIC */ + {"MAINMIC", NULL, "Ext Mic"}, + {"SUBMIC", NULL, "Ext Mic"}, + + /* External Speakers: HFL, HFR */ + {"Ext Spk", NULL, "HFL"}, + {"Ext Spk", NULL, "HFR"}, + + /* Headset: HSMIC, HSOL, HSOR */ + {"Headset Jack", NULL, "HSOL"}, + {"Headset Jack", NULL, "HSOR"}, + {"HSMIC", NULL, "Headset Jack"}, +}; + +static int sdp3430_twl4030_init(struct snd_soc_codec *codec) +{ + int ret; + + /* SDP3430 connected pins */ + snd_soc_dapm_enable_pin(codec, "Ext Mic"); + snd_soc_dapm_enable_pin(codec, "Ext Spk"); + snd_soc_dapm_enable_pin(codec, "Headset Jack"); + + /* TWL4030 not connected pins */ + snd_soc_dapm_nc_pin(codec, "AUXL"); + snd_soc_dapm_nc_pin(codec, "AUXR"); + snd_soc_dapm_nc_pin(codec, "CARKITMIC"); + snd_soc_dapm_nc_pin(codec, "DIGIMIC0"); + snd_soc_dapm_nc_pin(codec, "DIGIMIC1"); + + snd_soc_dapm_nc_pin(codec, "OUTL"); + snd_soc_dapm_nc_pin(codec, "OUTR"); + snd_soc_dapm_nc_pin(codec, "EARPIECE"); + snd_soc_dapm_nc_pin(codec, "PREDRIVEL"); + snd_soc_dapm_nc_pin(codec, "PREDRIVER"); + snd_soc_dapm_nc_pin(codec, "CARKITL"); + snd_soc_dapm_nc_pin(codec, "CARKITR"); + + /* Add SDP3430 specific widgets */ + ret = snd_soc_dapm_new_controls(codec, sdp3430_twl4030_dapm_widgets, + ARRAY_SIZE(sdp3430_twl4030_dapm_widgets)); + if (ret) + return ret; + + /* Set up SDP3430 specific audio path audio_map */ + snd_soc_dapm_add_routes(codec, audio_map, ARRAY_SIZE(audio_map)); + + ret = snd_soc_dapm_sync(codec); + + return ret; +} + /* Digital audio interface glue - connects codec <--> CPU */ static struct snd_soc_dai_link sdp3430_dai = { .name = "TWL4030", .stream_name = "TWL4030", .cpu_dai = &omap_mcbsp_dai[0], .codec_dai = &twl4030_dai, + .init = sdp3430_twl4030_init, .ops = &sdp3430_ops, }; -- 1.5.4.3

1 0

[alsa-devel] [PATCH 0/3] GPIO for jack reporting interface
by Lopez Cruz, Misael 26 Feb '09

26 Feb '09

The following patch set implements GPIO support for SoC jack reporting interface and uses it in SDP3430 machine driver. The jack detection interface is used in SDP3430 driver to handle headset events. That requires DAPM machine widgets to be added to the machine driver before the actual use of the interface. ASoC: Add GPIO support for jack reporting interface ASoC: Add DAPM machine widgets to SDP3430 driver ASoC: Add headset jack detection for SDP3430 machine driver

1 0

Re: [alsa-devel] [PATCH] ASoC: Add support for OMAP3 EVM
by Peter Ujfalusi 26 Feb '09

26 Feb '09

On Wednesday 25 February 2009 22:25:59 ext George G. Davis wrote: > Hi, > > On Tue, Nov 25, 2008 at 02:52:58PM +0000, Mark Brown wrote: > > On Tue, Nov 25, 2008 at 01:21:20PM +0200, Jarkko Nikula wrote: > > > Or if those EVM's & SDP's can route TWL4030 audio connections more > > > flexible than Beagle but somewhat similar manner, then probably have > > > one single machine driver for all EVM's? > > > > > > Otherwise it doesn't make very much sense to have n similar machine > > > drivers where only functions and variable names differ. > > > > Yes, it looks like a lot of these drivers could be redone along the > > lines of s3c24xx_uda134x.c with platform data specifying the differences > > between the boards. > > Is someone working on updating ASoC drivers for OMAP TWL4030 based > boards as recommended above? Just curious since I already made the > mistake of creating my own OMAP3 EVM ASoC driver w/o checking the > list first. : / Well, I have checked the s3c24xx_uda134x.c and the corresponding uda134x.c codec driver. In case of the uda134x codec - since it does not have DAPM implementation, the board file does not need to deal with the output/input pins. In case of boards using the TWL4030 codec it is not that simple IMHO. You see TWL4030 has nine output 'pins' and six (plus 2x stereo digital mic) input 'pins'. So, yes it is doable, but will it make things cleaner and more manageable? Few things came to my mind, which needs to be addressed: 1. Who is the master (OMAP McBSP or TWL4030)? 2. What is the reference clock in the given board 3. Connected pins (or not connected pins) 4. I2S or TDM mode (this is not implemented yet, but it is coming at some point) It easy to provide 1, 2 and 4. But when it comes to 3... One needs to build up the DAPM routes in the common board file for the supported boards, which again doable based on - for example - some model/board ID, but I think it will look ugly. Or I might over complicate things ;) > -- > Regards, > George -- Péter

1 0

Re: [alsa-devel] [PATCH] ASoC: Add support for OMAP3 EVM
by Mark Brown 26 Feb '09

26 Feb '09

On Wed, Feb 25, 2009 at 03:25:59PM -0500, George G. Davis wrote: > Is someone working on updating ASoC drivers for OMAP TWL4030 based > boards as recommended above? Just curious since I already made the > mistake of creating my own OMAP3 EVM ASoC driver w/o checking the > list first. : / Not to my knowledge.

2 1

[alsa-devel] possible recursive locking in snd_pcm_playback_ioctl()
by Chuck Ebbert 26 Feb '09

26 Feb '09

https://bugzilla.redhat.com/show_bug.cgi?id=486729 [ INFO: possible recursive locking detected ] 2.6.29-0.137.rc5.git4.fc11.x86_64 #1 --------------------------------------------- pulseaudio/4381 is trying to acquire lock: (&substream->self_group.lock/1){....}, at: [<ffffffffa0161309>] snd_pcm_action_group+0x53/0x217 [snd_pcm] but task is already holding lock: (&substream->self_group.lock/1){....}, at: [<ffffffffa0161309>] snd_pcm_action_group+0x53/0x217 [snd_pcm] other info that might help us debug this: 4 locks held by pulseaudio/4381: #0: (snd_pcm_link_rwlock){....}, at: [<ffffffffa0160450>] snd_pcm_stream_lock_irq+0x1d/0x2d [snd_pcm] #1: (&substream->self_group.lock){....}, at: [<ffffffffa016045c>] snd_pcm_stream_lock_irq+0x29/0x2d [snd_pcm] #2: (&substream->group->lock){....}, at: [<ffffffffa0161619>] snd_pcm_action+0x33/0x90 [snd_pcm] #3: (&substream->self_group.lock/1){....}, at: [<ffffffffa0161309>] snd_pcm_action_group+0x53/0x217 [snd_pcm] stack backtrace: Pid: 4381, comm: pulseaudio Not tainted 2.6.29-0.137.rc5.git4.fc11.x86_64 #1 Call Trace: [<ffffffff8106faa1>] __lock_acquire+0x83b/0xc0d [<ffffffff8106e500>] ? check_usage_backwards+0x4a/0x53 [<ffffffff8106ff05>] lock_acquire+0x92/0xc0 [<ffffffffa0161309>] ? snd_pcm_action_group+0x53/0x217 [snd_pcm] [<ffffffff81394c10>] _spin_lock_nested+0x34/0x67 [<ffffffffa0161309>] ? snd_pcm_action_group+0x53/0x217 [snd_pcm] [<ffffffffa0161309>] snd_pcm_action_group+0x53/0x217 [snd_pcm] [<ffffffffa016164f>] snd_pcm_action+0x69/0x90 [snd_pcm] [<ffffffffa016045c>] ? snd_pcm_stream_lock_irq+0x29/0x2d [snd_pcm] [<ffffffffa0161690>] snd_pcm_stop+0x1a/0x1c [snd_pcm] [<ffffffffa0161722>] snd_pcm_drop+0x90/0xa6 [snd_pcm] [<ffffffffa01642e9>] snd_pcm_common_ioctl1+0xb76/0xc26 [snd_pcm] [<ffffffff8101781b>] ? native_sched_clock+0x2d/0x5a [<ffffffff810170b5>] ? sched_clock+0x9/0xc [<ffffffff8106d04d>] ? lock_release_holdtime+0x2c/0x11d [<ffffffff81167865>] ? avc_has_perm_noaudit+0x444/0x497 [<ffffffff8116788c>] ? avc_has_perm_noaudit+0x46b/0x497 [<ffffffff81167458>] ? avc_has_perm_noaudit+0x37/0x497 [<ffffffffa01648ed>] snd_pcm_playback_ioctl1+0x282/0x29f [snd_pcm] [<ffffffff8106d04d>] ? lock_release_holdtime+0x2c/0x11d [<ffffffffa016529d>] snd_pcm_playback_ioctl+0x2f/0x33 [snd_pcm] [<ffffffff810ee59b>] vfs_ioctl+0x22/0x87 [<ffffffff810eea6b>] do_vfs_ioctl+0x46b/0x4ac [<ffffffff810eeb02>] sys_ioctl+0x56/0x79 [<ffffffff8101133a>] system_call_fastpath+0x16/0x1b

1 0

[alsa-devel] Rationale behind snd_pcm_htimestamp()
by Lennart Poettering 25 Feb '09

25 Feb '09

Heya! I am interested to query the current delay and the current avail atomically together with the timestamp when they were current. Apparantly there is now a function that can get the former two atomically (snd_pcm_avail_delay()) and another one that gets the latter two atomically (snd_pcm_htimestamp()). _avail_delay() seems to sync the hw index data, _htimestamp() apparently not. Hence I had assume that first calling _avail_delay() and then _htimestamp() one after the other without any further access would return the same avail value. Turns out, my test results on an USB card show that this assumption is not true. An alternative way seemed to be to go via the snd_pcm_status structure. However querying that seems not to sync the hw index data. Hmm... so let's call snd_pcm_hwsync() right before querying the struct -- as it turns out however, that function is now deprecated. So which function should I call? The doxygen comments of _hwsync() kind of suggest in a way to call snd_pcm_avail_update(), whose doxygen comments however declare that it does in fact *not* sync the hw state either, but suggest to use snd_pcm_avail() for that. Ok, so I am now tempted to first call snd_pcm_avail() and then snd_pcm_status() and have all three values atomically. But unfortunately that's not the case. Again the avail value of the two calls differs sometimes. How can I query the three values atomically? Can i do that at all? Also, snd_pcm_hw_params_is_monotonic() always returns 0 on all my devices. I am calling that function after having set both HW and SW params. Kernel is 2.6.27, alsa-libs is 1.0.19. The kernel itself does monotonic/hrtimers just fine. Hmm, last week I started this discussion about "snd_pcm_busy_for()" (aka granularity API). Who can I bribe to get an API like this? Although snd_pcm_busy_for() would suit me much better than just a call to query the granularity, I'd be happy with either... Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

2 4