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

[alsa-devel] ALC268 "test" model
by Marco Schuster 28 Dec '07

28 Dec '07

Hi all, I try to use a patch from J. Woithe to put a test model into the ALC268 driver [1] (enabling all pins etc.); unfortunately it gives a lot of compiling errors ([2]) which I am unable to understand as I don't have sufficient knowledge of the internal API of HDA codec. Can someone please look over it and correct the mistakes? Marco Schuster [1]: http://harddisk.is-a-geek.org/patch.txt [2]: http://harddisk.is-a-geek.org/compiling-errors.txt

2 1

[alsa-devel] snd-hda-intel driver on sony VGN TZ11MN
by Jonathan Coe 26 Dec '07

26 Dec '07

The sound appears to play using audio players but no sound comes out of the speakers. Plugging in headphones and removing them leads to sound coming out of the speakers. This behaviour can be corrected by passing suitable parameters to the driver module. _From lspci: Subsystem: 104d:900e Arguments added to /etc/modprobe.d/sound: options snd-hda-intel model=hippo I hope this is all the information you need to get this working. If not please email and I'll be happy to help if I can. kind regards, Jon

2 1

[alsa-devel] doc update for http://bugtrack.alsa-project.org/main/index.php/Matrix:Vendor-Intel
by Paul Winkler 24 Dec '07

24 Dec '07

Hi, The page at http://bugtrack.alsa-project.org/main/index.php/Matrix:Vendor-Intel makes it seem that cards identified as ICH7 must use the hda_intel driver. This is apparently not always true. I have a dell desktop where snd_hda_intel refuses to load. I fired up alsaconf and it suggested using the intel8x0. I tried that and it works fine. So maybe ICH7 should be added to "chipsets" in the first row on that page. Thanks, - Paul Winkler p.s. here's some system info: pw@pw ~ $ lspci | grep audio 00:1e.2 Multimedia audio controller: Intel Corporation 82801G (ICH7 Family) AC'97 Audio Controller (rev 01) pw@pw ~ $ cat /proc/asound/cards 0 [ICH7 ]: ICH4 - Intel ICH7 Intel ICH7 with AD1981B at irq 23 pw@pw ~ $ lsmod | grep snd snd_intel8x0 27176 0 snd_ac97_codec 90456 1 snd_intel8x0 ac97_bus 4224 1 snd_ac97_codec snd_pcm 60808 2 snd_intel8x0,snd_ac97_codec snd_timer 18440 1 snd_pcm snd 38192 4 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer snd_page_alloc 8976 2 snd_intel8x0,snd_pcm

2 3

Re: [alsa-devel] [PATCH]Device ID for Toshiba laptop which uses AD1986A
by Jiang zhe 24 Dec '07

24 Dec '07

