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

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

[alsa-devel] Timer instability
by Lennart Poettering 25 Feb '09

25 Feb '09

Heya! As you might now PulseAudio schedules audio by system timers, not by sound card interrupts. Unfortunately there are are couple of issues with the reliability of the timing/buffering information we get from ALSA. For example, on an ens1371 I have tracked down the following issue: I use the full buffer that the sound card provides (64K, i.e. 371ms). I sleep for about 350 ms, then fill up again, and sleep 350ms, and so and so on. Everytime I wake up I check snd_pcm_avail() and write exactly as much as this call tells me to. I also listen to POLLOUT events on the fd, however I call snd_pcm_sw_params_set_period_event(, 0) for it to make sure I actually don't get any real events on that. After a couple of minutes of running this loop I can reliably reproduce that _avail() tells me I should fill the buffer up, I do so, query it again and it shows the buffer is filled up. I then go to sleep but immediately get POLLIN (although I shouldnt, given that I called snd_pcm_sw_params_set_period_event()), wake up again, call snd_pcm_avail() and according to it the buffer ran completely empty. The poll() took less than 1 ms time, and the last thing I did before going to sleep was checking that the buffer was full. So certainly ALSA is lying to me here... The buffer couldn't have run empty in less than 1 ms! The same with real numbers as one example: 1. ... we are woken up 2. _avail() returns 15496 samples (i.e. 350ms to fill up) 3. we gather and write 15496 samples 4. _avail() returns 48 samples, which we consider "filled up enough" to go to sleep 5. we call poll() 6. after < 1ms we are woken up by a POLLIN (which we actually thought we had explicitly disabled) 7. _avail() returns 16448 samples (i.e. 372ms to fill up -- larger than the actual buffer of 16384 samples!) This smells a lot like some kind of overflow to me, given that in every case where I could reproduce this it was possible to 'fix' the issue by substracting the buffer size from the _avail() after the poll(). After that substraction the value started to make sense again. (i.e. in the example above it then becomes 64 samples, which is reasonable after sleep less than 1ms I guess). The stop threshold is set to the boundary here btw. If necessary I could extract a test case for this, but my hope that you guys might have an idea what goes on without a test case, given that this smells so "overflowy" ;-) And of course, how come ALSA triggers POLLIN if I asked it not to? This is alsa-libs 1.0.19 on a 2.6.27 kernel. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

5 36