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

[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

[alsa-devel] no input/output analog channels on rme multiface I
by rmgls＠free.fr 21 Dec '07

21 Dec '07

Hi all, the multiface 1, does not work for me. it is recognized as hammerfal DSP, but the amixer shows no analog in/out (there are 8 analog I/O in the box) and of course no volume control for any channel. the driver: hg: 20071205, the last lib, and firmware, and utils. unpluging the box (power off), and loading the firmware on windows gives: in the debian (2.6.24-rc3) dmesg: e9652/../../alsa-kernel/pci/rme9652/hdsp.c:5037: Hammerfall-DSP: Firmware already present, initializing card. ... pcmcia: Detected deprecated PCMCIA ioctl usage from process: discover. pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools. pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details. sndstat reports: Xilinx FPGA ??? and now amixer -c2: Simple mixer control 'Line Out',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'IEC958 Emphasis Bit',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'IEC958 Input Connector',0 Capabilities: enum Items: 'Optical' 'Coaxial' 'Internal' Item0: 'Internal' Simple mixer control 'IEC958 Non-audio Bit',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'IEC958 Output also on ADAT1',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'IEC958 Professional Bit',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'ADAT Lock Status',1 Capabilities: enum Items: 'No Lock' 'Lock' 'Sync' Item0: 'No Lock' Simple mixer control 'ADAT Sync Lock Status',0 Capabilities: enum Items: 'No Lock' 'Lock' 'Sync' Item0: 'No Lock' Simple mixer control 'AutoSync Reference',0 Capabilities: enum Items: 'Word' 'ADAT Sync' 'IEC958' 'None' 'ADAT1' 'ADAT2' 'ADAT3' Item0: 'None' Simple mixer control 'External Rate',0 Capabilities: enum Items: '32000' '44100' '48000' '64000' '88200' '96000' 'None' Item0: 'None' Simple mixer control 'Preferred Sync Reference',0 Capabilities: enum Items: 'Word' 'IEC958' 'ADAT1' 'ADAT Sync' Item0: 'IEC958' Simple mixer control 'SPDIF Lock Status',0 Capabilities: enum Items: 'No Lock' 'Lock' 'Sync' Item0: 'No Lock' Simple mixer control 'SPDIF Sample Rate',0 Capabilities: enum Items: '32000' '44100' '48000' '64000' '88200' '96000' 'None' Item0: 'None' Simple mixer control 'Sample Clock Source',0 Capabilities: enum Items: 'AutoSync' 'Internal 32.0 kHz' 'Internal 44.1 kHz' 'Internal 48.0 kHz' 'Internal 64.0 kHz' 'Internal 88.2 kHz' 'Internal 96.0 kHz' Item0: 'Internal 44.1 kHz' Simple mixer control 'Sample Clock Source Locking',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off] Simple mixer control 'System Clock Mode',0 Capabilities: enum Items: 'Master' 'Slave' Item0: 'Master' Simple mixer control 'System Sample Rate',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 0 Mono: 0 [0%] Simple mixer control 'Word Clock Lock Status',0 Capabilities: enum Items: 'No Lock' 'Lock' 'Sync' Item0: 'No Lock' please do i miss something? thanks rmgls(a)free.fr

2 1

[alsa-devel] Userspace control of HDA port connections
by Andrew Paprocki 21 Dec '07

21 Dec '07

Takashi, I'm wondering if there is any interest in providing a userspace way of modifying the HDA port/mixer input/output mappings? The driver currently uses hard-coded models to define the standard configuration for a given piece of hardware, but this doesn't allow a user to redefine a line-in port as an output port if the chipset has an available unmapped mixer. I'm bringing this up because from what I understand of the ALC883 is that it has 4 mixers, yet on my motherboard there are only 3 ports configured as output by default (6stack-dig). Correct me if I'm wrong, but I should be able to map all of the physical jacks as outputs and then assign each of the mixers to a jack or more than one jack. That would require adding a new model to the driver and/or unloading/reloading the module with a new model string. In a system which has the driver built-in and isn't using modules, this requires a reboot. If there was a userspace way of reconfiguring the jacks (via /proc/asound?) then perhaps even all of the hardware -> model mappings could be moved into a little tool run at boot time which doesn't require a kernel change every time new hardware is introduced. A nice little ncurses tool could even be made to modify port mappings. What do you think? If I'm misunderstanding the capabilities of the chips please let me know. Thanks, -Andrew p.s. I still have yet to test out the multi-card patch. I'll reply to that once I have more info.

2 1