On Fri, 2007-12-21 at 21:39 +0200, Andy Shevchenko wrote: > Hi Jiang zhe! > > On Thu, Dec 20, 2007 at 09:44:14AM +0800, Jiang zhe wrote next: > > > @@ -859,6 +859,7 @@ static struct snd_pci_quirk ad1986a_cfg_ > > SND_PCI_QUIRK(0x17aa, 0x1017, "Lenovo A60", AD1986A_3STACK), > > SND_PCI_QUIRK(0x17aa, 0x2066, "Lenovo N100", AD1986A_LAPTOP_AUTOMUTE), > > SND_PCI_QUIRK(0x17c0, 0x2017, "Samsung M50", AD1986A_LAPTOP), > > + SND_PCI_QUIRK(0x1179, 0xff40, "Toshiba", AD1986A_LAPTOP_EAPD), > > {} > > }; > Please, keep list sorted by PCI SSID. > Thank you very much! ^_^ --- alsa-driver-hg20071224/alsa-kernel/pci/hda/patch_analog.c 2007-12-21 09:00:06.000000000 +0800 +++ b/alsa-kernel/pci/hda/patch_analog.c 2007-12-24 10:07:54.000000000 +0800 @@ -848,6 +848,7 @@ static struct snd_pci_quirk ad1986a_cfg_ SND_PCI_QUIRK(0x1043, 0x81cb, "ASUS M2N", AD1986A_3STACK), SND_PCI_QUIRK(0x1043, 0x8234, "ASUS M2N", AD1986A_3STACK), SND_PCI_QUIRK(0x10de, 0xcb84, "ASUS A8N-VM", AD1986A_3STACK), + SND_PCI_QUIRK(0x1179, 0xff40, "Toshiba", AD1986A_LAPTOP_EAPD), SND_PCI_QUIRK(0x144d, 0xb03c, "Samsung R55", AD1986A_3STACK), SND_PCI_QUIRK(0x144d, 0xc01e, "FSC V2060", AD1986A_LAPTOP), SND_PCI_QUIRK(0x144d, 0xc023, "Samsung X60", AD1986A_LAPTOP_EAPD), @@ -859,7 +860,6 @@ static struct snd_pci_quirk ad1986a_cfg_ SND_PCI_QUIRK(0x17aa, 0x1017, "Lenovo A60", AD1986A_3STACK), SND_PCI_QUIRK(0x17aa, 0x2066, "Lenovo N100", AD1986A_LAPTOP_AUTOMUTE), SND_PCI_QUIRK(0x17c0, 0x2017, "Samsung M50", AD1986A_LAPTOP), - SND_PCI_QUIRK(0x1179, 0xff40, "Toshiba", AD1986A_LAPTOP_EAPD), {} };

1 0

[alsa-devel] Gadget Labs Linux Alsa driver is coming!! (and you are invited)
by Mike Mazarick 24 Dec '07

24 Dec '07

There is a recently revitalized project to create an alsa linux driver for the Gadget Labs series of cards. http://sourceforge.net/projects/wavepro-driver/ There is an active mailing list of the developers, testers, and interested parties who are helping located here: wavepro-driver-developers(a)lists.sourceforge.net It is recommended that if you are interested in reading the progress of this effort, that you subscribe soon because the mailing list will go 'private' around the middle of January (to keep out spam and other unwanted intrusions). The end goal of this project is to have the driver included in the alsa distribution and eventually into the linux distributions so that owners of this card can simply have the card installed in their system and all the necessary steps will be done automatically by the installation, as is the case with SoundBlasters, onboard sound cards, Delta 1010s, RME 9652s, etc. Having a working driver is several months away from now, and the developers who are helping write this are quite good, however, we are all inexperienced at creating drivers for linux and are unsure of the needed steps to get it included in the Alsa tree. We are also very receptive to any advice or help with the creation of this driver; feel free to sign up and be a part of this project. We have a major advantage because there is already a Windows driver available with source (including new FPGA firmware), which was developed after the Gadget Labs company went under. Best wishes (and happy holidays!!) Mike Mazarick

2 1

[alsa-devel] [lennart@poettering.net: Status of ALSA "simple" mixer interface]
by Lennart Poettering 23 Dec '07

23 Dec '07

Hi! A few days ago I sent the attached emails to Takashi and filed a couple of bugs on the ALSA BTS. Takashi suggested to post these issues on the ML as well, to allow public discussion. So, here we go. The relevant bugs are: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3570 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3569 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3568 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3572 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3571 Lennart

5 36

[alsa-devel] [PATCH] PulseAudio plugin: report XRUN state back to application
by Lennart Poettering 23 Dec '07

23 Dec '07

