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

Re: [alsa-devel] Alsa-devel Digest, Vol 12, Issue 70
by Anders Rønningen 21 Feb '08

21 Feb '08

I'll do the tests when I get home from work. Just wanted to check that I understood the instructions. The problem is like you said. The left HP and the internal speakers never give any sound, regardless of whether the right HP is connected. You want me to: 1. remove the mentioned line from alsa-kernel/pci/hda/patch_sigmatel.c. 2. configure and build the driver with full debug 3. reboot, run alsa-info.sh and upload the output Is that right? > No difference in the output but there must be a difference in the codec setting. You mean before and after I remove the line from patch_sigmatel.c? >What is the original configuration of pin 0xf? How can I know/find out this? - Anders On Feb 20, 2008 12:00 PM, <alsa-devel-request(a)alsa-project.org> wrote: > Send Alsa-devel mailing list submissions to > alsa-devel(a)alsa-project.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > or, via email, send a message with subject or body 'help' to > alsa-devel-request(a)alsa-project.org > > You can reach the person managing the list at > alsa-devel-owner(a)alsa-project.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Alsa-devel digest..." > > > Today's Topics: > > 1. Re: Problem with DELL XPS M1530 (Jiang zhe) > 2. Re: Problem with DELL XPS M1530 (Takashi Iwai) > 3. Re: Problem with DELL XPS M1530 (Takashi Iwai) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 20 Feb 2008 17:49:00 +0800 > From: Jiang zhe <zhe.jiang(a)intel.com> > Subject: Re: [alsa-devel] Problem with DELL XPS M1530 > To: Anders R?nningen <andersronningen(a)gmail.com> > Cc: Takashi Iwai <tiwai(a)suse.de>, alsa-devel(a)alsa-project.org > Message-ID: <1203500940.3006.4.camel(a)localhost.localdomain> > Content-Type: text/plain; charset=utf-8 > > On Wed, 2008-02-20 at 02:25 +0800, Anders R?nningen wrote: > > Hi Takashi. > > > > Some dmesg output: > > > > [ 14.192000] ALSA > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:2994: > > autoconfig: line_outs=1 (0xf/0x0/0x0/0x0/0x0) > > [ 14.192000] ALSA > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:2998: > > speaker_outs=1 (0xd/0x0/0x0/0x0/0x0) > > [ 14.192000] ALSA > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:3002: > > hp_outs=1 (0xa/0xf/0x0/0x0/0x0) > > [ 14.192000] ALSA > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:3003: > > mono: mono_out=0x0 > > [ 14.192000] ALSA > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:3011: > > inputs: mic=0xe, fmic=0x0, line=0x0, fline=0x0, cd=0x0, aux=0x0 > > [ 14.196000] ALSA > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/../../alsa-kernel/pci/hda/patch_sigmatel.c:2224: > > dac_nids=2 (0x5/0x4/0x0/0x0/0x0) > > > > Unmuted and adjusted Surround volume, but it made no difference. > > > > - Anders > > > It's weird that 0xf is in both the line_outs and hp_outs. > And the hp_outs=1 when there are two items. > > What is the original configuration of pin 0xf? > Please try to get rid of this line from the > alsa-kernel/pci/hda/patch_sigmatel.c. > > SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x022e, "Dell ", STAC_DELL_BIOS), > > Rebuild and install the driver. > Please give the output of "cat /proc/asound/card0/codec#0". > > Thanks! > > > Takashi Iwai wrote: > > > At Tue, 19 Feb 2008 17:24:04 +0100, > > > Anders R?nningen wrote: > > > > > >> Hi. I am the mentioned user with this problem. Just thought I'd > > give you > > >> a little more info on this problem. > > >> > > >> What wishie described was correct, except it's the internal > > speakers and > > >> the /left/ hp-jack that stopped working, while the right one is > > still > > >> ok. Like he wrote, the reason we started this debugging was to get > > mic > > >> sound on my system. The thing I think is worth mentioning is that > > with > > >> alsa 1.0.14 on an out-of-the box Ubuntu Gutsy, both hp-jacks and > > the > > >> internal speakers worked for me. People in #alsa told me that the > > module > > >> was not loaded correctly, but whatever was loaded _almost_ worked > > well :-) > > >> > > > > > > OK, please build the driver with --with-debug=full option and show > > the > > > kernel messages such as "autoconfig: ..." and "dac_nids...", etc. > > > This contains the information that the pin configuration parser > > uses. > > > > > > Also, unmute and adjust "Surround" volume. > > > > > > > > > Takashi > > > > > _______________________________________________ > > Alsa-devel mailing list > > Alsa-devel(a)alsa-project.org > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 20 Feb 2008 11:50:44 +0100 > From: Takashi Iwai <tiwai(a)suse.de> > Subject: Re: [alsa-devel] Problem with DELL XPS M1530 > To: Jiang zhe <zhe.jiang(a)intel.com> > Cc: alsa-devel(a)alsa-project.org, Anders R?nningen > <andersronningen(a)gmail.com> > Message-ID: <s5hy79fsxyz.wl%tiwai(a)suse.de> > Content-Type: text/plain; charset=ISO-8859-1 > > At Wed, 20 Feb 2008 17:49:00 +0800, > Jiang zhe wrote: > > > > On Wed, 2008-02-20 at 02:25 +0800, Anders R?nningen wrote: > > > Hi Takashi. > > > > > > Some dmesg output: > > > > > > [ 14.192000] ALSA > > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:2994: > > > autoconfig: line_outs=1 (0xf/0x0/0x0/0x0/0x0) > > > [ 14.192000] ALSA > > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:2998: > > > speaker_outs=1 (0xd/0x0/0x0/0x0/0x0) > > > [ 14.192000] ALSA > > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:3002: > > > hp_outs=1 (0xa/0xf/0x0/0x0/0x0) > > > [ 14.192000] ALSA > > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:3003: > > > mono: mono_out=0x0 > > > [ 14.192000] ALSA > > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:3011: > > > inputs: mic=0xe, fmic=0x0, line=0x0, fline=0x0, cd=0x0, aux=0x0 > > > [ 14.196000] ALSA > > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/../../alsa-kernel/pci/hda/patch_sigmatel.c:2224: > > > dac_nids=2 (0x5/0x4/0x0/0x0/0x0) > > > > > > Unmuted and adjusted Surround volume, but it made no difference. > > > > > > - Anders > > > > > It's weird that 0xf is in both the line_outs and hp_outs. > > And the hp_outs=1 when there are two items. > > It's due to a fix for an ALC268 laptop that has also two HPs but one > is actually a line-out. Note that hp_outs=1 in the print above. The > 0x0f in hp_outs is simply a garbage. Maybe that patch broke the > double HPs with STAC9228... > > > Takashi > > > ------------------------------ > > Message: 3 > Date: Wed, 20 Feb 2008 11:52:43 +0100 > From: Takashi Iwai <tiwai(a)suse.de> > Subject: Re: [alsa-devel] Problem with DELL XPS M1530 > To: Anders R?nningen <andersronningen(a)gmail.com> > Cc: alsa-devel(a)alsa-project.org > Message-ID: <s5hwsozsxvo.wl%tiwai(a)suse.de> > Content-Type: text/plain; charset=ISO-8859-1 > > At Tue, 19 Feb 2008 19:25:24 +0100, > Anders R?nningen wrote: > > > > Hi Takashi. > > > > Some dmesg output: > > > > [ 14.192000] ALSA > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:2994: > > autoconfig: line_outs=1 (0xf/0x0/0x0/0x0/0x0) > > [ 14.192000] ALSA > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:2998: > > speaker_outs=1 (0xd/0x0/0x0/0x0/0x0) > > [ 14.192000] ALSA > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:3002: > > hp_outs=1 (0xa/0xf/0x0/0x0/0x0) > > [ 14.192000] ALSA > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:3003: > > mono: mono_out=0x0 > > [ 14.192000] ALSA > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/hda_codec.c:3011: > > inputs: mic=0xe, fmic=0x0, line=0x0, fline=0x0, cd=0x0, aux=0x0 > > [ 14.196000] ALSA > > > /mnt/storage/source/alsa/alsa-driver-hg20080217/pci/hda/../../alsa-kernel/pci/hda/patch_sigmatel.c:2224: > > dac_nids=2 (0x5/0x4/0x0/0x0/0x0) > > > > Unmuted and adjusted Surround volume, but it made no difference. > > Please upload the alsa-info.sh output again. No difference in the > output but there must be a difference in the codec setting. > > Also, just to make the situation clear: > the problem is that the speaker and the rear HP don't give sound > output even if you *don't* plug in the front HP, right? > > > Takashi > > > ------------------------------ > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > End of Alsa-devel Digest, Vol 12, Issue 70 > ****************************************** > -- Mvh, Anders

