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

[alsa-devel] ALSA driver for Native Instruments sound hardware
by Daniel Mack 23 Mar '08

23 Mar '08

Hi, some months after the last posting, we finally managed to finish a new version of the ALSA driver for Native Instruments' external USB sound cards such as "Rig Kontrol 2", "Kore Kontroller", "Audio Kontrol 1" and "Audio 8 DJ". Compared to the last release, the following things were changed: - the streaming logic was completely reworked so that multiple substreams are handled correctly - a Linux input device layer was added to support the knobs, buttons and pedals on "Rig Kontrol 2" and "AudioKontrol 1" - workqueues were entirely removed from the code - most data structures are now allocated within one big struct to avoid multiple, smaller allocations - many more cleanups according to Clemens' reply on my last posting[1] The driver was properly tested with all the mentioned hardware on both record and playback channels. The patchset should apply to the current mecurial alsa-kernel tree. Please let me know what you think. Best regards, Daniel [1] http://article.gmane.org/gmane.linux.alsa.devel/34324/ Signed-off-by: Daniel Mack <daniel(a)caiaq.org> Signed-off-by: Karsten Wiese <fzu(a)wemgehoertderstaat.de>

4 10

[alsa-devel] ALC882 on Abit AW9D-MAX
by Dan Aloni 10 Jul '07

10 Jul '07

Hello, Yesterday I posted this bug in the bugtracker: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3013 I have received no reponse yet. I'd like to cooperate on solving this. Thanks, -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il

2 14

Re: [alsa-devel] Fwd: Problems with hda_intel, Santa Rosa, and suspend
by Takashi Iwai 09 Jul '07

09 Jul '07

At Mon, 25 Jun 2007 15:16:41 -0500, Matt Mullins wrote: > > On 6/25/07, Takashi Iwai <tiwai(a)suse.de> wrote: > > > Yes, single_cmd mode is used always. > > That's bad. > > I believe we have established that. What can I do about it? *Can* I > do anything about it? What functions should I start debugging? Has > this happened with other codecs before? What documentation will I > need or want other than the Intel HDA and STAC9205 specifications? Similar problems have been seen in some laptops, too. I vaguely remember that they need some ACPI-related boot options to fix it somehow. I think it's likely irrelevant with the codec chip, but rather a problem of the controller side. > I'm definitely willing to help work on this, as not many people have > this hardware. I'm just new to the sound system, so I'm still trying > to figure out what-calls-what. Takashi

3 10

[alsa-devel] [HDA Intel/STAC92xx] mic not working (retasking?)...
by Daniel J Blueman 08 Jul '07

08 Jul '07

With both 2.6.20 and 2.6.22 kernels on Ubuntu 7.04 on my Sony Vaio SZ240, I'm unable to get my mic connector working at any cost. Well, almost...reading from /dev/dsp, I do see a minute change from 127 for 126 or 128 if I tap my external mic. This would imply the jack-retasking feature of this darn STAC chipset, right? How can I change the jack retasking with the Intel HDA drivers or get further insight into this problem? Thanks in advance, Daniel --- [1] $ lspci -s0:1b.0 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 $ arecord -l **** List of CAPTURE Hardware Devices **** card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 $ amixer info Card default 'Intel'/'HDA Intel at 0xde400000 irq 22' Mixer name : 'SigmaTel CXD9872RD/K' Components : 'HDA:83847661 HDA:14f12bfa' Controls : 6 Simple ctrls : 5 $ amixer controls numid=2,iface=MIXER,name='Master Playback Switch' numid=1,iface=MIXER,name='Master Playback Volume' numid=6,iface=MIXER,name='PCM Playback Volume' numid=5,iface=MIXER,name='Capture Source' numid=4,iface=MIXER,name='Capture Switch' numid=3,iface=MIXER,name='Capture Volume' $ amixer scontrols Simple mixer control 'Master',0 Simple mixer control 'PCM',0 Simple mixer control 'Line',0 Simple mixer control 'Mic',0 Simple mixer control 'Capture',0 $ amixer contents numid=2,iface=MIXER,name='Master Playback Switch' ; type=BOOLEAN,access=rw------,values=2 : values=on,on numid=1,iface=MIXER,name='Master Playback Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=127,step=0 : values=66,66 numid=6,iface=MIXER,name='PCM Playback Volume' ; type=INTEGER,access=rw---RW-,values=2,min=0,max=255,step=0 : values=230,230 | dBscale-min=-51.00dB,step=0.20dB,mute=0 numid=5,iface=MIXER,name='Capture Source' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Line' ; Item #1 'Mic' : values=1 numid=4,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=2 : values=on,on numid=3,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=15,step=0 : values=15,15 | dBscale-min=0.00dB,step=1.50dB,mute=0 -- Daniel J Blueman

3 14

[alsa-devel] PCMCIA Audigy 2 broken in 2.6.21?
by Chuck Ebbert 04 Jul '07

04 Jul '07

Multiple users report the PCMCIA Audigy 2 adapter hangs the machine in 2.6.21 while it work OK in 2.6.20: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242208

3 3

[alsa-devel] SALSA-Lib: snd_pcm_hw_params fails with MMAP
by J. Scott Merritt 03 Jul '07

03 Jul '07

Dear List, Using SALSA-Lib 0.0.5 ... After calling snd_pcm_hw_params_set_access with an access mode of SND_PCM_ACCESS_MMAP_INTERLEAVED, the subsequent call to snd_pcm_hw_params returns a snd_strerror error code of "Invalid argument". This same program operates properly in the target environment (ARM PXA270) when compiled and linked with the standard ALSA LIB 1.0.13. Thanks, Scott.

2 2

[alsa-devel] roland synth sh-201
by carlo beccaria 03 Jul '07

03 Jul '07

hi all, with this change in usbquirks.h , i can use my synth roland sh-201 { /* Roland SH-201 */ USB_DEVICE(0x0582, 0x00ad), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .vendor_name = "Roland", .product_name = "SH-201", .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .format = SNDRV_PCM_FORMAT_S24_3LE, .channels = 2, .iface = 0, .altsetting = 1, .altset_idx = 1, .attributes = 0, .endpoint = 0x01, .ep_attr = 0x01, .rates = SNDRV_PCM_RATE_CONTINUOUS, .rate_min = 44100, .rate_max = 44100, } }, { .ifnum = 1, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .format = SNDRV_PCM_FORMAT_S24_3LE, .channels = 2, .iface = 1, .altsetting = 1, .altset_idx = 1, .attributes = 0, .endpoint = 0x81, .ep_attr = 0x01, .rates = SNDRV_PCM_RATE_CONTINUOUS, .rate_min = 44100, .rate_max = 44100, } }, { .ifnum = 2, .type = QUIRK_MIDI_FIXED_ENDPOINT, .data = & (const struct snd_usb_midi_endpoint_info) { .out_cables = 0x0007, .in_cables = 0x0007 } }, { .ifnum = -1 } } } }, my kernel is 2.6.21.5-rt17, (plus preempt patch) and i use debian testing the hardware seem to be very similar to Roland SC-D70 (windows .inf file are very similar) this is the device id Bus 001 Device 003: ID 0582:00ad Roland Corp. in attach you can see the lsusb (verbose) output becks@vaix:~$ amidi -l Dir Device Name IO hw:1,0,0 SH-201 MIDI 1 IO hw:1,0,1 SH-201 MIDI 2 IO hw:1,0,2 SH-201 MIDI 3 muse works fine with jack and midi output becks@vaix:~$ aseqdump -p 20:0 Waiting for data. Press Ctrl+C to end. Source_ Event_________________ Ch _Data__ 20:0 Note on 1 52 17 20:0 Note off 1 52 55 also midi-in works becks@vaix:~$ cat /proc/asound/cards 0 [A5451 ]: ALI5451 - ALI 5451 ALI 5451 at 0x8400, irq 9 1 [SH201 ]: USB-Audio - SH-201 Roland SH-201 at usb-0000:00:0c.0-1, full speed when i use my synth like a sound card, it don't work, i don't know exactly why (if is a patch problem, or rate/format) becks@vaix:~$ aplay -D hw:1,0 /usr/share/sounds/KDE_Window_UnSticky.wav Playing WAVE '/usr/share/sounds/KDE_Window_UnSticky.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono aplay: set_params:904: Sample format non available let me know if you need more info thanks -- carlo beccaria

2 4

[alsa-devel] [HDA-Intel/ALC268] no sound
by Steven Zakulec 02 Jul '07

02 Jul '07