Hi! Please consider merging this patch we ship in Fedora: http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/alsa-plugins/1.0.14-s… It adds support to report back XRUN to the application if one happens. This is required to make some applications work on top of the pulse plugin. One being XMMS, which checks if a song finished to play by waiting for an XRUN (yes, I don't argue that XMMS shouldn't do that, but nonetheless it is a good thing if XRUNs are reported properly.) Now, this patch is a bit problematic, since it touches pcm->io.state which is not supposed to be touched by ioplug-based plugins -- according to the comments in ioplug. However, I saw no other way to fix this, and from judging the ioplug code overwriting the variable should be safe. Thus I decided to simply touch the variable but documented it in a comment. Alternatively, ioplug could be beefed up to properly handle XRUNs, but I thought this fix is simpler. Also reported on the ALSA BTS: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3579 Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

2 2

[alsa-devel] write/read system calls and ioctl
by Michael Voigt 22 Dec '07

22 Dec '07

Dear ALSA developers, At the beginning, I would like to give a short introdution of myself, then my question follows. My project: =============== Currently, I am interning at the TU Dresden operating systems group's [1] and it is my task to port ALSA to DROPS [2, 3], a L4-microkernel-based real-time system. The long-term goal of this project should be to establish a truely real-time capable FOSS platform for audio recording and processing. The current state of the project: By using DDELinux [4] and writing a small kernel-user inferface emulation layer, we now have an unchanged version of ALSA and an unchanged version of salsa-lib [5] running on our system. The next steps will be to test how stable this port is and fix bugs. Then, during my diploma thesis, it is my task to port Jack (or an equivalent) to our system and to evaluate how to make the whole thing to work in real-time. But now my question: =============== In the file pcm_native in alsa-core read (snd_pcm_read) and write (snd_pcm_write) functions are attached to the snd_pcm_f_ops. But as far as I can see, these write- und read- system calls aren't used either in salsa-lib or in alsa-lib. I can see that in former versions of alsa-lib (for instance alsalib-0.0.3) the write system call was used to implement snd_pcm_write (LIB); but now we have snd_pcm_writei (LIB) and snd_pcm_writen (LIB) which use ioctl. I guess this was done to realize both interleaved and noninterleaved audio playback (The old snd_pcm_write (LIB) was based on bytes not on frames and did not have a notion of interleaved/noninterleaved playback?). If I have a look at snd_pcm_write (KERNEL, pcm_native.c), I can see it also ends up in snd_pcm_lib_write(...). So does ioctl with SNDRV_PCM_IOCTL_WRITEI_FRAMES as argument, but snd_pcm_write (KERNEL) does not copy the frames to kernel memory. My question: what is snd_pcm_write in pcm_native.c good for? Is it only there to keep ALSA compatible to older versions of alsa-lib? Kindest regards, Michael Voigt ================ [1] http://www.inf.tu-dresden.de/index.php?node_id=1141&ln=en [2] http://www.osnews.com/story.php/15814/Introduction-to-TUD-OS/ [3] http://www.realtimelinuxfoundation.org/variants/variants.html#VARIANTS_DROPS [4] http://demo.tudos.org/dsweeper_tutorial.html [5] http://ftp.isr.ist.utl.pt/pub/MIRRORS/ftp.suse.com/people/tiwai/salsa-lib/ ================ -- Today is Pungenday, the 61st day of The Aftermath in the YOLD 3173

2 2

Re: [alsa-devel] snd-hda-intel support for SPDIF-in wiht vt1708 card?
by forumjunk＠comcast.net 22 Dec '07

22 Dec '07

