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

[alsa-devel] [PATCH] Add mute support to FM-only card with FM801 PCI to tuner bridge
by Andy Shevchenko 24 Jan '08

24 Jan '08

Hi! This is improvement of the early support of the FM-only cards where the fm801 chip represents the PCI to tuner bridge. The tuner initialization isn't included the mute on as well as mute support via V4L request. Proposed patch should fix this at least for 64-PCR model. Signed-off-by: Andy Shevchenko <andy(a)smile.org.ua> --- alsa-driver-hg20080124/alsa-kernel/i2c/other/tea575x-tuner.c.mute-fix 2008-01-09 03:00:14.000000000 +0200 +++ alsa-driver-hg20080124/alsa-kernel/i2c/other/tea575x-tuner.c 2008-01-24 16:58:25.000000000 +0200 @@ -53,6 +53,9 @@ MODULE_LICENSE("GPL"); #define TEA575X_BIT_DUMMY (1<<15) /* buffer */ #define TEA575X_BIT_FREQ_MASK 0x7fff +#define TEA575X_UNMUTE 0 /* just FALSE */ +#define TEA575X_MUTE 1 /* just TRUE */ + /* * lowlevel part */ @@ -158,6 +161,10 @@ static int snd_tea575x_ioctl(struct inod struct video_audio v; if(copy_from_user(&v, arg, sizeof(v))) return -EFAULT; + if (v.flags & VIDEO_AUDIO_MUTE) + tea->ops->mute(tea, TEA575X_MUTE); + else + tea->ops->mute(tea, TEA575X_UNMUTE); if(v.audio) return -EINVAL; return 0; @@ -205,6 +212,9 @@ void snd_tea575x_init(struct snd_tea575x tea->freq = 90500 * 16; /* 90.5Mhz default */ snd_tea575x_set_freq(tea); + + /* mute on init */ + tea->ops->mute(tea, TEA575X_MUTE); } void snd_tea575x_exit(struct snd_tea575x *tea) --- alsa-driver-hg20080124/alsa-kernel/pci/fm801.c.mute-fix 2008-01-09 03:00:15.000000000 +0200 +++ alsa-driver-hg20080124/alsa-kernel/pci/fm801.c 2008-01-24 17:02:17.000000000 +0200 @@ -802,6 +802,11 @@ static unsigned int snd_fm801_tea575x_25 return val; } +static void snd_fm801_tea575x_256pcs_mute(struct snd_tea575x *tea, unsigned int mute) +{ + /* TODO: Should be implemented */ +} + /* 256PCPR GPIO numbers */ #define TEA_256PCPR_BUS_CLOCK 0 #define TEA_256PCPR_DATA 1 @@ -890,6 +895,11 @@ static unsigned int snd_fm801_tea575x_25 return val; } +static void snd_fm801_tea575x_256pcpr_mute(struct snd_tea575x *tea, unsigned int mute) +{ + /* TODO: Should be implemented */ +} + /* 64PCR GPIO numbers */ #define TEA_64PCR_BUS_CLOCK 0 #define TEA_64PCR_WRITE_ENABLE 1 /* inverted */ @@ -978,21 +988,42 @@ static unsigned int snd_fm801_tea575x_64 return val; } +static void snd_fm801_tea575x_64pcr_mute(struct snd_tea575x *tea, unsigned int mute) +{ + struct fm801 *chip = tea->private_data; + unsigned short reg; + + spin_lock_irq(&chip->reg_lock); + + reg = inw(FM801_REG(chip, GPIO_CTRL)); + if (mute) + reg &= ~FM801_GPIO_GP(TEA_64PCR_WRITE_ENABLE); // 0xf800 (mute) + else + reg |= FM801_GPIO_GP(TEA_64PCR_WRITE_ENABLE); // 0xf802 (unmute) + outw(reg, FM801_REG(chip, GPIO_CTRL)); + udelay(1); + + spin_unlock_irq(&chip->reg_lock); +} + static struct snd_tea575x_ops snd_fm801_tea_ops[3] = { { /* 1 = MediaForte 256-PCS */ .write = snd_fm801_tea575x_256pcs_write, .read = snd_fm801_tea575x_256pcs_read, + .mute = snd_fm801_tea575x_256pcs_mute, }, { /* 2 = MediaForte 256-PCPR */ .write = snd_fm801_tea575x_256pcpr_write, .read = snd_fm801_tea575x_256pcpr_read, + .mute = snd_fm801_tea575x_256pcpr_mute, }, { /* 3 = MediaForte 64-PCR */ .write = snd_fm801_tea575x_64pcr_write, .read = snd_fm801_tea575x_64pcr_read, + .mute = snd_fm801_tea575x_64pcr_mute, } }; #endif --- alsa-driver-hg20080124/alsa-kernel/include/tea575x-tuner.h.mute-fix 2007-10-16 03:00:12.000000000 +0300 +++ alsa-driver-hg20080124/alsa-kernel/include/tea575x-tuner.h 2008-01-24 16:58:25.000000000 +0200 @@ -30,6 +30,7 @@ struct snd_tea575x; struct snd_tea575x_ops { void (*write)(struct snd_tea575x *tea, unsigned int val); unsigned int (*read)(struct snd_tea575x *tea); + void (*mute)(struct snd_tea575x *tea, unsigned int mute); }; struct snd_tea575x { -- With best regards, Andy Shevchenko. mailto: andy(a)smile.org.ua