(Continued from this thread: http://mailman.alsa-project.org/pipermail/alsa-devel/2007-June/001459.html) I've included the result of alsactl -f somefile store. I thought it got sent to the list earlier, but apparently not. Below this I also added the alsa things from dmesg. state.Intel { control.1 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 64' iface MIXER name 'Front Playback Volume' value.0 57 value.1 57 } control.2 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Front Playback Switch' value.0 true value.1 true } control.3 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 64' iface MIXER name 'Headphone Playback Volume' value.0 63 value.1 63 } control.4 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Headphone Playback Switch' value.0 true value.1 true } control.5 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' iface MIXER name 'Capture Volume' value.0 1 value.1 1 } control.6 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' value.0 false value.1 false } control.7 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' iface MIXER name 'Capture Volume' index 1 value.0 1 value.1 1 } control.8 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' index 1 value.0 false value.1 false } control.9 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Mic comment.item.1 'Front Mic' iface MIXER name 'Input Source' value Mic } control.10 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Mic comment.item.1 'Front Mic' iface MIXER name 'Input Source' index 1 value Mic } control.11 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Off-hook Switch' value false } control.12 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Caller ID Switch' value false } control.13 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 255' comment.tlv '0000000100000008ffffec1400000014' iface MIXER name 'PCM Playback Volume' value.0 255 value.1 255 } } hda_codec: Unknown model for ALC268, trying auto-probe from BIOS... [ 18.512000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/hda_codec.c:2339: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 18.512000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/hda_codec.c:2343: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 18.512000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/hda_codec.c:2347: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 18.512000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/hda_codec.c:2355: inputs: mic=0x19, fmic=0x18, line=0x0, fline=0x0, cd=0x0, aux=0x0 [ 19.236000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:244: si3054: cannot initialize. EXT MID = 0000 [ 19.244000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:256: Link Frame Detect(FDT) is not ready (line status: 0000) comment.count 2 :

2 1

[alsa-devel] [HDA Intel/STAC92xx] Alsa 1.0.14: error in stac92xx_auto_fill_dac_nid
by Jan de Mooij 02 Jul '07

02 Jul '07

I have a strange problem with alsa on Ubuntu Gutsy. If I compile and install the Alsa 1.0.14 driver, my sound card is not detected, and sound doesn't work. I also get the following message in dmesg: [ 33.360190] stac92xx_auto_fill_dac_nids: No available DAC for pin 0x15 So the problem seems to be in the stac92xx_auto_fill_dac_nids function. When I copy that function from alsa 1.0.13 into the 1.0.14 source, everything works okay... It looks like the function is rewritten for version 1.0.14, but for me it does not work anymore. I have to do the above steps with each new kernel update in Ubuntu Gutsy... Therefore I would like to fix it, but I don't know where to start. Thanks in advance. Jan

2 6

[alsa-devel] Acer Aspire 9810 hda-intel RealTek ALC883 no sound thru speakers only via SPDIF/Headphones.
by Adrian Grassi 02 Jul '07

02 Jul '07

Hi guys, I have a Acer Aspire 9810 with hda-intel realtek ALC883 chipset and no matter what version of alsa and ditribution I try I only get sound thru the shared SPDIF/Headphone Jack. This laptop has a built in 2.1 power speaker system which works fine under windows but not in any linux distro's I have tried: Ubuntu 7.04 - Kubuntu 7.04 - Suse 10.2 - Ubuntu Gutsy 7.10 Beta - Mandriva Spring 2007.1 I think this is a configuration issue however I can't find any info anywhere on how to fix it, I did find a few posts where several people are having the same issue. Can someone please shed some light on how to fix this issue, if any additional information is needed please let me know, I have been trying to solve this for over 5 days now and is driving me bananas. Here is the aadebug from alsa-wiki: Debug INFO ALSA Audio Debug v0.1.0 - Sat Jun 30 02:01:40 EDT 2007 http://alsa.opensrc.org/aadebug http://www.gnu.org/licenses/gpl.txt Kernel ---------------------------------------------------- Linux XTTG-Mob1 2.6.22-7-generic #1 SMP Mon Jun 25 17:33:14 GMT 2007 i686 GNU/Linux Loaded Modules -------------------------------------------- snd_hda_intel 256024 1 snd_pcm_oss 44672 0 snd_mixer_oss 17664 1 snd_pcm_oss snd_pcm 80388 3 snd_hda_intel,saa7134_alsa,snd_pcm_oss snd_seq_dummy 4740 0 snd_seq_oss 33152 0 snd_seq_midi 9600 0 snd_rawmidi 25728 1 snd_seq_midi snd_seq_midi_event 8448 2 snd_seq_oss,snd_seq_midi snd_seq 53232 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_timer 24324 2 snd_pcm,snd_seq snd_seq_device 9228 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq snd 54660 12 snd_hda_intel,saa7134_alsa,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device snd_page_alloc 10888 2 snd_hda_intel,snd_pcm 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.14 (Thu May 31 09:03:25 2007 UTC). 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xd2300000 irq 23 1 [SAA7134 ]: SAA7134 - SAA7134 saa7133[0] at 0xd2005000 irq 16 2: : timer 3: : sequencer 4: [ 1- 0]: digital audio capture 5: [ 1] : control 6: [ 0- 2]: digital audio capture 7: [ 0- 0]: digital audio playback 8: [ 0- 0]: digital audio capture 9: [ 0] : control cat: /proc/asound/hwdep: No such file or directory 01-00: SAA7134 PCM : SAA7134 PCM : capture 1 00-02: ALC883 Analog : ALC883 Analog : capture 2 00-00: ALC883 Analog : ALC883 Analog : playback 1 : capture 2 Client info cur clients : 3 peak clients : 3 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 Dev Snd --------------------------------------------------- controlC0 controlC1 pcmC0D0c pcmC0D0p pcmC0D2c pcmC1D0c seq timer CPU ------------------------------------------------------- model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz cpu MHz : 2000.000 model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz cpu MHz : 2000.000 RAM ------------------------------------------------------- MemTotal: 2074528 kB SwapTotal: 1951888 kB Hardware -------------------------------------------------- 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 09:04.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev d1) 09:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)

4 3

[alsa-devel] High-pitched noise on output from cmi9739 (snd_intel8x0)
by j t 02 Jul '07

02 Jul '07

Hi all. I have a cmi9739 (sis7012) built into an asus k7s8x motherboard which produces a quiet but noticeable noise on top of the regular output (the noise only occurs during playback). I logged a bug to alsa's bugtrack: (https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2288) about a year ago, but unfortunately I still have the problem with alsa release 1.0.14 To try to find out what's going on, I tried using seven (7) different drivers for this soundcard (both Linux and Windows XP) to find out when the problem occurs. Here's the results: a) Alsa (snd_intel8x0) version 1.0.14 under Ubuntu 7.10 alpha 2. Problem EXISTS. b) OSS 4Front Opensound v4.1 (v4.1test0-070624). Problem EXISTS c) CMedia Linux OSS driver cmaudio-070 (from http://www.cmedia.com.tw). Problem EXISTS. d) Windows XP "built-in" driver for SiS 7012 version 5.10.0.6120. Problem EXISTS. e) Windows XP drivers from Asus website for SiS 7012 version 5.12.1.38. Problem DOES NOT EXIST. f) Windows XP drivers from CMedia website (http://www.cmedia.com.tw) version 5.12.1.39. Problem DOES NOT EXIST. g) Windows XP drivers from CMedia forum (http://www.cmedia.com.tw/forums) version 5.12.1.51. Problem DOES NOT EXIST. Given that the problem does not happen with three out of the seven drivers, I assume it's a driver problem. Is there anything that I can do debug this further? Thank you.

2 1

[alsa-devel] NVidia AC97 / CK804: arecord hangs in system call poll()
by Rainer Menzner 02 Jul '07

02 Jul '07

Hi, my soundcard is an onboard AC97 CK804 NVidia. I use snd-intel8x0 module. Everything works fine except recording sound. When calling arecord -f cd buffer.wav the program infinitely hangs, and an strace shows that it is a poll() call that does not return. After interrupting, a wave file of 44 bytes which is the header only is left. My setup is Kernel 2.6.21.3, all ALSA-software is updated to the latest version, that is 1.0.14(a). In a previous setup with an older ALSA version and kernel 2.6.16.11 recording did work with the same hardware. Now that I updated all ALSA software, even with that older kernel version the same recording problem came up. From that I concluded that it is somehow related to the ALSA-lib version. I have tried to downgrade ALSA-lib down to 1.0.0 to no avail. I have also made tests appropriate if this would be an interrupt problem (using pci=noroute et al) which also did not solve the problem. I have scrolled though the archives of alsa-user and there have been a few posts regarding the same problem (but with other chip sets). However, in those threads no definitive solution of the problem has been discussed. So I tried it again in alsa-user but did not get any feedback ... Now, I finally try this developer list. Your comments and help are much appreciated. Let me know if you need further info. I'm not a Linux system programmer or specialist, but I would be willing to do some debugging if somebody explains what to check. Thanks for any support, -Rainer

2 2

[alsa-devel] hda-Intel Realtek ALC883 chipset support
by Adriano Grassi 30 Jun '07

30 Jun '07

Hi guys I have sound on different linux distro's however only the spdif/headphone share output, no sound from the internal speakers I have been trying to get this work for the last 5 days no success. So i was wondering if the support for this chipset is in place. I even tried the lastest candidate release alsa files 14rc4 with no luck, this is a high definition audio card with multiple outputs analog and digital and i have tried everything i can think of with no success, I tried multiple distro's with the same result, I don't this it is a driver issue is probably more like a configuration issue. Can anyone help me figure this one out. Thanks. 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xd2300000 irq 98 2: : timer 3: [ 0- 2]: digital audio playback 4: [ 0- 1]: digital audio capture 5: [ 0- 0]: digital audio playback 6: [ 0- 0]: digital audio capture 7: [ 0] : control 8: : sequencer cat: /proc/asound/Intel: Is a directory 0 snd_hda_intel cat: /proc/asound/oss: Is a directory 00-02: ALC883 Digital : ALC883 Digital : playback 1 00-01: ALC883 Analog : ALC883 Analog : capture 2 00-00: ALC883 Analog : ALC883 Analog : playback 1 : capture 2 cat: /proc/asound/seq: Is a directory G0: system timer : 4000.000us (10000000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE P0-0-3: PCM capture 0-0-3 : SLAVE P0-1-1: PCM capture 0-1-1 : SLAVE P0-1-3: PCM capture 0-1-3 : SLAVE P0-2-0: PCM playback 0-2-0 : SLAVE Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).

1 0

[alsa-devel] Digigram VX source code
by Colin Stewart Campbell 30 Jun '07

30 Jun '07

About 5 years ago Digigram released their VX soundcard source for OSX through the alsa project. Is there somewhere I can still get a hold of it? I have in mind a legacy card coreaudio driver for Intel macs. Colin

2 1

[alsa-devel] helping debugging
by Thierry Vignaud 30 Jun '07

30 Jun '07

Hi Here's a suggestion from Dave Airlie: http://airlied.livejournal.com/46087.html "If you are going to have lots of unsigned int sized free running pointers called things like hw_ptr or hw.ptr or anything, for debugging it would be really cool if you started those counters at INT_MAX-100000 or something instead of at zero, 24 hours waiting for a bug to trip in the pcm rate conversion is not fun and I'm guessing it'll be some stupid interger overflow or dumb boundary condition hitting..."

2 1

Re: [alsa-devel] Fwd: Problems with hda_intel, Santa Rosa, and suspend
by albox＠free.fr 30 Jun '07

30 Jun '07

Could this issue be related to the other one with Medion laptops : https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3160 Takashi, you said you were going to check the older patch that was working on ALSA 1.0.13, did you have a chance to do that ? Takashi Iwai wrote: > At Mon, 25 Jun 2007 15:16:41 -0500, > Matt Mullins wrote: >> On 6/25/07, Takashi Iwai <tiwai(a)suse.de> wrote: >>>> Yes, single_cmd mode is used always. >>> That's bad. >> I believe we have established that. What can I do about it? *Can* I >> do anything about it? What functions should I start debugging? Has >> this happened with other codecs before? What documentation will I >> need or want other than the Intel HDA and STAC9205 specifications? > > Similar problems have been seen in some laptops, too. I vaguely > remember that they need some ACPI-related boot options to fix it > somehow. I think it's likely irrelevant with the codec chip, but > rather a problem of the controller side. > >> I'm definitely willing to help work on this, as not many people have >> this hardware. I'm just new to the sound system, so I'm still trying >> to figure out what-calls-what. > > > Takashi > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > >

2 1

Re: [alsa-devel] Creative Soundblaster X-Fi
by Ash Willis 30 Jun '07

30 Jun '07

Hi all, Sorry for straying a little off topic, but talk of these couple of chips got me thinking about unsupported hardware in general. Does anyone know the legal implications of reverse engineering with regards to producing new drivers? I myself wouldn't mind reversing a certain chip or two but I'm not too aware of the legality of it all, particularly in the case where the vendor is hostile or unwilling to release chip information. In general, is it legally acceptable to reverse engineer for the purposes of interoperability? Are vendors likely to make a noise if their hardware gains support under Linux without or against their consent? or is it more a matter of protecting the original product specification than hiding details of the product's interface? Takashi, may I ask your thoughts on this? What's your position on accepting reverse engineered code? (Let's assume that the driver works as well as one written in a more correct manner ;)) I'm fully aware that uncooperative vendors don't deserve to have their hardware supported, but I think that Linux users and Linux itself deserves the support. Ash -- We've Got Your Name at http://www.mail.com! Get a FREE E-mail Account Today - Choose From 100+ Domains

3 2

[alsa-devel] [1/2] 2.6.22-rc6: known regressions v2
by Michal Piotrowski 29 Jun '07

29 Jun '07

Hi all, Here is a list of some known regressions in 2.6.22-rc6. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces Name Regressions fixed since 21-Jun-2007 Hugh Dickins 2 Andi Kleen 1 Björn Steinbrink 1 Bjorn Helgaas 1 Jean Delvare 1 Olaf Hering 1 Siddha, Suresh B 1 Trent Piepho 1 Ville Syrjälä 1 Unclassified Subject : Kernel hang on CMOS_READ References : http://lkml.org/lkml/2007/6/3/138 Submitter : Rodrigo Luiz <troops.of.doom(a)gmail.com> Status : Unknown ALSA Subject : snd-aoa causes badness in lib/kref.c:33 References : http://bugzilla.kernel.org/show_bug.cgi?id=8513 Submitter : Ben Collins <bcollins(a)ubuntu.com> Handled-By : Takashi Iwai <tiwai(a)suse.de> Status : Unknown FS Subject : 2.6.22-rc4-git5 reiserfs: null ptr deref. References : http://lkml.org/lkml/2007/6/13/322 Submitter : Randy Dunlap <randy.dunlap(a)oracle.com> Handled-By : Vladimir V. Saveliev <vs(a)namesys.com> Status : problem is being debugged IDE Subject : 2.6.22-rcX: hda: lost interrupt References : http://lkml.org/lkml/2007/6/29/121 Submitter : David Chinner <dgc(a)sgi.com> Status : unknown SATA/PATA Subject : libata IT821X driver still fails! Hard-freezes system References : http://lkml.org/lkml/2007/6/14/82 Submitter : Rodney Gordon II <meff(a)spherevision.org> Status : unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/

4 7

[alsa-devel] Creative Soundblaster X-Fi
by Tim Laszlo 29 Jun '07

29 Jun '07

Has anyone worked on developing an open source driver for the sound blaster x-fi cards? I've been sitting on one for about a year (mental note check support *before* buying..) and would love to use it already... Creative has promised drivers but they seem to be in no rush to support Linux. I'd like to try my hand at working on a driver for this, but without any technical specs from creative I wouldn't really know where to begin. Anyone have any suggestions on how to start? Anyone worked on this yet? Am I nuts for even considering this?? Timl

2 2

[alsa-devel] SALSA-Lib: Playback overrun on initial PCM start
by J. Scott Merritt 29 Jun '07

29 Jun '07

Dear List, Using SALSA-Lib 0.0.3, I call: snd_pcm_open (&playback_handle, argv[1], SND_PCM_STREAM_PLAYBACK, 0); snd_pcm_hw_params_malloc (&hw_params); snd_pcm_hw_params_any (playback_handle, hw_params); snd_pcm_hw_params_set_access (playback_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED); snd_pcm_hw_params_set_format (playback_handle, hw_params, SND_PCM_FORMAT_S16_LE)); snd_pcm_hw_params_set_rate_near (playback_handle, hw_params, 44100, 0); snd_pcm_hw_params_set_channels (playback_handle, hw_params, 2); snd_pcm_hw_params_set_buffer_size_last (playback_handle, hw_params, &bfrsize); snd_pcm_hw_params_get_buffer_size (hw_params, &bfrsize); snd_pcm_hw_params (playback_handle, hw_params); snd_pcm_hw_params_free (hw_params); snd_pcm_sw_params_malloc (&sw_params); snd_pcm_sw_params_current (playback_handle, sw_params); snd_pcm_sw_params_set_avail_min (playback_handle, sw_params, 4096); snd_pcm_sw_params_set_start_threshold (playback_handle, sw_params, 10000U); snd_pcm_sw_params_set_xfer_align (playback_handle, sw_params, 1); snd_pcm_sw_params (playback_handle, sw_params); state = snd_pcm_state (playback_handle); frames_to_deliver = snd_pcm_avail_update (playback_handle); while ((frames_to_deliver = snd_pcm_avail_update (playback_handle)) > 4096) { snd_pcm_writei (playback_handle, &buf, 4096) } As soon as the buffer start threshold is reached, or alternatively if I manually start PCM stream, the PCM stream reports an overrun (i.e. "Broken Pipe"). If I then examine the PCM state, it is in the overrun (XRUN) state. The code is being cross-compiled and tested on an ARM processor (PXA270) which is running linux kernel 2.6.21. This same code sequence -does- operate properly (in the same ARM test environment) when compiled against AlsaLib 1.0.13. Another apparent (and perhaps relevent) difference between AlsaLib and SALSA-Lib is that if I open the PCM stream with O_NONBLOCK and then call snd_pcm_poll_descriptors, AlsaLib gives me a FD = 4, whereas SALSA-Lib reports an FD = 3; Thanks, Scott.

3 8

Re: [alsa-devel] MOTU development
by Jonathan Woithe 29 Jun '07

29 Jun '07

Hi Per > I'd like to know more about the health on the connections to MOTU, if > they give any information about their products and how the development > has proceeded over the years. It kind of depends which MOTU devices you're asking about. There is, for example, an alsa driver for the MOTU Midi Timepiece AV (MTPAV) which presumedly makes the midi side of this available via the ALSA sequencer system. I can't speak for any of MOTU's PCI/PCIe cards. However, in connection with their more recent outboard interfaces MOTU have been, to put it mildly, extremely unhelpful. Some on the net go so far as to say they are hostile to Linux. The facts are that despite multiple people requesting information from MOTU on how to drive their firewire interfaces MOTU have responded every time with a very terse non-negotiable "no, never". I don't know if anyone's ever asked about their USB-equipped devices but I can't imagine the answer would be any different. Despite this, some progress is being made in supporting MOTU firewire devices under linux. For various reasons this support is not through ALSA but instead as part of the FFADO project. FFADO provides a userspace library for driving firewire audio devices in general and a JACK backend allowing such devices to be used by any jack-enabled software. An ALSA backend is planned but no work has been done towards this yet. Check out www.ffado.org for information on this project. Device support in FFADO varies. Some interfaces for which we have vendor support are doing very well, while supporting an interface such as the MOTUs without any documentation is challenging. However, the MOTU control protocol is pretty well understood at this point in time and it is possible to actually use the MOTU firewire devices for real work under Linux (as I have been for about 9 months now). The trap is that one needs to use an earlier revision of ffado at present. Back in February some key FFADO infrastructure changed. From before that until the last week or so I've been busy with production projects and so haven't had a chance to update the MOTU FFADO driver and restore its functionality. I'm back on the case now though and hope to make progress in the next month or so. If you want further details about all this please contact me off-list and I'll fill you in. Best regards jonathan

1 0

[alsa-devel] ALSA Application Programming Questions
by Paul Kavan 28 Jun '07

28 Jun '07

Hello all: I have been working on getting ALSA to work on my at91sam9260 with a simple voice codec for a few weeks. For the most part, I have my ARM board producing nice audio with aplay/arecord. Now I need a custom application that will allow me to create an 'intercom' like device with my ARM board. I am planning on writing the application as I do not think there is something out there that will accomplish what I want. I am really new to ALSA--as some of you know--and, as such, have never written an application for ALSA. I have found the ALSA driver api page on the alsa site. Wondering if there is any other good documentation on writing alsa applications? Any advice is greatly appreciated as well. One of my concerns is building the applications against the libs. I have the libs on my target machine. As my host machine has a version of my rfs on it, the libs are there as well. Just wondering how to accomplish cross-compiling new apps. I suppose I could copy the libs into the directory with my cross-compiling tools. Again, any advice would be great. Thanks. Paul -- *************************************** Paul David Kavan Project Engineer GRH Electronics, Inc. 402-734-4900 pkavan(a)gmail.com ***************************************

1 0

[alsa-devel] sound on SMDK2410 working
by Jose Henrique Spahn Torres 28 Jun '07

28 Jun '07

Hi all, I was able to get sound on smdk2410 to work. I can play .wav files with the following asound.conf file: /etc $ more asound.conf pcm.!default { type hw card 0 } ctl.!default { type hw card 0 } However the sound is distorted, in the sense that it sounds as played with a lower rate. I tried force a rate with -r 44100 or other rates, with no success. Can anyone point me to the right direction? Thanks, Henrique

1 0

[alsa-devel] SALSA-Lib: snd_pcm_hw_params_any clobbers memory
by J. Scott Merritt 28 Jun '07

28 Jun '07

Dear list, Using SALSA-Lib 0.0.2, I call snd_pcm_open snd_pcm_hw_params_malloc snd_pcm_hw_params_any The call to snd_pcm_hw_params_any appears to clobber memory beyond the end of the hw_params allocated by snd_pcm_hw_params_malloc (as reported by linking in -lmcheck). The code is being cross-compiled and tested on an ARM processor (PXA270) which is running linux kernel 2.6.21. This same code sequence -does- operate properly (in the same ARM test environment) when compiled against AlsaLib 1.0.13. I got "lost" somewhere around the hw_refine IOCTL .... Any suggestions appreciated :) Thanks, Scott.

