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

[alsa-devel] [PATCH] hda: STAC9205 GPIO line fix
by Matthew Ranostay 24 Jan '08

24 Jan '08

Fixed issue that the incorrect GPIO line was being pulled high for some STAC9205 based laptops. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- diff -r 32b13f326915 pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Thu Jan 24 11:49:21 2008 +0100 +++ b/pci/hda/patch_sigmatel.c Thu Jan 24 09:08:23 2008 -0500 @@ -3661,11 +3661,11 @@ static int patch_stac9205(struct hda_cod stac92xx_set_config_reg(codec, 0x1f, 0x01441030); stac92xx_set_config_reg(codec, 0x20, 0x1c410030); - spec->gpio_mask = 0x00000007; /* GPIO0-2 */ - /* GPIO0 High = EAPD, GPIO1 Low = DRM, - * GPIO2 High = Headphone Mute + spec->gpio_mask = 0x0000000b; + /* GPIO0 High = EAPD, GPIO1 Low = Headphone Mute, + * GPIO3 High = DRM */ - spec->gpio_data = 0x00000005; + spec->gpio_data = 0x00000009; break; default: /* GPIO0 High = EAPD */

2 1

Re: [alsa-devel] 1.0.16rc1 release -- error: ‘system_utsname’ undeclared
by Takashi Iwai 24 Jan '08

24 Jan '08

At Fri, 25 Jan 2008 00:30:31 +1300, Brad Milne wrote: > > On Jan 25, 2008 12:23 AM, Takashi Iwai <tiwai(a)suse.de> wrote: > > At Fri, 25 Jan 2008 00:18:33 +1300, > > > > Brad Milne wrote: > > > > > > On Jan 24, 2008 11:58 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > > > > At Thu, 24 Jan 2008 23:40:55 +1300, > > > > > > > > Brad Milne wrote: > > > > > > > > > > > From tiwai at suse.de Wed Jan 23 08:31:32 2008 > > > > > > From: tiwai at suse.de (Takashi Iwai) > > > > > > Date: Wed, 23 Jan 2008 08:31:32 +0100 > > > > > > Subject: [alsa-devel] > > > > > > =?iso-8859-7?q?1=2E0=2E16rc1_release_--_error=3A_=A1?= > > > > > > =?iso-8859-7?q?system=5Futsname=A2_undeclared?= > > > > > > In-Reply-To: <s5htzl5t45y.wl%tiwai(a)suse.de> > > > > > > References: < Pine.LNX.4.61.0801221247570.9698(a)tm8103.perex-int.cz> > > > > > > <47964342.1060608(a)measham.id.au> <s5htzl5t45y.wl%tiwai(a)suse.de > > > > > > > Message-ID: <s5hsl0pt2uj.wl%tiwai(a)suse.de> > > > > > > > > > > > At Wed, 23 Jan 2008 08:03:05 +0100, > > > > > > I wrote: > > > > > > > > > > > > > > At Wed, 23 Jan 2008 06:25:54 +1100, > > > > > > > Rick Measham wrote: > > > > > > > > > > > > > > > > [1 <multipart/signed (7bit)>] > > > > > > > > [1.1 <text/plain; UTF-8 (quoted-printable)>] > > > > > > > > Jaroslav Kysela wrote: > > > > > > > > > 1.0.16rc1 release is available for download on > > > > > > > > > > > > > > > > Running Kubuntu: > > > > > > > > > > > > > > > > # uname -a > > > > > > > > Linux lugtop 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 GNU/Linux > > > > > > > > > > > > > > > > > > > > > > > > During the make: > > > > > > > > > > > > > > > > In file included from > > > > > > > > /usr/src/alsa/alsa-driver-1.0.16rc1/acore/info_oss.c:7: > > > > > > > > /usr/src/alsa/alsa-driver-1.0.16rc1/acore/../alsa-kernel/core/info_oss.c: > > > > > > > > In function ?snd_sndstat_proc_read?: > > > > > > > > /usr/src/alsa/alsa-driver-1.0.16rc1/acore/../alsa-kernel/core/info_oss.c:96: > > > > > > > > error: ?system_utsname? undeclared (first use in this function) > > > > > > > > /usr/src/alsa/alsa-driver-1.0.16rc1/acore/../alsa-kernel/core/info_oss.c:96: > > > > > > > > error: (Each undeclared identifier is reported only once > > > > > > > > /usr/src/alsa/alsa-driver-1.0.16rc1/acore/../alsa-kernel/core/info_oss.c:96: > > > > > > > > error: for each function it appears in.) > > > > > > > > make[3]: *** [/usr/src/alsa/alsa-driver-1.0.16rc1/acore/info_oss.o] Error 1 > > > > > > > > make[2]: *** [/usr/src/alsa/alsa-driver-1.0.16rc1/acore] Error 2 > > > > > > > > make[1]: *** [_module_/usr/src/alsa/alsa-driver-1.0.16rc1] Error 2 > > > > > > > > make[1]: Leaving directory `/usr/src/linux-headers-2.6.20-16-386' > > > > > > > > make: *** [compile] Error 2 > > > > > > > > > > > > > > Isn't it fixed on HG version? > > > > > > > > > > > Nevermind, I myself can confirm that it's broken. > > > > > > The patch below should fix the problem. > > > > > > > > > > > > > > > > Takashi > > > > > > > > > > > diff -r a5f603cb254a configure.in > > > > > > --- a/configure.in Tue Jan 22 17:52:34 2008 +0100 > > > > > > +++ b/configure.in Wed Jan 23 08:28:56 2008 +0100 > > > > > > @@ -2571,7 +2571,7 @@ init_utsname="0" > > > > > > init_utsname="0" > > > > > > ac_save_CFLAGS="$CFLAGS" > > > > > > ac_save_CC="$CC" > > > > > > -CFLAGS="$KERNEL_CHECK_CFLAGS -Werror" > > > > > > +CFLAGS="$KERNEL_CHECK_CFLAGS -Werror=implicit-function-declaration" > > > > > > CC=$KCC > > > > > > AC_TRY_COMPILE([ > > > > > > #define __KERNEL__ > > > > > > > > > > It doesn't seem that it is fixed in HG or by this patch (though I do get: > > > > > patching file configure.in > > > > > Hunk #1 succeeded at 1579 with fuzz 2 (offset > > > > > -992 lines). > > > > > patch unexpectedly ends in middle of line > > > > > when patching), I get the exact same error in both. > > > > > > > > And did you run hgcompile after that? > > > > > > If I run: > > > sudo ./configure > > > then: > > > sudo ./hgcompile > > > > You don't have to be root for compiling the driver. The root priv is > > needed only for installation, i.e. make install. > > > > > on the latest hg code, I still get the same error: > > > > > from /usr/src/alsa/alsa-driver/acore/info_oss.c:7: > > > include/linux/utsname.h:77: error: expected '=', ',', ';', 'asm' or > > > '__attribute__' before '{' token > > > ... > > > /usr/src/alsa/alsa-driver/acore/../alsa-kernel/core/info_oss.c: In > > > function 'snd_sndstat_proc_read': > > > /usr/src/alsa/alsa-driver/acore/../alsa-kernel/core/info_oss.c:96: > > > error: 'system_utsname' undeclared (first use in this function) > > > ... > > > make[3]: *** [/usr/src/alsa/alsa-driver/acore/info_oss.o] Error 1 > > > ... > > > > Interesting. You're using 2.6.20 kernel, right? > > > > First check include/config.h. whether it defines > > CONFIG_HAVE_INIT_UTSNAME. If it's defined, then the build must go > > well. If it's undefined (commented out), then check configure.in > > whether the patch was properly applied and -Werror was changed to > > -Werror=implicit-function-declaration. And see config.log at the > > place where init_utsname is checked. You must have a compile error > > there. Show that part. > > brad@cyborg:/usr/src/alsa/alsa-driver$ uname -a > Linux cyborg 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 > i686 GNU/Linux > > include/config.h: > /* 2.6 kernel */ > #define CONFIG_SND_NESTED_CLASS_DEVICE 1 > /* #undef CONFIG_SND_OLD_DRIVER_SUSPEND */ > #define CONFIG_SND_REMOVE_PAGE_RESERVE 1 > #define CONFIG_SND_NEW_IRQ_HANDLER 1 > #define CONFIG_HAVE_PNP_SUSPEND 1 > #define CONFIG_HAVE_GFP_T 1 > /* #undef CONFIG_HAVE_INIT_UTSNAME */ <----!! > > configure.in (hg version): > dnl Check for init_utsname... > AC_MSG_CHECKING(for init_utsname) > init_utsname="0" > ac_save_CFLAGS="$CFLAGS" > ac_save_CC="$CC" > CFLAGS="$KERNEL_CHECK_CFLAGS -Werror=implicit-function-declaration" > CC=$KCC > AC_TRY_COMPILE([ > #define __KERNEL__ > > config.log: > configure:11638: checking for init_utsname > configure:11673: gcc -c -Wall -fno-strict-aliasing -g -O2 > -I/lib/modules/2.6.22-14-generic/build/include > -I/lib/modules/2.6.22-14-generic/build/include/asm-i386/mach-default > -Iinclude -nostdinc -iwithprefix include -DKBUILD_STR(s)=#s > -DKBUILD_BASENAME=KBUILD_STR(dummy) -DKBUILD_MODNAME=KBUILD_BASENAME > -Werror=implicit-function-declaration conftest.c >&5 > cc1: error: unrecognized command line option > "-Werror=implicit-function-declaration" Grrr, it looks like this option isn't available for all gcc versions. Then try the patch below and run hgcompile. It should work, at least, for your system. thanks, Takashi --- diff -r e80f59e90231 configure.in --- a/configure.in Wed Jan 23 08:33:10 2008 +0100 +++ b/configure.in Thu Jan 24 12:36:35 2008 +0100 @@ -2567,13 +2567,16 @@ fi fi dnl Check for init_utsname... +if test "$kversion.$kpatchlevel" = "2.6" -a $ksublevel -ge 19; then + CONFIG_HAVE_INIT_UTSNAME=1 +else AC_MSG_CHECKING(for init_utsname) -init_utsname="0" -ac_save_CFLAGS="$CFLAGS" -ac_save_CC="$CC" -CFLAGS="$KERNEL_CHECK_CFLAGS -Werror=implicit-function-declaration" -CC=$KCC -AC_TRY_COMPILE([ + init_utsname="0" + ac_save_CFLAGS="$CFLAGS" + ac_save_CC="$CC" + CFLAGS="$KERNEL_CHECK_CFLAGS -Werror" + CC=$KCC + AC_TRY_COMPILE([ #define __KERNEL__ #include <linux/config.h> #include <linux/utsname.h> @@ -2585,9 +2588,10 @@ AC_TRY_COMPILE([ AC_MSG_RESULT(no);init_utsname="0", AC_MSG_RESULT(unknown);init_utsname="0" ) -CFLAGS=$ac_save_CFLAGS -CC=$ac_save_CC -CONFIG_HAVE_INIT_UTSNAME=$init_utsname + CFLAGS=$ac_save_CFLAGS + CC=$ac_save_CC + CONFIG_HAVE_INIT_UTSNAME=$init_utsname +fi dnl AC_SUBST(CONFIG_HAVE_INIT_UTSNAME) if test "$CONFIG_HAVE_INIT_UTSNAME" = "1"; then AC_DEFINE(CONFIG_HAVE_INIT_UTSNAME)

2 1

Re: [alsa-devel] 1.0.16rc1 release -- error: ‘system_utsname’ undeclared
by Brad Milne 24 Jan '08

24 Jan '08

> From tiwai at suse.de Wed Jan 23 08:31:32 2008 > From: tiwai at suse.de (Takashi Iwai) > Date: Wed, 23 Jan 2008 08:31:32 +0100 > Subject: [alsa-devel] > =?iso-8859-7?q?1=2E0=2E16rc1_release_--_error=3A_=A1?= > =?iso-8859-7?q?system=5Futsname=A2_undeclared?= > In-Reply-To: <s5htzl5t45y.wl%tiwai(a)suse.de> > References: < Pine.LNX.4.61.0801221247570.9698(a)tm8103.perex-int.cz> > <47964342.1060608(a)measham.id.au> <s5htzl5t45y.wl%tiwai(a)suse.de > > Message-ID: <s5hsl0pt2uj.wl%tiwai(a)suse.de> > At Wed, 23 Jan 2008 08:03:05 +0100, > I wrote: > > > > At Wed, 23 Jan 2008 06:25:54 +1100, > > Rick Measham wrote: > > > > > > [1 <multipart/signed (7bit)>] > > > [1.1 <text/plain; UTF-8 (quoted-printable)>] > > > Jaroslav Kysela wrote: > > > > 1.0.16rc1 release is available for download on > > > > > > Running Kubuntu: > > > > > > # uname -a > > > Linux lugtop 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 GNU/Linux > > > > > > > > > During the make: > > > > > > In file included from > > > /usr/src/alsa/alsa-driver-1.0.16rc1/acore/info_oss.c:7: > > > /usr/src/alsa/alsa-driver-1.0.16rc1/acore/../alsa-kernel/core/info_oss.c: > > > In function ?snd_sndstat_proc_read?: > > > /usr/src/alsa/alsa-driver-1.0.16rc1/acore/../alsa-kernel/core/info_oss.c:96: > > > error: ?system_utsname? undeclared (first use in this function) > > > /usr/src/alsa/alsa-driver-1.0.16rc1/acore/../alsa-kernel/core/info_oss.c:96: > > > error: (Each undeclared identifier is reported only once > > > /usr/src/alsa/alsa-driver-1.0.16rc1/acore/../alsa-kernel/core/info_oss.c:96: > > > error: for each function it appears in.) > > > make[3]: *** [/usr/src/alsa/alsa-driver-1.0.16rc1/acore/info_oss.o] Error 1 > > > make[2]: *** [/usr/src/alsa/alsa-driver-1.0.16rc1/acore] Error 2 > > > make[1]: *** [_module_/usr/src/alsa/alsa-driver-1.0.16rc1] Error 2 > > > make[1]: Leaving directory `/usr/src/linux-headers-2.6.20-16-386' > > > make: *** [compile] Error 2 > > > > Isn't it fixed on HG version? > Nevermind, I myself can confirm that it's broken. > The patch below should fix the problem. > Takashi > diff -r a5f603cb254a configure.in > --- a/configure.in Tue Jan 22 17:52:34 2008 +0100 > +++ b/configure.in Wed Jan 23 08:28:56 2008 +0100 > @@ -2571,7 +2571,7 @@ init_utsname="0" > init_utsname="0" > ac_save_CFLAGS="$CFLAGS" > ac_save_CC="$CC" > -CFLAGS="$KERNEL_CHECK_CFLAGS -Werror" > +CFLAGS="$KERNEL_CHECK_CFLAGS -Werror=implicit-function-declaration" > CC=$KCC > AC_TRY_COMPILE([ > #define __KERNEL__ It doesn't seem that it is fixed in HG or by this patch (though I do get: patching file configure.in Hunk #1 succeeded at 1579 with fuzz 2 (offset -992 lines). patch unexpectedly ends in middle of line when patching), I get the exact same error in both. I don't pretend to know a lot about alsa workings, but is this patch in the right area as the error complains about 'system_utsname', not 'init_utsname'? Brad

2 3

[alsa-devel] [PATCH1/2] hda: Added mono_out_pin to autoconfig
by Matthew Ranostay 24 Jan '08

24 Jan '08

Added a mono_out_pin field to autocfg struct, and code to parse for the mono_out_line. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- diff -r 5492010913f0 pci/hda/hda_codec.c --- a/pci/hda/hda_codec.c Tue Jan 22 15:37:13 2008 +0100 +++ b/pci/hda/hda_codec.c Wed Jan 23 10:55:11 2008 -0500 @@ -769,7 +769,7 @@ get_alloc_amp_hash(struct hda_codec *cod /* * query AMP capabilities for the given widget and direction */ -static u32 query_amp_caps(struct hda_codec *codec, hda_nid_t nid, int direction) +u32 query_amp_caps(struct hda_codec *codec, hda_nid_t nid, int direction) { struct hda_amp_info *info; @@ -2708,6 +2708,10 @@ int snd_hda_parse_pin_def_config(struct case AC_JACK_LINE_OUT: seq = get_defcfg_sequence(def_conf); assoc = get_defcfg_association(def_conf); + + if (!(wid_caps & AC_WCAP_STEREO)) + if (!cfg->mono_out_pin) + cfg->mono_out_pin = nid; if (!assoc) continue; if (!assoc_line_out) @@ -2856,6 +2860,7 @@ int snd_hda_parse_pin_def_config(struct cfg->hp_outs, cfg->hp_pins[0], cfg->hp_pins[1], cfg->hp_pins[2], cfg->hp_pins[3], cfg->hp_pins[4]); + snd_printd(" mono: mono_out=0x%x\n", cfg->mono_out_pin); snd_printd(" inputs: mic=0x%x, fmic=0x%x, line=0x%x, fline=0x%x," " cd=0x%x, aux=0x%x\n", cfg->input_pins[AUTO_PIN_MIC], diff -r 5492010913f0 pci/hda/hda_local.h --- a/pci/hda/hda_local.h Tue Jan 22 15:37:13 2008 +0100 +++ b/pci/hda/hda_local.h Wed Jan 23 10:56:40 2008 -0500 @@ -332,6 +332,7 @@ struct auto_pin_cfg { hda_nid_t input_pins[AUTO_PIN_LAST]; hda_nid_t dig_out_pin; hda_nid_t dig_in_pin; + hda_nid_t mono_out_pin; }; #define get_defcfg_connect(cfg) \ @@ -374,6 +375,7 @@ static inline u32 get_wcaps(struct hda_c return codec->wcaps[nid - codec->start_nid]; } +u32 query_amp_caps(struct hda_codec *codec, hda_nid_t nid, int direction); int snd_hda_override_amp_caps(struct hda_codec *codec, hda_nid_t nid, int dir, unsigned int caps);

2 1

[alsa-devel] Fixing my sound driver
by Adrian McMenamin 24 Jan '08

24 Jan '08

I am still trying to find out what is wrong with my sound driver - for the Sega Dreamcast (sound/sh/aica.c). This works perfectly with the OSS emulation layer but will not work with the ALSA layer per se. As this shows - there is something wrong with how it interacts with the PCM layer of alsa-lib: $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: AICA [AICA], device 0: AICA PCM [AICA PCM] Subdevices: 1/1 Subdevice #0: subdevice #0 $ $ $ aplay -L null Discard all samples (playback) or generate zero samples (capture) I have no reason to think that my build of alsa-lib is wrong - both the automagic buildroot build and my own by-hand build behave the same way. So therefore I assume it must be something in the driver?! Some questions: The driver implements nothing for capture (the AICA device is pure playback) - could that have an effect? What information must the driver pass to the PCM layer? What could make the alsa-lib layer detect the card but then report "null" is the only PCM device? Adrian

2 3

[alsa-devel] Specific question about ICE1724 + AK4114
by Pavel Hofman 24 Jan '08

24 Jan '08

Hello, I would like to add support for automatic detection of incoming SPDIF sample rate for ICE cards with AK4114 DIR, specifically ESI Juli and Prodigy192 with MI/IODI/O card. Juli windows drivers support the detection, Prodigy drivers don't (broken in some other way too), but the hardware is basically identical. AK4114 support detection by comparing the recovered clock from SPDIF with another clock of 11, 12 or 24MHz, supplied by a crystal, or externally. In both cards this functionality seems to be provided by Xilinx XC9536 CPLD, together with PLL frequency multiplier MK73-1. It all fits together, the CPLD provides the freqency division for PLL feedback of the multiplier. External reference clock input of AK4114 is connected to CPLD, as well as setup pins XTL0/1. Output frequency of MK73-1 specified in datasheet is in the range of 10-50MHz Here is my question: For the PLL multiplier to work, its datasheet says it must be fed with input pulses of 20-50kHz. This frequency could be easily provided by ICE1724, BUT in master mode only. When in slave mode (which is the case for active SPDIF input - clock provided by AK4114), all the clocks are derived from the external clock. This signal obviously cannot be used as reference for the sample rate detection in AK4114 - i.e. basically of itself. According to the ICE1724 datasheet, only I2C and MIDI clocks are derived from the 48kHz mode crystal in slave mode. The datasheed says I2C clock is output only during I2C read/write activity, MIDI clock is not directly output at all. The cards have no other visible crystals/clock modules apart of those two connected directly to ICE1724. I could not trace any connections from the actual crystals to CPLD. Now here I am, absolutely wondering where the CPLD gets its low frequency stable signal for the PLL multiplier, to provide reference clock for SPDIF rate detection. I am afraid without this knowledge I cannot make the detection work in the alsa driver. Hopefully someone experienced in this area will throw a ray of light upon this mystery. Thanks in advance for any ideas, information, suggestions. Best regards, Pavel Hofman.

1 0

[alsa-devel] [PATCH2/2] hda: Add dynamic mono mixer support for STAC92xx codecs
by Matthew Ranostay 23 Jan '08

23 Jan '08

Allows for dynamically creating mono out mixer controls and well as mono mux controls. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- diff -r 5492010913f0 pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Tue Jan 22 15:37:13 2008 +0100 +++ b/pci/hda/patch_sigmatel.c Tue Jan 22 21:22:52 2008 -0500 @@ -756,7 +756,6 @@ static struct snd_kcontrol_new stac92hd7 static struct snd_kcontrol_new stac92hd71bxx_analog_mixer[] = { STAC_INPUT_SOURCE(2), - STAC_MONO_MUX, HDA_CODEC_VOLUME_IDX("Capture Volume", 0x0, 0x1c, 0x0, HDA_OUTPUT), HDA_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x1c, 0x0, HDA_OUTPUT), @@ -768,15 +767,12 @@ static struct snd_kcontrol_new stac92hd7 HDA_CODEC_MUTE("Analog Loopback 1", 0x17, 0x3, HDA_INPUT), HDA_CODEC_MUTE("Analog Loopback 2", 0x17, 0x4, HDA_INPUT), - - HDA_CODEC_MUTE_MONO("Mono Playback Switch", 0x14, 0x1, 0, HDA_INPUT), { } /* end */ }; static struct snd_kcontrol_new stac92hd71bxx_mixer[] = { STAC_INPUT_SOURCE(2), STAC_ANALOG_LOOPBACK(0xFA0, 0x7A0, 2), - STAC_MONO_MUX, HDA_CODEC_VOLUME_IDX("Capture Volume", 0x0, 0x1c, 0x0, HDA_OUTPUT), HDA_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x1c, 0x0, HDA_OUTPUT), @@ -785,8 +781,6 @@ static struct snd_kcontrol_new stac92hd7 HDA_CODEC_VOLUME_IDX("Capture Volume", 0x1, 0x1d, 0x0, HDA_OUTPUT), HDA_CODEC_MUTE_IDX("Capture Switch", 0x1, 0x1d, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME_IDX("Capture Mux Volume", 0x1, 0x1b, 0x0, HDA_OUTPUT), - - HDA_CODEC_MUTE_MONO("Mono Playback Switch", 0x14, 0x1, 0, HDA_INPUT), { } /* end */ }; @@ -1157,7 +1151,7 @@ static struct snd_pci_quirk stac9200_cfg static unsigned int ref925x_pin_configs[8] = { 0x40c003f0, 0x424503f2, 0x01813022, 0x02a19021, - 0x90a70320, 0x02214210, 0x400003f1, 0x9033032e, + 0x90a70320, 0x02214210, 0x01019020, 0x9033032e, }; static unsigned int stac925x_MA6_pin_configs[8] = { @@ -1561,7 +1555,7 @@ static struct snd_pci_quirk stac927x_cfg static unsigned int ref9205_pin_configs[12] = { 0x40000100, 0x40000100, 0x01016011, 0x01014010, - 0x01813122, 0x01a19021, 0x40000100, 0x40000100, + 0x01813122, 0x01a19021, 0x01019020, 0x40000100, 0x90a000f0, 0x90a000f0, 0x01441030, 0x01c41030 }; @@ -2018,6 +2012,7 @@ enum { enum { STAC_CTL_WIDGET_VOL, STAC_CTL_WIDGET_MUTE, + STAC_CTL_WIDGET_MONO_MUX, STAC_CTL_WIDGET_IO_SWITCH, STAC_CTL_WIDGET_CLFE_SWITCH }; @@ -2025,6 +2020,7 @@ static struct snd_kcontrol_new stac92xx_ static struct snd_kcontrol_new stac92xx_control_templates[] = { HDA_CODEC_VOLUME(NULL, 0, 0, 0), HDA_CODEC_MUTE(NULL, 0, 0, 0), + STAC_MONO_MUX, STAC_CODEC_IO_SWITCH(NULL, 0), STAC_CODEC_CLFE_SWITCH(NULL, 0), }; @@ -2388,7 +2384,9 @@ static int stac92xx_auto_create_mono_out mono_mux->items[mono_mux->num_items].index = i; mono_mux->num_items++; } - return 0; + + return stac92xx_add_control(spec, STAC_CTL_WIDGET_MONO_MUX, + "Mono Mux", spec->mono_nid); } /* labels for dmic mux inputs */ @@ -2569,6 +2567,50 @@ static int stac92xx_parse_auto_config(st sizeof(spec->autocfg.hp_pins)); spec->autocfg.line_outs = spec->autocfg.hp_outs; hp_speaker_swap = 1; + } + if (spec->autocfg.mono_out_pin) { + int dir = (get_wcaps(codec, spec->autocfg.mono_out_pin) + & AC_WCAP_OUT_AMP) ? HDA_OUTPUT : HDA_INPUT; + u32 caps = query_amp_caps(codec, + spec->autocfg.mono_out_pin, dir); + hda_nid_t conn_list[1]; + + /* get the mixer node and then the mono mux if it exists */ + if (snd_hda_get_connections(codec, + spec->autocfg.mono_out_pin, conn_list, 1) && + snd_hda_get_connections(codec, conn_list[0], + conn_list, 1)) { + + int wcaps = get_wcaps(codec, conn_list[0]); + int wid_type = (wcaps & AC_WCAP_TYPE) + >> AC_WCAP_TYPE_SHIFT; + /* LR swap check, some stac925x have a mux that + * changes the DACs output path instead of the + * mono-mux path. + */ + if (wid_type == AC_WID_AUD_SEL && + !(wcaps & AC_WCAP_LR_SWAP)) + spec->mono_nid = conn_list[0]; + } + /* all mono outs have a least a mute/unmute switch */ + err = stac92xx_add_control(spec, STAC_CTL_WIDGET_MUTE, + "Mono Playback Switch", + HDA_COMPOSE_AMP_VAL(spec->autocfg.mono_out_pin, + 1, 0, dir)); + if (err < 0) + return err; + /* check to see if there is volume support for the amp */ + if ((caps & AC_AMPCAP_NUM_STEPS) >> AC_AMPCAP_NUM_STEPS_SHIFT) { + err = stac92xx_add_control(spec, STAC_CTL_WIDGET_VOL, + "Mono Playback Volume", + HDA_COMPOSE_AMP_VAL(spec->autocfg.mono_out_pin, + 1, 0, dir)); + if (err < 0) + return err; + } + + stac92xx_auto_set_pinctl(codec, spec->autocfg.mono_out_pin, + AC_PINCTL_OUT_EN); } if ((err = stac92xx_add_dyn_out_pins(codec, &spec->autocfg)) < 0) @@ -3317,7 +3359,6 @@ again: spec->gpio_mask = spec->gpio_data = 0x00000001; /* GPIO0 High = EAPD */ - spec->mono_nid = 0x15; spec->mux_nids = stac92hd71bxx_mux_nids; spec->adc_nids = stac92hd71bxx_adc_nids; spec->dmic_nids = stac92hd71bxx_dmic_nids;

1 0

[alsa-devel] problems with Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
by forwind 23 Jan '08

23 Jan '08

Hi folks, I am having difficulty getting a friends on-board speakers working on her laptop. After some reading of forums I'm not sure whether there is a solution for this or not ? The setup and details can be read below. The headphones work fine but the speakers are mute even though nothing is muted. I installed from source alsa version 1.0.15rc3 but to no avail. ALSA Audio Debug v0.1.0 - Thu Jan 17 23:21:23 GMT 2008 http://alsa.opensrc.org/aadebug http://www.gnu.org/licenses/gpl.txt Kernel ---------------------------------------------------- Linux laura-laptop 2.6.22-14-rt #1 SMP PREEMPT RT Tue Dec 18 10:01:34 UTC 2007 i686 GNU/Linux Loaded Modules -------------------------------------------- snd_rtctimer 4384 1 snd_hda_intel 291616 1 snd_pcm_oss 43264 0 snd_mixer_oss 17664 1 snd_pcm_oss snd_pcm 80132 2 snd_hda_intel,snd_pcm_oss snd_page_alloc 11400 2 snd_hda_intel,snd_pcm snd_hwdep 10500 1 snd_hda_intel snd_seq_dummy 4740 0 snd_seq_oss 33792 0 snd_seq_midi 9600 0 snd_rawmidi 25728 1 snd_seq_midi snd_seq_midi_event 8576 2 snd_seq_oss,snd_seq_midi snd_seq 54128 7 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_timer 24324 3 snd_rtctimer,snd_pcm,snd_seq snd_seq_device 9228 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq snd 55428 13 snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_hwdep,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device Modprobe Conf --------------------------------------------- Warning: module config file does not exist This means any kernel modules will not be auto loaded See your linux distro docs on how to create this file Proc Asound ----------------------------------------------- Advanced Linux Sound Architecture Driver Version 1.0.15rc3. 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xfc200000 irq 22 2: : timer 3: : sequencer 4: [ 0- 2]: digital audio capture 5: [ 0- 1]: digital audio playback 6: [ 0- 0]: digital audio playback 7: [ 0- 0]: digital audio capture 8: [ 0- 1]: hardware dependent 9: [ 0- 0]: hardware dependent 10: [ 0] : control 00-01: HDA Codec 1 00-00: HDA Codec 0 00-02: ALC883 Analog : ALC883 Analog : capture 2 00-01: ALC883 Digital : ALC883 Digital : playback 1 00-00: ALC883 Analog : ALC883 Analog : playback 1 : capture 2 Client info cur clients : 4 peak clients : 4 max clients : 192 Client 0 : "System" [Kernel] Port 0 : "Timer" (Rwe-) Port 1 : "Announce" (R-e-) Connecting To: 15:0 Client 14 : "Midi Through" [Kernel] Port 0 : "Midi Through Port-0" (RWe-) Client 15 : "OSS sequencer" [Kernel] Port 0 : "Receiver" (-we-) Connected From: 0:1 Client 128 : "TiMidity" [User] Port 0 : "TiMidity port 0" (-We-) Port 1 : "TiMidity port 1" (-We-) Port 2 : "TiMidity port 2" (-We-) Port 3 : "TiMidity port 3" (-We-) Output pool : Pool size : 500 Cells in use : 0 Peak cells in use : 0 Alloc success : 0 Alloc failures : 0 Input pool : Pool size : 1000 Cells in use : 0 Peak cells in use : 0 Alloc success : 0 Alloc failures : 0 Dev Snd --------------------------------------------------- controlC0 hwC0D0 hwC0D1 pcmC0D0c pcmC0D0p pcmC0D1p pcmC0D2c seq timer CPU ------------------------------------------------------- model name : Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz cpu MHz : 2001.000 model name : Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz cpu MHz : 2001.000 RAM ------------------------------------------------------- MemTotal: 1028132 kB SwapTotal: 3028212 kB Hardware -------------------------------------------------- 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03) does this sound familiar or is everybody blue in the face from hearing about this 'bug' :)? Best regards, Conor

3 5

[alsa-devel] The state of Digigram cards
by Mark Hills 23 Jan '08

23 Jan '08

Hi, I've been trying to use Digigram cards with ALSA using the drivers specific to these cards: * VX222 (detected as vx222/Old) * miXArt 8 Since about 1 year ago, I've tried both cards in various machines with various software configurations, and my experiences have ranged from complete system lockups to problems opening the device. Using more than one CPU seems to be a certain way to get system lockups. Is anybody actually using the Digigram drivers? Searching the various archives shows interest in the cards from a number of years ago. Is it possible that more recent developments to ALSA and the kernel cause the drivers to be unstable? Thanks, Mark

1 0

[alsa-devel] S16_LE + softvol = bad
by Alexander E. Patrakov 23 Jan '08

23 Jan '08

Hello developers, some cards (most notably, Intel HD audio) have the PCM control as softvol, and default to S16_LE as a format for dmix. Since softvol is configured to attenuate signal, and not many people set this control to 100% (especially those who have no other volume controls), this effectively leaves less than 16 bits per sample. The card can surely produce sound of better quality in most cases, if one changes defaults.pcm.dmix.format in ~/.asoundrc. However, one should now search a lot of forums in order to know about this setting. Not everyone does this, and not everyone is even able to diagnose the "noisy sound in Linux" problem properly as "too few bits per sample in the default configuration". A much better situation would be if ALSA defaulted to good quality (i.e.: S24_LE or S32_LE on all cards that require softvol and support this sample format). Could you please change the files in /usr/share/alsa/cards accordingly? -- Alexander E. Patrakov

3 7