3 5

Re: [alsa-devel] Problem with DELL XPS M1530
by Anders Rønningen 21 Feb '08

21 Feb '08

Hi. I am the mentioned user with this problem. Just thought I'd give you a little more info on this problem. What wishie described was correct, except it's the internal speakers and the /left/ hp-jack that stopped working, while the right one is still ok. Like he wrote, the reason we started this debugging was to get mic sound on my system. The thing I think is worth mentioning is that with alsa 1.0.14 on an out-of-the box Ubuntu Gutsy, both hp-jacks and the internal speakers worked for me. People in #alsa told me that the module was not loaded correctly, but whatever was loaded _almost_ worked well :-) - Anders

3 7

[alsa-devel] snd-hda-intel AD1981 - the microphone doesn't work
by Robert Gonciarz 20 Feb '08

20 Feb '08

Hi, I'm trying to activate a microphone (I have just external one) in my HP NX7300 (RU374ES) notebook (it has two jacks without internal mic) for six months. Alsamixer says that it's AD1981 chipset. The sound works great execept two things: - it's too silent when I set almost the maximum level (if you compare it with Windows XP driver) - but it's not so bad. It is said that a tothem can change some hidden settings to make it louder. - the microphone doesn't work even though I setted it in alsamiser (the settings: <capture tab> the "Mic" is red, "Mic boss" is setted with 67/67, "Capture" 80/80, Mix is blue and "-----", "Digital" 62/62, "Docking-" is blue and "----", "Internal" 67/67. The mic doesn't capture any voice at all. I was trying to load the module with different names: default, hp and toshiba works but the mic still doesn't work. lspci | grep Audio 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) lspci -nv 00:1b.0 0403: 8086:27d8 (rev 01) Subsystem: 103c:30a2 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f4580000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel It was tested with snd-hda-intel module from the lastest sources from your website: alsa-driver-1.0.16rc2. I'm using 2.6.24.1 kernel. At the begining I tried to compile the kernel with a module which was included to it (it was working without a mic) and then I compiled the external module from your web. It was tested with many other kernels. Can you check it please? If you need more information just email me back. Robert