2 2

[alsa-devel] MOTU development
by Per Eriksson 28 Jun '07

28 Jun '07

Dear list, My name is Per Eriksson, working as a musician with music and interactive content in Sweden. I'd like to know more about the health on the connections to MOTU, if they give any information about their products and how the development has proceeded over the years. I am thankful for any input. Best Regards Per Eriksson per(a)erinet.se

1 0

Re: [alsa-devel] [Pkg-alsa-devel] Bug#430833: libasound2: PCM plugin `lfloat' not built
by Elimar Riesebieter 28 Jun '07

28 Jun '07

forwarded 430833 alsa-devel(a)alsa-project.org -- On Wed, 27 Jun 2007 the mental interface of Mark Wooding told: > Package: libasound2 > Version: 1.0.14a-1 > Severity: normal > Tags: patch > > The PCM plugin `lfloat' isn't compiled into libasound. In particular, > this prevents the `plug' plugin from doing linear<->float conversion, > and in turn this means that hardly any ALSA clients can use the JACK > plugin from libasound2-plugins, because JACK uses FLOAT_LE format > throughout. > > The reason for this is quite simple: the configure script is broken! In > particular, the sense of the `softfloat' check used to decide whether to > disable the plugin is wrong! (That's aside from the question of whether > it's sensible to fail to build the thing just because it might be slow.) > We should solve this in general. It's not a Debian specific wish so forwarded upstream. > > Index: alsa-lib-1.0.14a/configure.in > =================================================================== > --- alsa-lib-1.0.14a.orig/configure.in 2007-06-27 16:24:58.000000000 > +0100 > +++ alsa-lib-1.0.14a/configure.in 2007-06-27 16:25:19.000000000 > +0100 > @@ -416,7 +416,7 @@ > build_pcm_share="no" > fi > > -if test "$softfloat" != "yes"; then > +if test "$softfloat" = "yes"; then > build_pcm_lfloat="no" > fi > > Index: alsa-lib-1.0.14a/configure > =================================================================== > --- alsa-lib-1.0.14a.orig/configure 2007-06-27 16:25:23.000000000 > +0100 > +++ alsa-lib-1.0.14a/configure 2007-06-27 16:25:38.000000000 +0100 > @@ -20946,7 +20946,7 @@ > build_pcm_share="no" > fi > > -if test "$softfloat" != "yes"; then > +if test "$softfloat" = "yes"; then > build_pcm_lfloat="no" > fi > > Elimar -- Experience is something you don't get until just after you need it!

