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

[alsa-devel] [PATCH] alsa-info.sh: Use pgrep -f to match against command line; fix misspellings
by crimsunkg＠yahoo.com 19 Feb '09

19 Feb '09

Hi, The current alsa-info.sh script fails to report running pulseaudio/esd/artsd instances due to missing -f passed to pgrep. The attached patch resolves said issue and corrects trivial misspellings. Thanks, Dan

2 1

[alsa-devel] [PATCH 0/1] ASoC: TWL4030: Digital loopback support
by Peter Ujfalusi 18 Feb '09

18 Feb '09

Hello, The following patch adds the digital loopback support for TWL4030 codec driver. Effectively the digital loopback is routing the audio from the TX1 capture path to the RX2 playback path. With the patch applied, the audio coming from digimic0 can be routed back to the playback path without any CPU interaction. Also one can use this loopback instead of the analog bypass for the analog inputs as well, given that the TX1 capture path is configured in such a way. --- Peter Ujfalusi (1): ASoC: TWL4030: Add digital loopback support sound/soc/codecs/twl4030.c | 57 +++++++++++++++++++++++++++++++++++++++---- 1 files changed, 51 insertions(+), 6 deletions(-)

2 2

[alsa-devel] longname in sound/core/jack.c
by Takashi Iwai 18 Feb '09

18 Feb '09

Mark, I'm not sure whether I've already asked it, but I find it ugly to refer to card->longname for the input device name in sound/core/jack.c. Can it be changed to card->shortname, at least? The long name is often really long like "HDA Intel at 0xf8400000 irq 21", thus the resultant name will be "HDA Intel at 0xf8400000 irq 21 Line Out at Ext Left" as the jack name. Takashi --- diff --git a/sound/core/jack.c b/sound/core/jack.c index 43b10d6..c8254c6 100644 --- a/sound/core/jack.c +++ b/sound/core/jack.c @@ -55,7 +55,7 @@ static int snd_jack_dev_register(struct snd_device *device) int err; snprintf(jack->name, sizeof(jack->name), "%s %s", - card->longname, jack->id); + card->shortname, jack->id); jack->input_dev->name = jack->name; /* Default to the sound card device. */

2 4

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

18 Feb '09

The following changes since commit 59544d33ff3118f22a484d8be06cdf5cfc2fdca5: Mark Brown (1): ASoC: Remove version display from the WM8753 driver 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 (2): ASoC: Include I2C headers for corgi and poodle ASoC: Implement SPI device unregistration for WM8731 sound/soc/codecs/wm8731.c | 7 ++++++- sound/soc/pxa/corgi.c | 1 + sound/soc/pxa/poodle.c | 1 +

3 5

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

18 Feb '09

The following changes since commit f1464ede550b8fda75086cb9bacf8d60fc9f6780: Takashi Iwai (1): Merge branch 'for-2.6.30' of git://git.kernel.org/.../broonie/sound-2.6 into topic/asoc 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 Kevin Hilman (1): ASoC: Fix DaVinci module unload error Mark Brown (9): ASoC: Remove version display from the WM8731 driver ASoC: Clean up WM8731 bias level configuration ASoC: Improve diagnostics for AT91SAM9G20-EK probe ASoC: Check machine type before loading on AT91SAM9G20-EK ASoC: Actively manage MCLK for AT91SAM9G20-EK ASoC: Rename AT91SAMG20-EK for applications ASoC: Shuffle WM8731 SPI and I2C device registration ASoC: Refactor WM8731 device registration ASoC: Remove version display from the WM8753 driver Paul Fertser (1): ASoC: Fix WM8753 DAIs unregistering sound/soc/atmel/sam9g20_wm8731.c | 124 +++++++++++-- sound/soc/codecs/wm8731.c | 377 ++++++++++++++++-------------------- sound/soc/codecs/wm8731.h | 6 - sound/soc/codecs/wm8753.c | 9 +- sound/soc/davinci/davinci-evm.c | 3 +- sound/soc/davinci/davinci-sffsdr.c | 3 +- sound/soc/pxa/corgi.c | 43 ++++- sound/soc/pxa/poodle.c | 41 ++++- 8 files changed, 361 insertions(+), 245 deletions(-)

2 18

[alsa-devel] [PATCH] OSS: missing parentheses?
by Roel Kluin 18 Feb '09

18 Feb '09