2 1

[alsa-devel] Problems with ALC882
by Christophe Osuna 24 Jan '08

24 Jan '08

Hi, I am having a bad time trying to get an ALC882 [1] to work. I hope that you can help me. Currently I am using alsa-driver-1.0.14 but it would probably be the same with 1.0.15 since there has been no change in /pci/hda/. The ALC882 has got three ADC, and for every one of them it is possible to select one input source. amixer shows my current settings: ~# amixer get 'Input Source',0 Simple mixer control 'Input Source',0 Capabilities: enum Items: 'Mic' 'Front Mic' 'Line' 'CD' Item0: 'Mic' ~# amixer get 'Input Source',1 Simple mixer control 'Input Source',1 Capabilities: enum Items: 'Mic' 'Front Mic' 'Line' 'CD' Item0: 'Front Mic' ~# amixer get 'Input Source',2 Simple mixer control 'Input Source',2 Capabilities: enum Items: 'Mic' 'Front Mic' 'Line' 'CD' Item0: 'Line' Put more simply: Mic -> Input 0 (1st ADC) Front Mic -> Input 1 (2nd ADC) Line In -> Input 2 (3rd ADC) A grep in the proc filesystem shows that there are three ADC and one digital input. ~# cat /proc/asound/card0/codec\#2 | grep Input Node 0x07 [Audio Input] wcaps 0x10011b: Stereo Amp-In Node 0x08 [Audio Input] wcaps 0x10011b: Stereo Amp-In Node 0x09 [Audio Input] wcaps 0x10011b: Stereo Amp-In Node 0x0a [Audio Input] wcaps 0x100391: Stereo Digital So far, so good. But then I try to use the PCM system and things start to go worse. ~# cat /proc/asound/pcm 00-02: ALC882 Analog : ALC882 Analog : capture 2 00-01: ALC882 Digital : ALC882 Digital : playback 1 : capture 1 00-00: ALC882 Analog : ALC882 Analog : playback 1 : capture 2 If my ALSA understanding is right, that means I have two analog input devices (hw:0,0 and hw:0,2). One is missing! If I ask arecord to list the capture devices, it shows the following: ~# ./arecord -l **** List of CAPTURE Hardware Devices **** card 0: Intel [HDA Intel], device 0: ALC882 Analog [ALC882 Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 card 0: Intel [HDA Intel], device 1: ALC882 Digital [ALC882 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 2: ALC882 Analog [ALC882 Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 I have tried to pipe arecord into aplay several times: 1) arecord -f dat -D hw:0,0,0 | aplay -f dat -D hw:0,0,0 2) arecord -f dat -D hw:0,0,1 | aplay -f dat -D hw:0,0,0 3) arecord -f dat -D hw:0,1,0 | aplay -f dat -D hw:0,0,0 (fails) 4) arecord -f dat -D hw:0,2,0 | aplay -f dat -D hw:0,0,0 5) arecord -f dat -D hw:0,2,1 | aplay -f dat -D hw:0,0,0 6) arecord -f dat -D hw:0,0,0 > /dev/null (fails) and arecord -f dat -D hw:0,2,0 > /dev/null (fails) and it shows that: 1) hw:0,0,0 maps to 1st ADC: OK 2) hw:0,0,1 maps to 2nd ADC: OK 3) fails probably because digital input is not activated 4) hw:0,2,0 maps to 1st ADC (same as hw:0,0,0) 5) hw:0,2,1 maps to 2nd ADC (same as hw:0,0,1) 6) when I start the second arecord the first stops (I/O error) and then the second one stops (error), probably because they are working on the same ADC. So it appears that while the "control" ALSA layer detects the 3 ADC the "PCM" layer does not. Do you have any idea of what could be wrong? Besides that I have another smaller problem. According to the ALC882 documentation, the codec can handle 8 kHz signals (by sending setting only one packet on every six packets of the HDA bus which operates at 48 kHz). However the driver will not let me use that sample rate. Example from /proc: Node 0x07 [Audio Input] wcaps 0x10011b: Stereo Amp-In Amp-In caps: ofs=0x08, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x14 0x14] PCM: rates [0x160]: 44100 48000 96000 bits [0x6]: 16 20 formats [0x1]: PCM Connection: 1 0x24 Is this a limit of the HDA implementation? Thanks for your help. [1] http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=28&Level…

3 12

[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