Well, I spoke too soon... with or without the via patch, I now get an error from the driver about an inappropriate ioctl for the device while KDE is trying to start the sound system. On a command line, madplay and aplay return this: #> aplay /usr/share/sounds/KDE_Glass_Break.ogg #> ALSA lib pcm_dmix.c:866:(snd_pcm_dmix_open) unable to open slave #> aplay: main:546: audio open error: Device or resource busy #> aplay /usr/share/sounds/pop.wav #> ALSA lib pcm_dmix.c:866:(snd_pcm_dmix_open) unable to open slave #> aplay: main:546: audio open error: Device or resource busy #> madplay /usr/share/sounds/KDE_Glass_Break.ogg #> MPEG Audio Decoder 0.15.2 (beta) - Copyright © 2000-2004 Robert Leslie et al. #> audio: /dev/dsp: Device or resource busy #> madplay /usr/share/sounds/pop.wav #> MPEG Audio Decoder 0.15.2 (beta) - Copyright © 2000-2004 Robert Leslie et al. #> audio: /dev/dsp: Device or resource busy alsaconf correctly detects the VT1708, and alsamixer and alsactl all seem to work correctly. I've tried obtaining and installing the latest mercurial clone of alsa-lib, and I've tried this with or without the patch_via.c patch below. Am I doing something wrong? -- Darryl -------------- Original message ---------------------- From: forumjunk(a)comcast.net (Darryl House) > The patch fixed all compilation errors for me, thank you. I did have to apply it > manually, but that was rather simple. > > I can confirm that SPDIF input doesn't work for the card, but I haven't applied > the patch that you suggested to John Stile for that, yet. I'll do that a bit > later today if you still recommend it > > Is this patch still recommended? > > > diff -r 2d3893cf030c pci/hda/patch_via.c > > --- a/pci/hda/patch_via.c Tue Dec 18 15:42:53 2007 +0100 > > +++ b/pci/hda/patch_via.c Tue Dec 18 17:48:00 2007 +0100 > > @@ -568,25 +568,27 @@ static int via_init(struct hda_codec *co > > if (IS_VT1708_VENDORID(codec->vendor_id)) { > > snd_hda_codec_write(codec, VT1708_DIGIN_PIN, 0, > > AC_VERB_SET_PIN_WIDGET_CONTROL, > > - 0x40); > > + PIN_OUT); > > snd_hda_codec_write(codec, VT1708_DIGIN_PIN, 0, > > AC_VERB_SET_EAPD_BTLENABLE, 0x02); > > } else if (IS_VT1709_10CH_VENDORID(codec->vendor_id) || > > IS_VT1709_6CH_VENDORID(codec->vendor_id)) { > > snd_hda_codec_write(codec, VT1709_DIGIN_PIN, 0, > > AC_VERB_SET_PIN_WIDGET_CONTROL, > > - 0x40); > > + PIN_OUT); > > snd_hda_codec_write(codec, VT1709_DIGIN_PIN, 0, > > AC_VERB_SET_EAPD_BTLENABLE, 0x02); > > } else if (IS_VT1708B_8CH_VENDORID(codec->vendor_id) || > > IS_VT1708B_4CH_VENDORID(codec->vendor_id)) { > > snd_hda_codec_write(codec, VT1708B_DIGIN_PIN, 0, > > AC_VERB_SET_PIN_WIDGET_CONTROL, > > - 0x40); > > + PIN_OUT); > > snd_hda_codec_write(codec, VT1708B_DIGIN_PIN, 0, > > AC_VERB_SET_EAPD_BTLENABLE, 0x02); > > } > > - } > > + } else /* enable SPDIF-input pin */ > > + snd_hda_codec_write(codec, spec->autocfg.dig_in_pin, 0, > > + AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN); > > > > return 0; > > } > > Thanks again! > > -- Darryl > > > -------------- Original message ---------------------- > From: Takashi Iwai <tiwai(a)suse.de> > [...] > > Thanks. Does the patch below fix the probelm? > > Run hgcompile after applying it. > > > > > > Takashi > > > > diff -r 414b1156a8b3 configure.in > > --- a/configure.in Tue Dec 18 16:09:20 2007 +0100 > > +++ b/configure.in Fri Dec 21 12:10:53 2007 +0100 > > @@ -1230,7 +1230,7 @@ esac > > > > dnl set ia32 (X86) > > case "$processor" in > > - i?86*|k?|crusoe|mcyrixiii|mwinchip|viac3_2|mcore2|geodegx*) > > + i?86*|k?|crusoe|mcyrixiii|mwinchip|viac3_2|mcore2|geodegx*|x86_32) > > if $KCC -mpreferred-stack-boundary=2 -S -o /dev/null -xc /dev/null > > >/dev/null 2>&1; then > > c_opts="-mpreferred-stack-boundary=2 $c_opts" > > CONFIG_X86=y > > _______________________________________________ > > Alsa-devel mailing list > > Alsa-devel(a)alsa-project.org > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

