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

[alsa-devel] New Realtec ALC833 Codec in Fujitsu Siemens Xi2428
by Die Mumie 05 Dec '07

05 Dec '07

Hi, I've been told to post here, so I do. I have a Notebook with a Intel hda sound device, the /proc/asound/card0/codec#1 returns Realtec ALC833 but there is no model provided by the alsa driver that runs this Soundcard properly. Am I wrong here? If yes, then I'm sorry. --------------------------------- Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail.

2 2

[alsa-devel] POSIX clocks and ALSA
by Heikki Lindholm 04 Dec '07

04 Dec '07

Hello, Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess. -- Heikki Lindholm

3 15

[alsa-devel] handling x-runs
by srinivasa bp 04 Dec '07

04 Dec '07

Hi all, I am new to ALSA. But was able to bring up two applications to play and record pcm. But now i am facing problems with X-Runs . I am using the API snd_pcm_prepare but somehow not able to recover from it. Can any one please guide me regarding or please let me know if there is any doc available to do this .... thanks -- - Regards, Srini

1 0

Re: [alsa-devel] rme multiface I=>pccard error -12
by rmgls＠free.fr 04 Dec '07

04 Dec '07

> At Fri, 30 Nov 2007 15:11:08 +0100, > rmgls(a)free.fr wrote: >> >> >> Hello, >> >> on a laptop the old multiface I with a pccard (1) doesn't attach. >> acore returns error -12. >> >> details: >> dmesg: >> pccard: CardBus card inserted into slot 0 >> ALSA /root/alsa-driver-hg20071129/acore/init.c:174: cannot find the slot for index 0 (range 0-0), error: -16 > Check /proc/asound/cards. The index 0 is likely already used by > another device. Since the recent distro loads the sound drivers > automatically via udev, you'll have to set index for all drivers > properly. > If it's snd-hda-intel, add the option like below: > options snd-hda-intel index=1 > Takashi Hello Takashi, thanks for this info, and sorry for the noise. all worlks fine now. Best regards rmgls(a)free.fr

1 0

[alsa-devel] May be typos in the current ALSA?
by Andy Shevchenko 03 Dec '07

03 Dec '07

Hi! I think the following notices should be reviewed as a typo fix. Could you tell me do I wrong? /* patch_realtek.c */ ... static struct snd_pci_quirk alc861_cfg_tbl[] = { SND_PCI_QUIRK(0x1043, 0x1205, "ASUS W7J", ALC861_3ST), SND_PCI_QUIRK(0x1043, 0x1335, "ASUS F2/3", ALC861_ASUS_LAPTOP), SND_PCI_QUIRK(0x1043, 0x1338, "ASUS F2/3", ALC861_ASUS_LAPTOP), SND_PCI_QUIRK(0x1043, 0x13d7, "ASUS A9rp", ALC861_ASUS_LAPTOP), >>> SND_PCI_QUIRK(0x1584, 0x9075, "Airis Praxis N1212", ALC861_ASUS_LAPTOP), SND_PCI_QUIRK(0x1043, 0x1393, "ASUS", ALC861_ASUS), SND_PCI_QUIRK(0x1043, 0x81cb, "ASUS P1-AH2", ALC861_3ST_DIG), SND_PCI_QUIRK(0x1179, 0xff00, "Toshiba", ALC861_TOSHIBA), /* FIXME: the entry below breaks Toshiba A100 (model=auto works!) * Any other models that need this preset? */ /* SND_PCI_QUIRK(0x1179, 0xff10, "Toshiba", ALC861_TOSHIBA), */ SND_PCI_QUIRK(0x1584, 0x9072, "Uniwill m31", ALC861_UNIWILL_M31), >>> SND_PCI_QUIRK(0x1584, 0x9075, "Uniwill", ALC861_UNIWILL_M31), SND_PCI_QUIRK(0x1584, 0x2b01, "Uniwill X40AIx", ALC861_UNIWILL_M31), SND_PCI_QUIRK(0x1849, 0x0660, "Asrock 939SLI32", ALC660_3ST), SND_PCI_QUIRK(0x8086, 0xd600, "Intel", ALC861_3ST), SND_PCI_QUIRK(0x1462, 0x7254, "HP dx2200 (MSI MS-7254)", ALC861_3ST), SND_PCI_QUIRK(0x1462, 0x7297, "HP dx2250 (MSI MS-7297)", ALC861_3ST), {} }; ... The second record was added by myself (I filed bug report) when I discover RoverBook Voyager V200. First one was added later without checks. And the lines at the same file ... /* * generic initialization of ADC, input mixers and output mixers */ static struct hda_verb alc883_auto_init_verbs[] = { ... /* FIXME: use matrix-type input source selection */ /* Mixer elements: 0x18, 19, 1a, 1b, 1c, 1d, 14, 15, 16, 17, 0b */ /* Input mixer1 */ {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}, {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)}, {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(2)}, /* {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(3)}, */ {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(4)}, /* Input mixer2 */ {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}, {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)}, {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(2)}, /* {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(3)}, */ >>> {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(4)}, { } }; The same initialization is present above in few lines. P.S. I've donloaded ALSA just few hours ago in daily snapshot tarball form. -- With best regards, Andy Shevchenko. mailto: andy(a)smile.org.ua