Please review. --------------------------->8-------------8<------------------------------ Add missing parentheses Signed-off-by: Roel Kluin <roel.kluin(a)gmail.com> --- diff --git a/sound/oss/pas2_card.c b/sound/oss/pas2_card.c index 25f3a22..7f377ec 100644 --- a/sound/oss/pas2_card.c +++ b/sound/oss/pas2_card.c @@ -156,9 +156,7 @@ static int __init config_pas_hw(struct address_info *hw_config) * 0x80 */ , 0xB88); - pas_write(0x80 - | joystick?0x40:0 - ,0xF388); + pas_write(0x80 | (joystick ? 0x40 : 0), 0xF388); if (pas_irq < 0 || pas_irq > 15) {

2 1

Re: [alsa-devel] HP pavilion dv5 1110ew - no hdmi sound
by Jean-Pierre André 18 Feb '09

18 Feb '09

Hi all, > Dnia 2009-02-14, sob o godzinie 11:30 +0100, Takashi Iwai pisze: > >> At Fri, 13 Feb 2009 22:48:26 +0100, >> Bartłomiej Holdenmayer wrote: >> >> > > I did ehat You wrote. Here is my dmesg: > [ 14.729023] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) > -> IRQ 2 > 2 > [ 14.729028] hda_intel: codec_mask forced to 0xff > [ 14.729054] HDA Intel 0000:00:1b.0: setting latency timer to 64 > [ 15.776021] > ALSA /usr/src/Alsa-1.0.19/alsa-driver-1.0.19/pci/hda/../../alsa-k > ernel/pci/hda/hda_intel.c:634: hda_intel: azx_get_response timeout, > switching to > polling mode: last cmd=0x100f0000 > [ 16.780019] > ALSA /usr/src/Alsa-1.0.19/alsa-driver-1.0.19/pci/hda/../../alsa-k > ernel/pci/hda/hda_intel.c:1271: hda_intel: Codec #1 probe error; > disabling it... > [ 17.816508] > ALSA /usr/src/Alsa-1.0.19/alsa-driver-1.0.19/pci/hda/../../alsa-k > ernel/pci/hda/hda_intel.c:1271: hda_intel: Codec #3 probe error; > disabling it... > [ 17.921600] input: HDA Digital PCBeep > as /devices/pci0000:00/0000:00:1b.0/inp > ut/input11 > [ 18.052194] input: HDA Intel at 0x9f300000 irq 22 Mic at Ext Front > Jack as /d > evices/pci0000:00/0000:00:1b.0/input/input12 > [ 18.052587] input: HDA Intel at 0x9f300000 irq 22 Mic at Sep UNKNOWN > Jack as > /devices/pci0000:00/0000:00:1b.0/input/input13 > [ 18.052894] input: HDA Intel at 0x9f300000 irq 22 HP Out at Ext Front > Jack as > /devices/pci0000:00/0000:00:1b.0/input/input14 This is very interesting for me, as I have another HP dv4 computer with the same sound chip, and I get roughly similar results, but with a significant difference (using Tagashi's snapshot from yesterday) : HDA Intel 0000:00:1b.0: power state changed by ACPI to D0 HDA Intel 0000:00:1b.0: PCI INT B -> GSI 22 (level, low) -> IRQ 22 hda_intel: codec_mask forced to 0xff HDA Intel 0000:00:1b.0: setting latency timer to 64 ALSA /home/linux/rpmbuild/BUILD/alsa-driver-1.0.19.217/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:634: hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 ALSA /home/linux/rpmbuild/BUILD/alsa-driver-1.0.19.217/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1271: hda_intel: Codec #1 probe error; disabling it... ALSA /home/linux/rpmbuild/BUILD/alsa-driver-1.0.19.217/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1271: hda_intel: Codec #3 probe error; disabling it... input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input12 input: HDA Intel at 0xdf300000 irq 22 Line In at Ext Rear Jack as /devices/pci0000:00/0000:00:1b.0/input/input13 input: HDA Intel at 0xdf300000 irq 22 Mic at Ext Front Jack as /devices/pci0000:00/0000:00:1b.0/input/input14 input: HDA Intel at 0xdf300000 irq 22 HP Out at Ext Front Jack as /devices/pci0000:00/0000:00:1b.0/input/input15 The point is I never get an IRQ 22, I get IRQ 20 instead, so most players do not work unless I boot with irqpoll or noapic options (mplayer is ok though) Now, you get the IRQ 22 routed by APIC from PCI INT A, whereas I have the IRQ 22 routed by APIC from PCI INT B. And I have the PCI INT A routed to IRQ 20 for USB : ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20 ehci_hcd 0000:00:1d.7: setting latency timer to 64 ehci_hcd 0000:00:1d.7: EHCI Host Controller From this I conclude that both our sound chips trigger INT A, but in my case, it is wrongly the INT B that has been connected to IRQ 22. So my question to all the techies on this list : how on earth can I influence on this IRQ routing ? Regards Jean-Pierre

1 0

[alsa-devel] ALI5451: "stimer is not ready"
by hagedorn＠kimae.de 18 Feb '09

18 Feb '09