4 12

[alsa-devel] Regarding pointer callback
by Pharaoh . 20 Feb '08

20 Feb '08

Hi, In Writing an ALSA driver, it is written 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. I know from a kernel space ALSA driver, the pointer callback is called after the driver calls snd_pcm_period_elapsed() from the interrupt handler or after a period is consumed. How pointer function of a user space plugin is called? I have a user space pcm external plugin which updates the buffer counter after every period is consumed, but when will it be called? How does the ALSA lib know when to call it since there is no snd_pcm_period_elapsed() in user space. -Phraoh.

1 0

[alsa-devel] Capture and playabck together
by Emmanuel Milou 20 Feb '08

20 Feb '08

Hi all, I am developping an open-source C++ softphone based on Alsa. We used to use Portaudio but we recently decided to switch to Alsa. I am quite unexperimented in Alsa dev and I got some difficulties to make it work fine. My capture and playback devices are plughw:0,0. I am using read/write transfers. When I disable the capture, playback works fine; when I disable the playback, capture works fine. The problems occurs when I used them together. If I set hardware parameters for both, the playback sound is awful and there is no capture, and finally core dumped. If I set hardware parameters for the playback stream only, the playback works fine, but no capture, I just get an echo with an input/ouput error. Where do you think the problem comes from? Isn't it possible to set hardware configuration for playback and capture? Is there a hardware ring buffer for each stream ? Thanks for your help Manu

1 0

[alsa-devel] [PATCH 0/2] TLV320AIC3X MCLK and rate updates
by Jarkko Nikula 20 Feb '08

20 Feb '08

Hi Two patches to TLV320AIC3X SoC codec driver. First one fixes typo (?) for 64 kHz sample rate and second one adds support to 12 MHz MCLK used e.g. in Nokia N810 Internet Tablet. Patches are generated from 2.6.25-rc2-omap1 tree but they apply to alsa git and alsa-kernel hg trees as well. -- Jarkko

2 3

[alsa-devel] Merging hg sources into kernel tree
by Andrew Boettcher 20 Feb '08

20 Feb '08

Is there a script to merge the hg sources into a kernel tree? If not do I need to worry about any changes other than the include/ directory? I have another module (cx88-alsa) that is in v4l but needs the newer alsa tree or I get "cx88_alsa: disagrees about version of symbol xxx", so I have to merge the sources for now. Andrew Boettcher

3 3

[alsa-devel] Moving X Window windows causes audio stuttering
by Timur Tabi 20 Feb '08

20 Feb '08

On our system, using mplayer to play a movie that has 44.1KHz audio (hardware only supports 48KHz) can cause audio stuttering if we're using OSS emulation, but not if we're using native ALSA. Is this a known problem? Does OSS emulation hog the CPU? -- Timur Tabi Linux kernel developer at Freescale

2 1

Re: [alsa-devel] [PATCH] Driver for Emagic Audiowerk 2
by Takashi Iwai 20 Feb '08

20 Feb '08