2 2

[alsa-devel] rme multiface I=>pccard error -12
by rmgls＠free.fr 03 Dec '07

03 Dec '07

Hello, on a laptop the old multiface I with a pccard (1) doesn't attach. acore returns error -12. details: dmesg: pccard: CardBus card inserted into slot 0 ALSA /root/alsa-driver-hg20071129/acore/init.c:174: cannot find the slot for index 0 (range 0-0), error: -16 RME Hammerfall DSP: probe of 0000:07:00.0 failed with error -12 config: machine: sony vaio s5 kernel 2-6-24-rc3 all alsa-*-hg as you seen. sound box: multiface I and pccard (I), the old one. Socket 0 Bridge: [yenta_cardbus] (bus ID: 0000:06:05.0) lspcmcia: Configuration: state: on ready: yes Voltage: 3.3V Vcc: 3.3V Vpp: 3.3V lspci -v 06:05.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller Subsystem: Sony Corporation Unknown device 818f Flags: bus master, medium devsel, latency 168, IRQ 17 Memory at b0008000 (32-bit, non-prefetchable) [size=4K] Bus: primary=06, secondary=07, subordinate=0a, sec-latency=176 Memory window 0: 50000000-53fff000 (prefetchable) Memory window 1: 54000000-57fff000 I/O window 0: 00002400-000024ff I/O window 1: 00002800-000028ff 16-bit legacy interface ports at 0001 07:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP (rev 10) Flags: medium devsel, IRQ 17 Memory at 54000000 (32-bit, non-prefetchable) [disabled] [size=64K] cat /dev/sndstat: ... 0: alc-260 any help would be appreciated. thanks. best regards raoul rmgls(a)free.fr

2 1

[alsa-devel] Patch - switching rate in STAC9460 codec of Prodigy192
by Pavel Hofman 03 Dec '07

03 Dec '07

Hi, Here is a patch for switching rate in STAC9460 codec. Thanks, Pavel. Signed-off-by: Pavel Hofman <dustin(a)seznam.cz> * support for switching rate in STAC9460 - using set_rate_val of the akm infrastructure * listing all STAC9460 registers in proc * disabling mpu401 device for Prodigy192 - otherwise the currently flawed mpu401 code hangs kernel when opening the midi device * removing old unused commented-out code

2 1

[alsa-devel] I2C fix for ice1724
by Pavel Hofman 03 Dec '07

03 Dec '07