2 1

[alsa-devel] Sound disappears after a long run, pcm_rate plugin maybe
by Dave Airlie 28 Jun '07

28 Jun '07

Hi, I've been debugging this bug which I first noticed close to a year ago but worked around by disabling dmix. Now I've had to enable dmix and try and fix it. My system is SDL on alsa-lib-1.0.13 on 2.6.21 on intel 810 with a Realtek ALC655. I'm using SDL to open a 22050 16-bit stereo stream, and dmix is set to 48000. When I run sound in my single app (only one app running for testing purposes) around 20-24 hours later (I haven't got exact timings as I can't sit in front of the pc for so long) the sound stop s happening just in that app. I can run aplay separately and it plays fine. If I stop my app (ctrl-C and cont in gdb) or attach/detach strace, I get an XRUN and my SDL code calls snd_pcm_prepare and the sounds comes back. Now I can't tell you how much it sucks to only get a single debugging run every 24 hours for 1 break point and if gdb stuffs it up you lose big time. I think I've tracked it down to pcm_rate.c as in if I open the sound card at 48000 instead of 22050 it doesn't happen and I've added a lot of printfs to the rate code in 1.0.13 and gotten huge log file traces of it.. In a normal rate trace when things are working I get traces like this: snd_pcm_rate_sync_playback_area: 442023720 442023720 525 986185728 snd_pcm_rate_sync_playback_area: 442023720 442023720 1549 986185728 snd_pcm_rate_sync_playback_area: 442023720 442023720 1549 986185728 snd_pcm_rate_sync_playback_area: 442024660 442023720 1549 986185728 snd_pcm_rate_commit_area: 6 940 1024 1881 snd_pcm_rate_sync_playback_area: 940 442023720 1881 snd_pcm_rate_sync_playback_area: 442024660 442024660 525 986185728 snd_pcm_rate_sync_playback_area: 442024660 442024660 1549 986185728 snd_pcm_rate_sync_playback_area: 442024660 442024660 1549 986185728 snd_pcm_rate_sync_playback_area: 442025595 442024660 1549 986185728 snd_pcm_rate_sync_playback_area: 442025600 442024660 1549 986185728 snd_pcm_rate_commit_area: 946 940 1024 1881 snd_pcm_rate_sync_playback_area: 940 442024660 1881 snd_pcm_rate_sync_playback_area: 442025600 442025600 525 986185728 snd_pcm_rate_sync_playback_area: 442025600 442025600 1549 986185728 snd_pcm_rate_sync_playback_area: 442025600 442025600 1549 986185728 snd_pcm_rate_sync_playback_area: 442026540 442025600 1549 986185728 snd_pcm_rate_commit_area: 5 940 1024 1881 snd_pcm_rate_sync_playback_area: 940 442025600 1881 snd_pcm_rate_sync_playback_area: 442026540 442026540 525 986185728 snd_pcm_rate_sync_playback_area: 442026540 442026540 1549 986185728 snd_pcm_rate_sync_playback_area: 442026540 442026540 1549 986185728 snd_pcm_rate_sync_playback_area: 442027476 442026540 1549 986185728 snd_pcm_rate_sync_playback_area: 442027480 442026540 1549 986185728 playback are debug code slave_size = snd_pcm_avail_update(slave); if (slave_size < 0) return slave_size; fprintf(stderr,"%s: %u %d %u %u\n", __func__, appl_ptr, rate->last_commit_ptr, slave_size, pcm->boundary); if (appl_ptr < rate->last_commit_ptr) xfer = appl_ptr - rate->last_commit_ptr + pcm->boundary; else xfer = appl_ptr - rate->last_commit_ptr; while (xfer >= pcm->period_size && (snd_pcm_uframes_t)slave_size >= rate->gen.slave->period_size) { err = snd_pcm_rate_commit_next_period(pcm, rate->last_commit_ptr % pcm->buffer_size); fprintf(stderr, "%s: %u %u %u\n", __func__, xfer, rate->last_commit_ptr, pcm->buffer_size); if (err == 0) commit area debug fprintf(stderr,"%s: %u %u %u %u\n", __func__, appl_offset, size, slave_size, pcm->buffer_size); areas = snd_pcm_mmap_areas(pcm); if (cont >= size) { In the not so good case (with different debug - two sites and I hadn't access to my debug code from one so I wrote it again) you get large numbers of snd_pcm_rate_sync_playback_area: 152605942 912 152385750 snd_pcm_rate_sync_playback_area: 152605942 912 152385750 snd_pcm_rate_sync_playback_area: 152606412 912 152385750 snd_pcm_rate_sync_playback_area: 152606412 912 152385750 snd_pcm_rate_sync_playback_area: 152606705 912 152385750 snd_pcm_rate_sync_playback_area: 152606882 912 152385750 snd_pcm_rate_sync_playback_area: 152606882 912 152385750 snd_pcm_rate_sync_playback_area: 152607352 912 152385750 snd_pcm_rate_sync_playback_area: 152607352 912 152385750 ...... snd_pcm_rate_sync_playback_area: 152769972 912 152385750 snd_pcm_rate_sync_playback_area: 152770381 1936 152385750 snd_pcm_rate_commit_area: 1411 572 470 snd_pcm_rate_sync_playback_area: 384631 1 1936 152385750 739770368 snd_pcm_rate_sync_playback_area: 152770442 912 152386220 .... more of these.... snd_pcm_rate_sync_playback_area: 152910502 912 152386220 snd_pcm_rate_sync_playback_area: 152910502 912 152386220 snd_pcm_rate_sync_playback_area: 152910972 912 152386220 snd_pcm_rate_sync_playback_area: 152910972 912 152386220 appl ptr is 152910972 recalc: 3022344724 1411 3072 470 1024 snd_pcm_rate_sync_playback_area: 152910972 1936 152386220 snd_pcm_rate_commit_area: 1411 1042 470 snd_pcm_rate_sync_playback_area: 524752 1 1936 152386220 739770368 snd_pcm_rate_sync_playback_area: 152910972 1936 152386690 snd_pcm_rate_commit_area: 1411 101 470 snd_pcm_rate_sync_playback_area: 524282 1 1936 152386690 739770368 snd_pcm_rate_sync_playback_area: 152910972 1936 152387160 ... this pattern repeats one commit per two playbacks until it goes back in the top... the debug code for these are recalc: fprintf(stderr,"%s: %lu %lu %lu %lu %lu\n", __func__, val, pcm->buffer_size, slave->buffer_size, pcm->period_size, slave->period_size); commit area areas = snd_pcm_mmap_areas(pcm); fprintf(stderr,"%s: %u %u %u\n", __func__, pcm->buffer_size, appl_offset, size); if (cont >= size) { playback area: fprintf(stderr,"%s: %u %d %d\n", __func__, appl_ptr, slave_size, rate->last_commit_ptr); if (appl_ptr < rate->last_commit_ptr) xfer = appl_ptr - rate->last_commit_ptr + pcm->boundary; else xfer = appl_ptr - rate->last_commit_ptr; while (xfer >= pcm->period_size && (snd_pcm_uframes_t)slave_size >= rate->gen.slave->period_size) { err = snd_pcm_rate_commit_next_period(pcm, rate->last_commit_ptr % pcm->buffer_size); fprintf(stderr,"%s: %u %d %d %u %u\n", __func__, xfer, err, slave_size, rate->last_commit_ptr, pcm->boundary); I'm hoping it is just some calculation in the rate plugin overflowing and I was blaming SDL but I've fixed up the codepaths to look like aplay and it still happened.. any hints would be appreciated on a) what that rate code is actually doing in the fail case, b) what the rate code is doing in the non-fail case :-) Dave.