Dear All, since our hardware supplier changed the processor type from Transmeta T5700 (667MHz) to T5800 (997MHz), we experience massive problems with the sound card access. With the new T5800 processor we first noticed problems with IDE access. But it can be solved by switching "acpi=off" and choosing another processor type in kernel config, e.g. 'Pentium MMX' instead 'Transmeta Crusoe'. Moreover we experienced random appearance of "ali_stimer_read: stimer is not ready" messages from ALSA when accessing the sound card on T5800. I tried also 2.4.37 and 2.6.22 kernels. An update to ALSA 1.0.19 does not help too. The strange thing is that i can boot the same system over and over again... in some cases i get above error message, sometimes i get no ALSA error message at all but the sound card can not be accessed, and sometimes the system works and is recording sound - at least for a few hours. Loading the kernel module trident instead of ALSA makes the system freeze immediately on a T5800. On a T5700 it works. System yields regulary " i8253 count too high ! resetting " but does not seem to have any effect on system with T5700. On T5800 this messages is much more often. On 2.6.22 kernel i saw "TSC unstable" at boot time. I do not have knowledge about these timing things, so i would like to know a) what does above message mean exactly? b) what timing source is alsa using and how can i influence it? c) what timing source is the kernel using and how can i influence it? d) can this be caused by defect hardware or buggy BIOS? e) do you have any other ideas (e.g. kernel options)? Some info about the original system which worked well on T5700: - Linux is self-compiled with 'Linux from Scratch' - System boots from Compact Flashdisk, HDD is used for log files only - Kernel 2.4.22, optimized for Transmeta crusoe - Glibc version 2.3.2, compiled with GNU CC 3.3.3 for i686 on Kernel 2.4.25 - ALSA 1.0.5a, loaded modules are snd, snd-ali5451, soundcore, snd-pcm snd-timer, snd-page-alloc, snd-ac97-codec The same compact flashcard containing this configuration on a T5800 system will yield IDE errors "DRQ after issuing write" and will show the stated ALSA stimer error. Thank you very much in advance. Kind regards, Christoph

2 1

[alsa-devel] Snapshot From ALSA Server
by Jean-Pierre André 18 Feb '09

18 Feb '09

Hi, When I try to compile alsa-driver from the snapshot from alsa server (eg alsa-driver-1.0.19.11.g5fc41.195.g772ce.tar.bz2), the compilation process fails at applying two patches : pci/hda/hda_beep.patch and acore/misc.patch After manually fixing the patches, the compilation goes on and provides apparently valid modules (at least I get sound from them). Why is it so ? In the said patches I see nothing specific to my environment. Could there be a missing patch or overlapping patches applied in a wrong order ? Are these tarballs compiled before being made available ? Note : this problem does not occur in daily snapshots by Tagashi. Regards Jean-Pierre

3 2

[alsa-devel] [PATCH] hda: Add logic to force HP mixer creation
by Matthew Ranostay 18 Feb '09

18 Feb '09

In some instances like a laptop PCI_QUIRK you may want to force a headphone mixer otherwise a "Front" mixer would be in its place, this is to aid user friendlyness. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- sound/pci/hda/patch_sigmatel.c | 25 ++++++++++++++++++------- 1 files changed, 18 insertions(+), 7 deletions(-) diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index aeb5d21..e02a187 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -168,6 +168,7 @@ struct sigmatel_spec { unsigned int surr_switch: 1; unsigned int alt_switch: 1; unsigned int hp_detect: 1; + unsigned int hp_mixer: 1; unsigned int spdif_mute: 1; unsigned int check_volume_offset:1; @@ -857,9 +858,9 @@ static struct hda_verb stac92hd73xx_10ch_core_init[] = { }; static struct hda_verb stac92hd83xxx_core_init[] = { - { 0xa, AC_VERB_SET_CONNECT_SEL, 0x1}, - { 0xb, AC_VERB_SET_CONNECT_SEL, 0x1}, - { 0xd, AC_VERB_SET_CONNECT_SEL, 0x0}, + { 0xa, AC_VERB_SET_CONNECT_SEL, 0x0}, + { 0xb, AC_VERB_SET_CONNECT_SEL, 0x0}, + { 0xd, AC_VERB_SET_CONNECT_SEL, 0x1}, /* power state controls amps */ { 0x01, AC_VERB_SET_EAPD, 1 << 2}, @@ -3115,12 +3116,12 @@ static int stac92xx_auto_create_multi_out_ctls(struct hda_codec *codec, "Front", "Surround", NULL /*CLFE*/, "Side" }; hda_nid_t nid = 0; - int i, err; + int i, idx = 0, err; unsigned int wid_caps; for (i = 0; i < cfg->line_outs && spec->multiout.dac_nids[i]; i++) { nid = spec->multiout.dac_nids[i]; - if (i == 2) { + if (idx == 2) { /* Center/LFE */ err = create_controls(codec, "Center", nid, 1); if (err < 0) @@ -3139,9 +3140,9 @@ static int stac92xx_auto_create_multi_out_ctls(struct hda_codec *codec, if (err < 0) return err; } - + idx++; } else { - const char *name = chname[i]; + const char *name = chname[idx]; /* if it's a single DAC, assign a better name */ if (!i && is_unique_dac(spec, nid)) { switch (cfg->line_out_type) { @@ -3153,6 +3154,10 @@ static int stac92xx_auto_create_multi_out_ctls(struct hda_codec *codec, break; } } + if (!i && spec->hp_mixer) + name = "Headphone"; + else + idx++; err = create_controls(codec, name, nid, 3); if (err < 0) return err; @@ -4894,6 +4899,12 @@ again: break; } + switch (spec->board_config) { + case STAC_DELL_S14: + spec->hp_mixer = 1; + break; + } + err = stac92xx_parse_auto_config(codec, 0x1d, 0); if (!err) { if (spec->board_config < 0) { -- 1.5.6.3

3 10