Hello Takashi, Below is a patch for ice1724 I2C read code. Thanks, Pavel. Signed-off-by: Pavel Hofman <dustin(a)seznam.cz> * adding i2c busy wait before sending device address to prevent reading bogus data diff -r 7f4b25ff79d6 pci/ice1712/ice1724.c --- a/pci/ice1712/ice1724.c Fri Nov 30 17:59:25 2007 +0100 +++ b/pci/ice1712/ice1724.c Fri Nov 30 21:17:36 2007 +0100 @@ -1958,6 +1958,7 @@ unsigned char snd_vt1724_read_i2c(struct unsigned char val; mutex_lock(&ice->i2c_mutex); + wait_i2c_busy(ice); outb(addr, ICEREG1724(ice, I2C_BYTE_ADDR)); outb(dev & ~VT1724_I2C_WRITE, ICEREG1724(ice, I2C_DEV_ADDR)); wait_i2c_busy(ice);

2 1

[alsa-devel] help
by YanBob 02 Dec '07

02 Dec '07

hello, my linux is ubuntu with Linux bob-laptop 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux. now the problem is that,no sound comes out when i use ubuntu. i have google some pages, and followed the steps as they said. But i turns out that my sound card is still not working. At the end of this email, i send you some inf. about my sound card. And my laptop model is Lenovo F41. Could you please help me? thanks a million!! bob@bob-laptop:~$ aplay -l **** PLAYBACK硬件设备列表 **** 卡 0: Intel [HDA Intel], 设备 0: ALC262 Analog [ALC262 Analog] 子设备: 1/1 子设备：#0: subdevice #0 卡 0: Intel [HDA Intel], 设备 1: ALC262 Digital [ALC262 Digital] 子设备: 1/1 子设备：#0: subdevice #0 卡 0: Intel [HDA Intel], 设备 6: Si3054 Modem [Si3054 Modem] 子设备: 1/1 子设备：#0: subdevice #0 bob@bob-laptop:~$ lspci -vv|grep Audio 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) bob@bob-laptop:~$ cat /proc/asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xf8300000 irq 22 bob@bob-laptop:~$ lsmod|grep snd snd_hda_intel 263712 1 snd_pcm_oss 44672 0 snd_mixer_oss 17664 1 snd_pcm_oss snd_pcm 80388 2 snd_hda_intel,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 11 snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device soundcore 8800 1 snd snd_page_alloc 11400 2 snd_hda_intel,snd_pcm bob@bob-laptop:~$ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC). ___________________________________________________________ 进入雅虎游戏嘉年华，赢取液晶显示器！ http://cn.mail.yahoo.com/promo/carnival07/

2 1

Re: [alsa-devel] multi pcm and mmap problem
by Takashi Iwai 02 Dec '07

02 Dec '07

At Wed, 21 Nov 2007 16:27:52 -0500, Tim wrote: > > On Wednesday 21 November 2007 06:01:22 am you wrote: > > At Wed, 21 Nov 2007 01:58:41 -0500, > > > > terminator356(a)users.sourceforge.net wrote: > > > After 2 years I've finally traced and fixed a problem > > > which was preventing me from using anything after > > > ALSA 1.0.9b ! > > > > > > In ALSA lib 1.0.9b: > > > pcm/pcm_generic.c: > > > int snd_pcm_generic_channel_info() > > > { > > > snd_pcm_generic_t *generic = pcm->private_data; > > > return snd_pcm_channel_info(generic->slave, info); > > > } > > > > > > But in ALSA lib 1.0.15: > > > pcm/pcm_generic.c: > > > int snd_pcm_generic_channel_info() > > > { > > > snd_pcm_generic_t *generic = pcm->private_data; > > > if (pcm->mmap_shadow) { > > > /* No own buffer is required - the plugin won't change > > > * the data on the buffer, or do safely on-the-place > > > * conversion > > > */ > > > return snd_pcm_channel_info(generic->slave, info); > > > } else { > > > // Tim: TESTED: This is now called instead of the other > > > one! /* Allocate own buffer */ > > > return snd_pcm_channel_info_shm(pcm, info, -1); > > > } > > > } > > > > > > My multi PCM consists of a plughw:0,2 and a hw:1,0 > > > In ALSA 1.0.9b, all five PCMs ALSA creates for this arrangement > > > create their areas with mmap(). And it works. > > > But in ALSA 1.0.15 my hw:1,0 and its multi PCM areas are > > > created with mmap(), and my plughw:0,2 and its PCMs areas > > > are created with malloc(). > > > Can't hear/record any sound from the plughw:0,2 part of the multi. > > > > > > I have verified that ALSA 1.0.15 is copying the plughw:0,2 HW PCM > > > areas to its LINEAR PCM areas, but NOT finally to its multi PCM areas. > > > It just copies all zeros. > > > That's the reason I hear/record no sound from the plughw:0,2 part > > > of the multi PCM. > > > So I reverted the function's code back to 1.0.9b and presto! > > > It works now, the same as in ALSA 1.0.9b > > > > > > So please tell me, am I missing something? > > > > Well, first of all, could you elaborate what is the real problem you > > are facing? Judging from your description above, it sounds like a > > clear bug, but I'm not sure where to start. > > > > In addition to the detailed bug description, a testcase program would > > be greatly helpful. > > > > OK. First, here's my simple testing .asoundrc : > pcm.multi_rec { > type multi; > slaves.a.pcm "hw:1,0"; > slaves.a.channels 12; > slaves.b.pcm "plughw:0,2"; > slaves.b.channels 16; > bindings.0.slave a; > bindings.0.channel 4; > bindings.1.slave b; > bindings.1.channel 10; > } > ctl.multi_rec { > type hw; > card 0; > } > > The two cards are SBLive! (emu10k1) and Delta1010LT (ice1712). > > And here is the command line I run: > arecord -I -v -t wav -c2 -r 48000 -f S32_LE -Dmulti_rec -d 3 \ > --buffer-size 128 arecord-multi-ice-emu.wav > > My problem is under ALSA 1.0.15 no sound is recorded from slave 'b' - > (the plughw:0,2 channel). > When I look at the two generated wav files, the first has data, and the second > has all zeros. > > So as I said before, I found that ALSA is copying data from the > plughw:0,2 HW PCM area to its LINEAR PCM area (i.e. the actual conversion > is taking place), but then somehow the data is not finally copied to its > multi slave b PCM area - just all zeros are copied. > Hence all zeros are stored in the second wav file. > > But with ALSA 1.0.9b, since all the areas are allocated with mmap(), > it works fine. It is only after ALSA 1.0.9b, that I get the problem. > Because ALSA 1.0.15 is allocating both the plughw:0,2 LINEAR PCM area > and multi slave slave b's PCM area with malloc(). > It seems ALSA doesn't want to copy to areas created with malloc(). OK, point taken. The problem is that the multi plugin creates unnecessary local buffer. It works somehow when the slave is a hw, but it doesn't for other types. Try the patch below. This should fix the problem. Now the multi plugin just shadows the slave buffers via mmap. > > > Should I add something more to my .asoundrc ? > > > I see that besides {type multi ... }, there is a {type share ...} > > > defined. *** Does the 'share' have any use here? Can't find any docs on > > > it. > > > > The share type is used only for share plugin, so you can ignore it. > > > > > Also: > > > Yes, I can see now, why you made this code change. > > > mmap() has limits, so you switched over to malloc(). > > > Those limits force the user to use small buffers > > > and/or reduce the number of channels created. > > > > No, mmap was never used between plugins. It was only for the hw layer > > even in the earlier verson. In the earlier version, SHM was used > > instead. But, the plugin buffer is referred only locally, so it makes > > no sense to use SHM for that. That's why now it was switched to > > malloc. (snd_pcm_channel_info_shm() is a rest of the old behavior, > > and thus its name is confusing...) > > > My point was this: > Under ALSA 1.0.9b, (and with my fix to ALSA 1.0.15 to force it to use > mmap() always - see above), if I run: > arecord -I -v -t wav -c2 -r 48000 -f S32_LE -Dmulti_rec -d 3 \ > --buffer-size 128 arecord-multi-ice-emu.wav > it will run. But if I run > arecord -I -v -t wav -c2 -r 48000 -f S32_LE -Dmulti_rec -d 3 \ > --buffer-size 256 arecord-multi-ice-emu.wav > it fails with "mmap() failed: Invalid argument". > I quadrupled the available locked memory with a line in > /etc/security/limits.conf > * - memlock 128 > but the second command line still fails. > What am I doing wrong? How can I increase mmap() limits? It must be irrelevant now... Takashi diff -r 3539f279ec38 src/pcm/pcm_multi.c --- a/src/pcm/pcm_multi.c Wed Nov 21 12:19:43 2007 +0100 +++ b/src/pcm/pcm_multi.c Fri Nov 23 14:40:39 2007 +0100 @@ -690,13 +690,43 @@ static snd_pcm_sframes_t snd_pcm_multi_m return size; } -static int snd_pcm_multi_mmap(snd_pcm_t *pcm ATTRIBUTE_UNUSED) +static int snd_pcm_multi_munmap(snd_pcm_t *pcm) { + free(pcm->mmap_channels); + free(pcm->running_areas); + pcm->mmap_channels = NULL; + pcm->running_areas = NULL; return 0; } -static int snd_pcm_multi_munmap(snd_pcm_t *pcm ATTRIBUTE_UNUSED) +static int snd_pcm_multi_mmap(snd_pcm_t *pcm) { + snd_pcm_multi_t *multi = pcm->private_data; + unsigned int c; + + pcm->mmap_channels = calloc(pcm->channels, + sizeof(pcm->mmap_channels[0])); + pcm->running_areas = calloc(pcm->channels, + sizeof(pcm->running_areas[0])); + if (!pcm->mmap_channels || !pcm->running_areas) { + snd_pcm_multi_munmap(pcm); + return -ENOMEM; + } + + /* Copy the slave mmapped buffer data */ + for (c = 0; c < pcm->channels; c++) { + snd_pcm_multi_channel_t *chan = &multi->channels[c]; + snd_pcm_t *slave; + if (chan->slave_idx < 0) { + snd_pcm_multi_munmap(pcm); + return -ENXIO; + } + slave = multi->slaves[chan->slave_idx].pcm; + pcm->mmap_channels[c] = + slave->mmap_channels[chan->slave_channel]; + pcm->running_areas[c] = + slave->running_areas[chan->slave_channel]; + } return 0; } @@ -850,6 +880,7 @@ int snd_pcm_multi_open(snd_pcm_t **pcmp, return err; } pcm->mmap_rw = 1; + pcm->mmap_shadow = 1; /* has own mmap method */ pcm->ops = &snd_pcm_multi_ops; pcm->fast_ops = &snd_pcm_multi_fast_ops; pcm->private_data = multi;

3 9