2 1

[alsa-devel] SoC multiple streams
by Steve Longerbeam 28 Jun '07

28 Jun '07

Hi all, I'm developing an SoC driver for a sound engine that supports playing up to 64 simultaneous substreams, all mixed in h/w to a stereo DAC. But it doesn't appear that the SoC framework supports multiple substreams, according to soc_new_pcm(). Am I missing something, or is this on the asoc development roadmap? Thanks, Steve

3 3

[alsa-devel] SoC Machine Code Suggestions
by Paul Kavan 27 Jun '07

27 Jun '07

First, thanks to all for helping me get the at91 soc stuff working with my board and codec. It now plays telecom quality audio using aplay and records it as well using arecord. For those who were following my trials and did not hear what the solution was, essentially, when the at91-ssc code goes into playback mode, it only activates the TX side of the SSC (PCM) bus. Similarly, when it is in capture mode, it only activates the RX side of the bus. This certainly makes sense and works in most situations I am sure. However, I needed both the RX and TX frames operating in both playback and capture. As such, I had to modify at91-ssc slightly to accomplish this. Now that I have decent audio, I want to clean up around the edges of the audio and determine the best way to proceed with my application code. First. when the pcm interface starts/stops, I get a pop that comes from the codec analog output transitioning some. Now, there may be some hardware fixes to this, but what I would like to do it mute the amp until the last possible second before audio is played. I can accomplish this with a simple gpio call, but am not sure where best to turn the mute on and off. Any suggestions with that would be appreciated. Also, my next phase of development is to determine whether I need to write my own application to accomplish what I want to do, or if there is an application out there that will do the trick--and that I can cross-compile to an ARM. What I would like is an application I will stream audio (half-duplex) between two ARM boards connected via ethernet. I would need to be able to control the start/stop of the audio. Sometimes this control will depend on the state of the machine and other times it will be activate with a button press by the user. I hope that makes sense. Obviously it would have to seamlessly stream to the codec via ALSA. Also, there may be times when it streams to a pc. Now, the codec uses 8-bit ulaw, so this code if it were on a pc, would need to be able to play that on the pc in its native state or some type of conversion on the fly. I guess you can think of the application as similar to voip, but half duplex instead of full duplex. Does anyone know if something like this exists that I might use. If not, how hard would it be to code this for ALSA? Thanks again and I look forward to your responses. Paul -- *************************************** Paul David Kavan Project Engineer GRH Electronics, Inc. 402-734-4900 pkavan(a)gmail.com ***************************************

2 2

Re: [alsa-devel] SALSA-Lib version 0.0.1 release
by Takashi Iwai 27 Jun '07

27 Jun '07

At Mon, 25 Jun 2007 23:32:39 +0100, Adrian McMenamin wrote: > > > You can check ldd to the app which shlib it's linked with. > > It should be linked with libsalsa, not libasound. > > > > > > Takashi > > > > I expect I am being a bit thick here but what app? I use mpg123 and > it's not linked with any alsa libs. > > / # ldd ./mpg123 > libm.so.0 => /lib/libm.so.0 (0x2956d000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2958b000) > libc.so.0 => /lib/libc.so.0 (0x295aa000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x29558000) mpg123 is an OSS app. > / # ldd aplay > libasound.so.2 => /usr/lib/libasound.so.2 (0x2956d000) > libm.so.0 => /lib/libm.so.0 (0x29652000) > libdl.so.0 => /lib/libdl.so.0 (0x29670000) > libpthread.so.0 => /lib/libpthread.so.0 (0x29683000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x296a4000) > libc.so.0 => /lib/libc.so.0 (0x296c3000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x29558000) It's liekly linked with the old libasound. SALSA-lib is a source-level compatible library and it's _not_ binary-level compatible. Thus, it's no drop-in replacement. After installing salsa-lib (better use --enable-everything option to make a libasound symlink), then you'll have to rebuild the other apps linked with alsa-lib again. Takashi

1 0

Re: [alsa-devel] ALSA always writes _whole_ periods, right?
by Takashi Iwai 27 Jun '07

27 Jun '07

At Sun, 24 Jun 2007 11:34:56 +0200, Joachim Förster wrote: > > Hi Takashi, > > thanks for your answer. > > On Wed, 2007-06-20 at 12:45 +0200, Takashi Iwai wrote: > > > Ok, ahm, I think my question was not about what I really wanted to know > > > - sorry. I have to reformulate it: In fact I would like to know, how the > > > ALSA-library mmap code behaves regarding the last chunk of samples, for > > > example: Consider aplay, playing a wav file and the wav file's > > > size/number of samples does _not_ fit to a multiple of a period's size. > > > Then, does the mmap code copy these last samples as is _or_ does it copy > > > one whole last period (which is filled with zeros)? > > > > No, you have to fill silence by yourself before committing the mmap > > chunk. The mmap code itself doesn't care about it. > > By "fill silence by yourself", you mean the application (user-space) > which is using ALSA library (with mmap), right? So this is not in the > responsibility of the sound driver, right? Right. The driver has some functionality to fill silence automatically, but it's better to avoid to play with it :) > Hmmm, so if an application does _not_ transfer sound data in a multiple > of period size, the _last_ "period" will be "incomplete". Then, my > question is: Does ALSA expect to receive a call of snd_period_elapsed() > after these last samples are played, although the it was _not_ a > complete period? I think it might depend on the hardware. Some hardwares are available to stop at the exact position, but most hardware are not. So, it's _safer_ to send always the data in the period size. And, yes, for the last period with less data, the app should fill the data to align to the period size. Takashi

1 0

[alsa-devel] Getting physical address of the DMA buffer
by Pharaoh . 27 Jun '07

27 Jun '07