At Tue, 19 Feb 2008 00:38:54 +0100, Cédric Brégardis wrote: > > Signed-off-by: Cedric Bregardis <cedric.bregardis(a)free.fr> > > Signed-off-by: Jean-Christian Hassler <jhassler(a)free.fr> Could you avoid HTML mail? I cannot get the patch properly. If embedding text is difficult, rather use an attachment. thanks, Takashi

2 4

[alsa-devel] Ends up with write error
by Ning Zhang 20 Feb '08

20 Feb '08

Hi all, I am writing a ALSA driver for my ARM 926 platform. The ARM communicates with the DSP by accessing a 128-byte shared memory. I don't use IRQ mechanism.(In fact, I am not sure the platform has this mechanism) Here is some code slices: static struct snd_pcm_hardware snd_arch_playback_hw = { .info = (SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER), .formats = SNDRV_PCM_FMTBIT_S16_LE, .rates = (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000 |\ SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |\ SNDRV_PCM_RATE_48000), .rate_min = 8000, .rate_max = 48000, .channels_min = 2, .channels_max = 2, .buffer_bytes_max = 128, .period_bytes_min = 2, .period_bytes_max = 128, .periods_min = 1, .periods_max = 64, }; static snd_pcm_uframes_t snd_arch_pcm_pointer(struct snd_pcm_substream *substream) { … /* * get the current hardware pointer */ current_ptr = arch_fw_read_dsp_reg(chip, AFE_RWADDR) & AFE_RD_ADDR; return bytes_to_frames(runtime, current_ptr); } static int snd_arch_pcm_playback_copy(struct snd_pcm_substream *substream, int channel, snd_pcm_uframes_t pos, void __user *src, snd_pcm_uframes_t count) { …… count = frames_to_bytes(runtime, count); pos = frames_to_bytes(runtime, pos); chip->bufpos = pos; …. spin_lock(chip->reg_lock); if ( count > 0 && count <= MAX_BUF_SIZE ) { if ( copy_from_user(chip->bufptr, src, count) ) { snd_printk(KERN_ERR "can not copy user data!\n"); return -EFAULT; } if ( arch_fill_rx_buf(chip, (signed short*)(chip->bufptr), count) < 0 ) { snd_printk(KERN_ERR "fill rx buffer failed!\n"); return -1; } …………… } spin_unlock(chip->reg_lock); return 0; } The problem is my driver can make sounds, but ends up a write error. After much debugging, I think there might be some problem in the interworking between middle-level driver and the device driver. I found the runtime->control->avail_min=32, and the runtime->buffer_size and runtime->period_size are both 32. So at first middle-level driver call snd_pcm_lib_write1 transfers 32 frames(128 bytes) to the device driver's copy callback function and trigger function. Then when middle-level driver wants to transfer another 32 frames, it calls the pointer callback function and gets the position, because at this time the whole bytes has not been processed completely, so the pointer function's return value must less than 32, and the avail must less than runtime->control_->avail_min, and goes to this flow and ends up a write error. _______________________________________________________________________________ if (((avail < runtime->control->avail_min && size > avail) || (size >= runtime->xfer_align && avail < runtime->xfer_align))) { ……………... long tout; init_waitqueue_entry(&wait, current); add_wait_queue(&runtime->sleep, &wait); while (1) { if (signal_pending(current)) { state = SIGNALED; break; } set_current_state(TASK_INTERRUPTIBLE); snd_pcm_stream_unlock_irq(substream); tout = schedule_timeout(10 * HZ); snd_pcm_stream_lock_irq(substream); if (tout == 0) { if (runtime->status->state != SNDRV_PCM_STATE_PREPARED && runtime->status->state != SNDRV_PCM_STATE_PAUSED) { state = runtime->status->state == SNDRV_PCM_STATE_SUSPENDED ? SUSPENDED : EXPIRED; break; } } switch (runtime->status->state) { ………….. : state = ERROR; goto _end_loop; default: break; } avail = snd_pcm_playback_avail(runtime); if (avail >= runtime->control->avail_min) { state = READY; break; } } _end_loop: remove_wait_queue(&runtime->sleep, &wait); switch (state) { ……. case EXPIRED: snd_printd("playback write error (DMA or IRQ trouble?)\n"); err = -EIO; goto _end_unlock; ……… } } This code is a part of snd_pcm_lib_write1() in sound/core/pcm_lib.c I think that I misunderstood the mechanism of middle-level driver. Could you please correct me? What should the pointer callback function return? What's it for? How comes the runtime->control->avail_min? Because I don't use the IRQ, so should I use the snd_pcm_period_elapsed function? And where? ALSA Version is 1.0.14rc1 and I use alsa-lib-1.0.15. Can someone comment on this and give me some hints to solve this problem? Thanks in advance. BRs, David

1 0