1 0

Re: [alsa-devel] snd-hda-intel support for SPDIF-in wiht vt1708 card?
by forumjunk＠comcast.net 21 Dec '07

21 Dec '07

The patch fixed all compilation errors for me, thank you. I did have to apply it manually, but that was rather simple. I can confirm that SPDIF input doesn't work for the card, but I haven't applied the patch that you suggested to John Stile for that, yet. I'll do that a bit later today if you still recommend it Is this patch still recommended? > diff -r 2d3893cf030c pci/hda/patch_via.c > --- a/pci/hda/patch_via.c Tue Dec 18 15:42:53 2007 +0100 > +++ b/pci/hda/patch_via.c Tue Dec 18 17:48:00 2007 +0100 > @@ -568,25 +568,27 @@ static int via_init(struct hda_codec *co > if (IS_VT1708_VENDORID(codec->vendor_id)) { > snd_hda_codec_write(codec, VT1708_DIGIN_PIN, 0, > AC_VERB_SET_PIN_WIDGET_CONTROL, > - 0x40); > + PIN_OUT); > snd_hda_codec_write(codec, VT1708_DIGIN_PIN, 0, > AC_VERB_SET_EAPD_BTLENABLE, 0x02); > } else if (IS_VT1709_10CH_VENDORID(codec->vendor_id) || > IS_VT1709_6CH_VENDORID(codec->vendor_id)) { > snd_hda_codec_write(codec, VT1709_DIGIN_PIN, 0, > AC_VERB_SET_PIN_WIDGET_CONTROL, > - 0x40); > + PIN_OUT); > snd_hda_codec_write(codec, VT1709_DIGIN_PIN, 0, > AC_VERB_SET_EAPD_BTLENABLE, 0x02); > } else if (IS_VT1708B_8CH_VENDORID(codec->vendor_id) || > IS_VT1708B_4CH_VENDORID(codec->vendor_id)) { > snd_hda_codec_write(codec, VT1708B_DIGIN_PIN, 0, > AC_VERB_SET_PIN_WIDGET_CONTROL, > - 0x40); > + PIN_OUT); > snd_hda_codec_write(codec, VT1708B_DIGIN_PIN, 0, > AC_VERB_SET_EAPD_BTLENABLE, 0x02); > } > - } > + } else /* enable SPDIF-input pin */ > + snd_hda_codec_write(codec, spec->autocfg.dig_in_pin, 0, > + AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN); > > return 0; > } Thanks again! -- Darryl -------------- Original message ---------------------- From: Takashi Iwai <tiwai(a)suse.de> [...] > Thanks. Does the patch below fix the probelm? > Run hgcompile after applying it. > > > Takashi > > diff -r 414b1156a8b3 configure.in > --- a/configure.in Tue Dec 18 16:09:20 2007 +0100 > +++ b/configure.in Fri Dec 21 12:10:53 2007 +0100 > @@ -1230,7 +1230,7 @@ esac > > dnl set ia32 (X86) > case "$processor" in > - i?86*|k?|crusoe|mcyrixiii|mwinchip|viac3_2|mcore2|geodegx*) > + i?86*|k?|crusoe|mcyrixiii|mwinchip|viac3_2|mcore2|geodegx*|x86_32) > if $KCC -mpreferred-stack-boundary=2 -S -o /dev/null -xc /dev/null > >/dev/null 2>&1; then > c_opts="-mpreferred-stack-boundary=2 $c_opts" > CONFIG_X86=y > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

1 0