Hi I have allocated the DMA buffer using snd_pcm_lib_malloc_pages() and it was preallocated as: snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_CONTINUOUS, snd_dma_continuous_data (GFP_KERNEL), 128 * 1024, 128 * 1024); and then, snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(hw_params)); None of these calls fail. The physical address of the allocated buffer is shown as 0 in my case since according to 'Writing an ALSA driver' the physical address of the DMA buffer will not be accessble from the main CPU. Is that why the physical address is shown as 0? Also, in my pointer function, I need the DMA buffers physical address to calculate the position in buffer etc. How can do that since runtime->dma_addr is 0 for me? Apologies for longish mail but I have to paste the actual paragraphs here to clear my understanding in less number of emails by avoiding further emails. In chapter 5, in DMA buffer information, it is said that, 1. The dma_area holds the buffer pointer (the logical address). You can call memcpy from/to this pointer. Meanwhile, dma_addr holds the physical address of the buffer. This ﬁeld is speciﬁed only when the buffer is a linear buffer. and in descrition of prepare callback it says, 2. The physical address of the allocated buffer is set to runtime->dma_area. Statements 1 and 2 contradict each other or I am mis reading them? How should I get the physical address in pointer callbacks? As runtime->dma_area or runtime->dma_addr which is 0? -pharaoh.

2 4

[alsa-devel] Input/output error while playing a file using aplay
by Pharaoh . 26 Jun '07

26 Jun '07

Hi I am testing my audio driver using aplay. I trying to play an audio file using: #aplay -Dplughw:0,0 --rate=44100 --format=S16 --channels=2 test.wav The log is as follows, snd_card_omap_alsa_open start snd_card_omap_alsa_open end Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo snd_omap_alsa_hw_params start snd_omap_alsa_prepare start snd_omap_alsa_prepare end snd_omap_alsa_trigger start audio_start_dma_chain start audio_start_dma_chain end omap_start_alsa_sound_dma end snd_omap_alsa_trigger end snd_omap_alsa_pointer start audio_get_dma_pos start audio_get_dma_pos end It waits here for sometime and then I get snd_omap_alsa_trigger starte error: Input/output error Then the things are wound up as: audio_stop_dma start omap_stop_alsa_sound_dma start omap_stop_alsa_sound_dma end omap_clear_alsa_sound_dma start omap_clear_alsa_sound_dma end snd_omap_alsa_trigger end snd_omap_alsa_hw_free start snd_omap_alsa_hw_free end snd_card_omap_alsa_close start snd_card_omap_alsa_close end So basically the problem is in trigger where it waits for something and then winds up things. Any idea, what could be the reason. I am thinking it has to do something with DMA interrupts etc.

2 14

[alsa-devel] at91 SoC Modifications
by Paul Kavan 26 Jun '07

26 Jun '07

Hello: Okay, so after probing the various pcm lines, I think I see that the format used for the pcm is a little bit off of what my codec likes to play nice. In my machine/codec driver, I see that I have some lines: /* set cpu DAI configuration */ ret = cpu_dai->dai_ops.set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS); I believe this is where it is selecting the format. In at91-ssc.c, I see that this format is given as: case SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_CBS_CFS: /* * DSP/PCM Mode A format, SSC provides BCLK and LRC clocks. * * The SSC transmit and receive clocks are generated from the * MCK divider, and the BCLK signal is output on the SSC TK line. */ rcmr = (( ssc_p->rcmr_period << 24) & AT91_SSC_PERIOD) | (( 1 << 16) & AT91_SSC_STTDLY) | (( AT91_SSC_START_RISING_RF ) & AT91_SSC_START) | (( AT91_SSC_CK_RISING ) & AT91_SSC_CKI) | (( AT91_SSC_CKO_NONE ) & AT91_SSC_CKO) | (( AT91_SSC_CKS_DIV ) & AT91_SSC_CKS); rfmr = (( AT91_SSC_FSEDGE_POSITIVE ) & AT91_SSC_FSEDGE) | (( AT91_SSC_FSOS_POSITIVE ) & AT91_SSC_FSOS) | (( 0 << 16) & AT91_SSC_FSLEN) | (((channels - 1) << 8) & AT91_SSC_DATNB) | (( 1 << 7) & AT91_SSC_MSBF) | (( 0 << 5) & AT91_SSC_LOOP) | (((bits - 1) << 0) & AT91_SSC_DATALEN); tcmr = (( ssc_p->tcmr_period << 24) & AT91_SSC_PERIOD) | (( 1 << 16) & AT91_SSC_STTDLY) | (( AT91_SSC_START_RISING_RF ) & AT91_SSC_START) | (( AT91_SSC_CK_RISING ) & AT91_SSC_CKI) | (( AT91_SSC_CKO_CONTINUOUS ) & AT91_SSC_CKO) | (( AT91_SSC_CKS_DIV ) & AT91_SSC_CKS); tfmr = (( AT91_SSC_FSEDGE_POSITIVE ) & AT91_SSC_FSEDGE) | (( 0 << 23) & AT91_SSC_FSDEN) | (( AT91_SSC_FSOS_POSITIVE ) & AT91_SSC_FSOS) | (( 0 << 16) & AT91_SSC_FSLEN) | (((channels - 1) << 8) & AT91_SSC_DATNB) | (( 1 << 7) & AT91_SSC_MSBF) | (( 0 << 5) & AT91_SSC_DATDEF) | (((bits - 1) << 0) & AT91_SSC_DATALEN); break; I should have caught this before--I spent enough time dealing with the HW registers. The simple ssc pcm driver I wrote sets the regs a little differently to get the peak performance out of the codec, e.g. In RCMR, I have STTDLY=0, AT91_SSC_CKI_FALLING, AT91_SSC_CKS_PIN. In RFMR everything looks okay except that I have FSOS_NONE as I borrow it from TF0 In TCMR the STTDLY=0 in mine In TFMR I do nothing with the FSEDGE and FSDEN and I have FSLEN=7 and DATADEF=1. So, I left with a decision. Do I add a mode or do I modify DSP A to fit my needs? I am not sure how much coding it would take to add a mode--I *do* know it would take little time to modify DSP A, but I am reluctant to make a change to something that is probably 'standard'. Any thoughts on this? Paul -- *************************************** Paul David Kavan Project Engineer GRH Electronics, Inc. 402-734-4900 pkavan(a)gmail.com ***************************************

3 17

[alsa-devel] Fwd: Fwd: Problems with hda_intel, Santa Rosa, and suspend
by Matt Mullins 25 Jun '07

25 Jun '07

On 6/25/07, Takashi Iwai <tiwai(a)suse.de> wrote: > > Yes, single_cmd mode is used always. > That's bad. I believe we have established that. What can I do about it? *Can* I do anything about it? What functions should I start debugging? Has this happened with other codecs before? What documentation will I need or want other than the Intel HDA and STAC9205 specifications? I'm definitely willing to help work on this, as not many people have this hardware. I'm just new to the sound system, so I'm still trying to figure out what-calls-what. - Matt

1 0

[alsa-devel] Intel Realtek ALC268 don't sound
by antoniorc＠4lineas.net 25 Jun '07

25 Jun '07

Hi, I tried latest HG driver version of Alsa, with patch included for ALC268. Apparently card is detected and mixer show correctly volumes bars, but don't sound. I tried option 3stack and auto in /etc/modprobe.d/alsa-base but nothing difference. I've a HP Pavilion dv6528 with Santa Rosa. Please tell me that I can do? Thanks

1 0

[alsa-devel] problem with audigy2 ZS remote
by Stefano Radaelli 25 Jun '07

25 Jun '07

Hi all! Sorry for my bad english. I have a problem with the livedrive of an audigy2 ZS. After some upgrades (on a gentoo linux system) the eternal panel seems to stop working. Even after the "initialization" (with echo on the midi device), the IR led not blink on remote action. This worked correctly in the past but after some upgrade (i don't know exactly what) it stoipped working. I don't known where i have to look (logs?) or what type of debugging it's necessary. Help me please

1 0

[alsa-devel] ARM in embedded audio
by Alan Horstmann 25 Jun '07

25 Jun '07

Hi, Can anyone help point me to info on using ARM in embedded audio systems? Does anyone use a low-cost chip with I2S interface? Thanks Alan

3 5

Re: [alsa-devel] [alsa-cvslog] alsa-lib: Add struct timeval and timespec definition when _POSIX_C_SOURCE is not defined
by Sergey Vlasov 25 Jun '07

25 Jun '07

On Fri, Oct 06, 2006 at 11:01:44AM +0200, Jaroslav Kysela wrote: > changeset: 2218:603411fd0c77712cab43cdd5afcf0ff4ebe51a7f > tag: tip > user: perex > date: Fri Oct 06 11:01:40 2006 +0200 > files: include/global.h > description: > Add struct timeval and timespec definition when _POSIX_C_SOURCE is not defined > > FIXME: It might cause problems on some platforms when tv_usec is not long type. And now it also breaks compilation of the following code (at least with glibc 2.5): #include <sys/select.h> #include <alsa/global.h> $ gcc -c --std=c99 x.c In file included from x.c:2: /usr/include/alsa/global.h:134: error: redefinition of 'struct timeval' /usr/include/alsa/global.h:139: error: redefinition of 'struct timespec' (Without #include <sys/select.h> only 'struct timespec' is redefined.) IMHO attempts to define structures which should be defined by system headers are too dangerous - if someone is using preprocessor flags which hide required parts of system headers, it is their problem, and the risk of mismatch is too high. BTW, <time.h> does not provide 'struct timeval' at all, even with _GNU_SOURCE - it defines only 'struct timespec'; however, this does not cause problems, because ALSA headers currently use only pointers to snd_timestamp_t, which works even without a complete definition of 'struct timeval'. We can try to include <sys/time.h> to get 'struct timeval', or even <sys/select.h> (which currently seems to provide both 'struct timeval' and 'struct timespec' even with -ansi, and http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/select.h.html tells that it should always provide their definitions). > > > diff -r 7bc021fb4bf1027b23aa5429ceda1e1e35c7d126 -r 603411fd0c77712cab43cdd5afcf0ff4ebe51a7f include/global.h > --- a/include/global.h Fri Oct 06 10:38:39 2006 +0200 > +++ b/include/global.h Fri Oct 06 11:01:40 2006 +0200 > @@ -130,6 +130,18 @@ int snd_shm_area_destroy(struct snd_shm_ > > int snd_user_file(const char *file, char **result); > > +#ifndef _POSIC_C_SOURCE > +struct timeval { > + time_t tv_sec; /* seconds */ > + long tv_usec; /* microseconds */ > +}; > + > +struct timespec { > + time_t tv_sec; /* seconds */ > + long tv_nsec; /* nanoseconds */ > +}; > +#endif > + > /** Timestamp */ > typedef struct timeval snd_timestamp_t; > /** Hi-res timestamp */

2 3

[alsa-devel] SALSA library in ARM platform
by Nobin Mathew 25 Jun '07

25 Jun '07

Hi, I tried compiling SALSA for ARM. I got few errors. CC=arm-none-linux-gnueabi-gcc ./configure --target=arm-linux --host=i386 --prefix=/usr make Then I am getting following errors See the bottom part /bin/bash ../libtool --tag=CC --mode=compile arm-none-linux-gnueabi-gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"salsa-lib\" -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -I. -Wall -g -g -O2 -MT mixer.lo -MD -MP -MF .deps/mixer.Tpo -c -o mixer.lo mixer.c arm-none-linux-gnueabi-gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"salsa-lib\" -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -I. -Wall -g -g -O2 -MT mixer.lo -MD -MP -MF .deps/mixer.Tpo -c mixer.c -o mixer.o In file included from hcontrol.h:36, from mixer.h:25, from mixer.c:30: hctl_macros.h: In function 'snd_hctl_elem_tlv_read': hctl_macros.h:136: warning: 'snd_ctl_elem_tlv_read' is deprecated (declared at ctl_macros.h:1131) hctl_macros.h: In function 'snd_hctl_elem_tlv_write': hctl_macros.h:142: warning: 'snd_ctl_elem_tlv_write' is deprecated (declared at ctl_macros.h:1138) hctl_macros.h: In function 'snd_hctl_elem_tlv_command': hctl_macros.h:148: warning: 'snd_ctl_elem_tlv_command' is deprecated (declared at ctl_macros.h:1145) mv -f .deps/mixer.Tpo .deps/mixer.Plo /bin/bash ../libtool --tag=CC --mode=link arm-none-linux-gnueabi-gcc -Wall -g -g -O2 -version-number 0:0:1 -o libsalsa.la -rpath /usr/lib control.lo cards.lo pcm.lo pcm_params.lo pcm_misc.lo hcontrol.lo mixer.lo mkdir .libs libtool: link: CURRENT `' must be a nonnegative integer libtool: link: `0:0:1' is not valid version information make[1]: *** [libsalsa.la] Error 1 make[1]: Leaving directory `/home/nmathew/Desktop/salsa-lib-0.0.1/src' make: *** [all-recursive] Error 1

2 3

[alsa-devel] [PATCH] hda: support for S/PDIF out on ASUS M2V
by Mike Crash 25 Jun '07

25 Jun '07

Added support for S/PDIF digital output on ASUS M2V motheboard - added new model "3stack-660-digout" and ALC660VD_3ST_DIG Apply to 1.0.14 driver file patch_realtek.c Signed-off-by: Mike Crash <mike(a)mikecrash.com> *** patch_realtek.c 2007-06-04 09:28:54.000000000 +0200 --- patch_realtek2.c 2007-06-16 21:46:14.000000000 +0200 *************** enum { *** 117,118 **** --- 117,119 ---- ALC660VD_3ST, + ALC660VD_3ST_DIG, ALC861VD_3ST, *************** static const char *alc861vd_models[ALC86 *** 9466,9467 **** --- 9467,9469 ---- [ALC660VD_3ST] = "3stack-660", + [ALC660VD_3ST_DIG]= "3stack-660-digout", [ALC861VD_3ST] = "3stack", *************** static struct snd_pci_quirk alc861vd_cfg *** 9477,9479 **** SND_PCI_QUIRK(0x1043, 0x1339, "Asus G1", ALC660VD_3ST), ! SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS", ALC660VD_3ST), SND_PCI_QUIRK(0x10de, 0x03f0, "Realtek ALC660 demo", ALC660VD_3ST), --- 9479,9481 ---- SND_PCI_QUIRK(0x1043, 0x1339, "Asus G1", ALC660VD_3ST), ! SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS", ALC660VD_3ST_DIG), SND_PCI_QUIRK(0x10de, 0x03f0, "Realtek ALC660 demo", ALC660VD_3ST), *************** static struct alc_config_preset alc861vd *** 9501,9502 **** --- 9503,9517 ---- }, + [ALC660VD_3ST_DIG] = { + .mixers = { alc861vd_3st_mixer }, + .init_verbs = { alc861vd_volume_init_verbs, + alc861vd_3stack_init_verbs }, + .num_dacs = ARRAY_SIZE(alc660vd_dac_nids), + .dac_nids = alc660vd_dac_nids, + .dig_out_nid = ALC861VD_DIGOUT_NID, + .num_adc_nids = ARRAY_SIZE(alc861vd_adc_nids), + .adc_nids = alc861vd_adc_nids, + .num_channel_mode = ARRAY_SIZE(alc861vd_3stack_2ch_modes), + .channel_mode = alc861vd_3stack_2ch_modes, + .input_mux = &alc861vd_capture_source, + }, [ALC861VD_3ST] = {

2 1

[alsa-devel] [PATCH] MPU401 lockups
by Serge Nikolaenko 25 Jun '07

25 Jun '07

Hello, The attachement is the fix for mpu to prevent lockups/freezes. Added mutexes with down_trylock() calls, to prevent blocking. Midi in/out not tested - I don't have no midi devices at the moment. My soundcard is ESI Juli@. MB integrated midi is disabled in bios. Last system messages after system freeze when running wine/jackd: kernel: cmd: 0xff failed at 0xac0c (status = 0xb, data = 0x0) ... kernel: BUG: soft lockup detected on CPU#0! kernel: kernel: Call Trace: kernel: <IRQ> [<ffffffff802b0bdb>] softlockup_tick+0xdb/0xf6 kernel: [<ffffffff8028f5d0>] update_process_times+0x42/0x68 kernel: [<ffffffff80271f0c>] smp_local_timer_interrupt+0x34/0x55 kernel: [<ffffffff802725e8>] smp_apic_timer_interrupt+0x51/0x69 kernel: [<ffffffff8025ace6>] apic_timer_interrupt+0x66/0x70 kernel: [<ffffffff889c600d>] :snd_mpu401_uart:mpu401_read_port+0x4/0x8 kernel: [<ffffffff889c62f0>] :snd_mpu401_uart:_snd_mpu401_uart_interrupt+0x4c/0x70 kernel: [<ffffffff889c6391>] :snd_mpu401_uart:snd_mpu401_uart_interrupt+0x13/0x1a kernel: [<ffffffff88a1f34b>] :snd_ice1724:snd_vt1724_interrupt+0x4e/0x13a kernel: [<ffffffff80210b93>] handle_IRQ_event+0x25/0x53 kernel: [<ffffffff802b202a>] handle_fasteoi_irq+0x92/0xd1 kernel: [<ffffffff8026862a>] do_IRQ+0xff/0x16d kernel: [<ffffffff8025a631>] ret_from_intr+0x0/0xa kernel: <EOI> [<ffffffff802f5df7>] proc_info_read+0x0/0xb9 kernel: [<ffffffff802f5df9>] proc_info_read+0x2/0xb9 kernel: [<ffffffff8020b14e>] vfs_read+0xcb/0x173 kernel: [<ffffffff80211847>] sys_read+0x45/0x6e kernel: [<ffffffff8025a11e>] system_call+0x7e/0x83

2 1

Re: [alsa-devel] Fwd: Problems with hda_intel, Santa Rosa, and suspend
by Takashi Iwai 25 Jun '07

25 Jun '07

[Please don't strip Cc to ML!] At Tue, 19 Jun 2007 15:54:42 -0500, Matt Mullins wrote: > > I played around with probe_mask, and found that probe_mask=0x1 causes > the error, but probe_mask=0x2 does not cause the timeout. Codec 1 is > my Sigmatel STAC9205, which is what plays sound on my laptop, and > codec 2 is my Conexant modem. The modem isn't the codec causing > problems; the audio codec is! OK, good to know. Does this problem occur with S2D? What is the very first command that triggers this timeout error? I'm wondering what is the difference between them -- according to your report, reloading the module fixes the problem. But, the resume callback is almost identical with the re-initiailzation. Perhaps it's something to do with the power-state management. What about the patch below? Takashi diff -r c531d63e820b sound/pci/hda/hda_intel.c --- a/sound/pci/hda/hda_intel.c Wed Jun 20 12:03:09 2007 +0200 +++ b/sound/pci/hda/hda_intel.c Wed Jun 20 12:09:40 2007 +0200 @@ -1450,7 +1450,7 @@ static int azx_suspend(struct pci_dev *p pci_disable_msi(chip->pci); pci_disable_device(pci); pci_save_state(pci); - pci_set_power_state(pci, pci_choose_state(pci, state)); + /* pci_set_power_state(pci, pci_choose_state(pci, state)); */ return 0; }

2 4

[alsa-devel] hda-intel without headphone output
by Robert Lemmen 25 Jun '07

25 Jun '07

hi everyone, i have a fujitsu siemens amilo pro v3515 notebook, with a via VT8251/ VT8237A chipset. sound works fine through the speakers, but i don't get anything through the headphones, no headphone channel shows up in the mixer, and the headphone jack switch doesn't mute the speakers. i have alsa 1.0.13, and a 2.6.18 kernel. i tried all "model" settings that i could find in ALSA-Configuration in the kernel tree. lspci -nv gives 04:01.0 0403: 1106:3288 (rev 10) Subsystem: 1734:10cb Flags: bus master, fast devsel, latency 0, IRQ 58 Memory at c9100000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 (only the stanza for the sound card, yell if you need more), and /proc/asound/card0/codec#0 gives: Codec: Generic 14f1 ID 5045 Address: 0 Vendor Id: 0x14f15045 Subsystem Id: 0x173410cb Revision Id: 0x100100 Default PCM: rates 0x140, bits 0x0e, types 0x1 Default Amp-In caps: N/A Default Amp-Out caps: N/A Node 0x10 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Amp-Out caps: ofs=0x2b, nsteps=0x2b, stepsize=0x05, mute=1 Amp-Out vals: [0x28 0x28] Pincap 0x0810014: OUT EAPD Detect Pin Default 0x92170110: [Fixed] Speaker at Int Front Conn = Analog, Color = Unknown Pin-ctls: 0x40: OUT Power: 0x0 Connection: 2 0x19* 0x17 Node 0x11 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Amp-Out caps: ofs=0x2b, nsteps=0x2b, stepsize=0x05, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x08113c: IN OUT HP Detect Pin Default 0x0121401f: [Jack] HP Out at Ext Rear Conn = 1/8, Color = Green Pin-ctls: 0xc0: OUT HP Power: 0x0 Connection: 2 0x19* 0x17 Node 0x12 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Amp-Out caps: ofs=0x2b, nsteps=0x2b, stepsize=0x05, mute=1 Amp-Out vals: [0xab 0xab] Pincap 0x08113c: IN OUT HP Detect Pin Default 0x01a19020: [Jack] Mic at Ext Rear Conn = 1/8, Color = Pink Pin-ctls: 0x20: IN Power: 0x0 Connection: 2 0x19* 0x17 Node 0x13 [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x0810: OUT Pin Default 0x214571f0: [Jack] SPDIF Out at Sep Rear Conn = Optical, Color = Yellow Pin-ctls: 0x00: Connection: 1 0x18 Node 0x14 [Pin Complex] wcaps 0x400081: Stereo Pincap 0x081124: IN Detect Pin Default 0x97a7012e: [Fixed] Mic at Int Riser Conn = Analog, Color = Unknown Pin-ctls: 0x20: IN Node 0x15 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: IN Pin Default 0x400001f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Node 0x16 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out Amp-Out caps: ofs=0x07, nsteps=0x07, stepsize=0x0b, mute=1 Amp-Out vals: [0x06] Node 0x17 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Amp-In caps: ofs=0x14, nsteps=0x2b, stepsize=0x05, mute=1 Amp-In vals: [0x94 0x94] [0x17 0x17] [0x94 0x94] [0x94 0x94] [0x94 0x94] Power: 0x0 Connection: 5 0x19 0x14 0x12 0x11 0x15 Node 0x18 [Audio Output] wcaps 0x211: Stereo Digital PCM: rates 0x040, bits 0x06, types 0x5 Node 0x19 [Audio Output] wcaps 0xc11: Stereo PCM: rates 0x540, bits 0x0e, types 0x1 Power: 0x0 Node 0x1a [Audio Input] wcaps 0x100d0b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x17, stepsize=0x05, mute=1 Amp-In vals: [0x17 0x17] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] Power: 0x0 Connection: 5 0x17 0x14 0x12 0x11 0x15* Node 0x1b [Vendor Defined Widget] wcaps 0xf00000: Mono please tell me if there is anything i can do, any additional information you need, or any general tipps. thanks robert -- Robert Lemmen http://www.semistable.com

3 13

[alsa-devel] [1/2] 2.6.22-rc6: known regressions
by Michal Piotrowski 25 Jun '07

25 Jun '07

Hi all, Here is a list of some known regressions in 2.6.22-rc6. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions *STATISTICS* (a.k.a. list of aces) Name Regressions fixed since 21-Jun-2007 Andi Kleen 1 Hugh Dickins 1 Jean Delvare 1 Unclassified Subject : Kernel hang on CMOS_READ References : http://lkml.org/lkml/2007/6/3/138 Submitter : Rodrigo Luiz <troops.of.doom(a)gmail.com> Status : Unknown ALSA Subject : snd-aoa causes badness in lib/kref.c:33 References : http://bugzilla.kernel.org/show_bug.cgi?id=8513 Submitter : Ben Collins <bcollins(a)ubuntu.com> Handled-By : Takashi Iwai <tiwai(a)suse.de> Status : Unknown Memory management Subject : 2.6.22-rc5-yesterdaygit with VM debug: BUG in mm/rmap.c:66: anon_vma_link ? References : http://lkml.org/lkml/2007/6/25/45 Submitter : Petr Vandrovec <petr(a)vmware.com> Status : unknown SATA/PATA Subject : libata IT821X driver still fails! Hard-freezes system References : http://lkml.org/lkml/2007/6/14/82 Submitter : Rodney Gordon II <meff(a)spherevision.org> Status : unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/

1 0

[alsa-devel] alsa-lib: pcm_softvol.c: attenuation curve - it seems to be too quiet at full volume
by John L. Utz III 25 Jun '07

25 Jun '07

Hello All; I am in release testing with a fix to our product to use 4 channels on a CMEDIA 8738-MC6 (previously we only used 2 channels on the CMEDIA and a separate soundcard for the 2 back channels). The 8738 is a pretty funny old duck of a chip and i am trying to work around a subset of it's many idiosyncracies. :-) The most glaring defect is the absence of hard volume on the back channels *and* that the back channel is louder than the front channel. Obviously, this is a great candidate for softvol! Softvol works quite well *except* that the max volume for the rear channel is now much quieter than it is without softvol. :-( Is there anything i can do to alter this behavior? I notice that there is an initial minimal DB in the file: #define PRESET_MIN_DB -51.0 is this where everything starts from? if i bump this up, will i get a higher max volume? tnx! johnu

2 1

[alsa-devel] Query regarding pointer callback
by Pharaoh . 25 Jun '07

25 Jun '07

Hi In Writing an ALSA driver, it is said that pointer callback is called usually from the buffer-update routine in the pcm middle layer, which is invoked when snd_pcm_period_elapsed() is called in the interrupt routine. Then the pcm middle layer updates the position and calculates the available space, and wakes up the sleeping poll threads, etc What are the other places from where pointer callback is called? If it is not called from any other routine then does it mean that interrupts are occuring?

2 2

[alsa-devel] Intel Realtek ALC268 don't sound
by Antonio Rguez. Capita 25 Jun '07

25 Jun '07

Hi, I tried lastest HG driver version of Alsa, with patch included for ALC268. Apparently card is detected and mixer show correctly volumes bars, but don't sound. I tried option 3stack and auto in /etc/modprobe.d/alsa-base but nothing difference. I've a HP Pavilion dv6528 with Santa Rosa. Please tell me that I can do? Thanks

1 0

Re: [alsa-devel] No sound on Medion laptop (intel 82801G)
by albox＠free.fr 25 Jun '07

25 Jun '07

Here is the result : $ sudo dmesg -c $ sudo rmmod snd-hda-intel && sudo modprobe snd-hda-intel probe_mask=1 $ dmesg [ 638.324000] ACPI: PCI interrupt for device 0000:00:1b.0 disabled [ 638.368000] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 [ 638.368000] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 638.400000] ALSA /home/alboot/Sources/alsa1.0.14rc4/alsa-driver-1.0.14rc4/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:698: codec_mask = 0x3 [ 638.576000] ALSA /home/alboot/Sources/alsa1.0.14rc4/alsa-driver-1.0.14rc4/pci/hda/hda_codec.c:1820: hda_codec: model 'medion' is selected for config 161f:2054 (Medion laptop) I can hear a quick sound (like a "bip") when I enter the command but after that, the sound doesn't work.

1 0

[alsa-devel] No sound on Medion laptop (intel 82801G)
by albox＠free.fr 25 Jun '07

25 Jun '07

Hi, I reported a bug about medion laptops having an intel 82801G sound card that doesn't work with ALSA 1.0.14rc4 on Kubuntu : https://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_i… I didn't get any news yet. As I said, I'm willing to help. Any ideas about what I should check ? Is there any web page that could help me to detect the problem ? Thanks

2 1