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

Re: [alsa-devel] Mic not working on Dell Vostro 1700 by default
by Takashi Iwai 23 Dec '09

23 Dec '09

At Wed, 23 Dec 2009 14:51:25 +0100, Anisse Astier wrote: > > On Wed, 23 Dec 2009 08:31:40 +0100, Takashi Iwai <tiwai(a)suse.de> wrote : > > > At Tue, 22 Dec 2009 18:50:28 +0100, > > Anisse Astier wrote: > > > > > > On Tue, 22 Dec 2009 18:44:04 +0100, Anisse Astier <anisse(a)astier.eu> wrote : > > > > > > > Hi, > > > > > > > > (i'm not subscribed to the list, please cc me in replies) > > > > > > > > So I'm on a Dell Vostro 1700 with latest BIOS (A07). In the default > > > > configuration, the mic is not working. > > > > > > > > But if I append model=dell-m42 when loading snd-hda-intel, it works. > > > > > > > > My alsa-info: > > > > http://www.alsa-project.org/db/?f=8d6f7d613b909c0eef67f93e0e86bf13476e9e54 > > > > > > > > alsa-info with option model=dell-m42 > > > > http://www.alsa-project.org/db/?f=233cee7ffea01b9f46451e64c95c4fc482ab4ee4 > > > > > > > > I don't know if dell-m42 is enough, I chose it because it was used for the > > > > Dell Vostro 1500, for which there was a pci quirk in patch_sigmatel.c, > > > > and that seemed close enough. Everything seems to work properly though. > > > > > > > > I don't know if it's possible to add the same pci-quirk (or a similar one) > > > > in patch_sigmatel.c , or any dmi-based quirk, but I'd like to help in > > > > doing so. > > > > > > > > I compiled a working hda-verb should some remote debugging be needed. > > > > > > > > > > I forgot to add that this is also working with dell-m44. A pointer: > > > https://wiki.ubuntu.com/InstallingUbuntuOnADellVostro1700#AUDIO : > > > suggestion to add this option by default on ubuntu. > > > > So, which is better, m42 or m44? > > This can be checked only with a real hardware... > > > > I did some tests today, and I'm unable to tell. Both behave the same with > external headphones, internal speakers, external mic, internal mic. Jack > detection works flawlessly with both. From time to time the codec will > timeout and driver switch to polling mode, but it's independent from the > option model. > I really don't know what else to test. Maybe the different is either the digital I/O or the docking station. > But IMO, we should go with m42. According to patch_sigmatel.c dell-m42 is > made for Vostro 1500, and this should be tho closest to the 1700. It > seems they have the same motherboard. I attached a diff between the two > laptops' lspci. Only the graphics card changes. OK, then let's take dell-m42. thanks, Takashi

1 0

Re: [alsa-devel] [2.6.33-rc1] [SOUND] HDA: high cpu usage, noise
by Takashi Iwai 23 Dec '09

23 Dec '09

At Wed, 23 Dec 2009 15:27:08 +0100, Éric Piel wrote: > > Op 22-12-09 10:17, Takashi Iwai schreef: > : > >>> Another thing to try is to replace the whole HD-audio stack with the > >>> last working one (was it 2.6.32?), and check whether it works with > >>> 2.6.32 core. > >> Could you give more details on how to do this? > >> Does it consist in taking the sound/ directory of 2.6.32 and copying it > >> over 2.6.33-rc1 ? Or less files? > > > > I'd try first only sound/pci/hda/* files. > > > Brute-force reverting these files to the version of 2.6.32.2 does fix > the problem. OK, that's good to know. > When I find time, I'll try to git bisect on this particular directory... > but anyone willing to try to beat me at this is welcome, as Christmas is > going to keep me rather busy ;-) bisecting would be indeed helpful. It needs to be done only in the above directory, so there shouldn't be much. thanks, Takashi

1 0

[alsa-devel] HDA model specification and a topic/hda bug?
by Paul "TBBle" Hampson 23 Dec '09

23 Dec '09

Hi, I've a couple of questions. Firstly, I've been through "MORE NOTES ON HD-AUDIO DRIVER" and was able to use codecgraph and hda-analyzer to identify non-disabled speakers on my laptop (the laptop claims four speakers plus a subwoofer, Alsa's autodetect only enables the subwoofer for output) but I'm having trouble working out how to convert this knowledge into either changes to patch_realtek.c or even a patch file to feed the driver, so that it comes up correctly by default. I do have a printout of the Intel HDA spec's codec layout chapter, but I haven't read it yet. I'm hoping not to have to, but I suspect I will. Anyway, I've been tracking topic/hda from the Alsa git repository, hoping it'll magically fix my sound-card detection, but I'm having a problem with 5b0cb1d850c26893b1468b3a519433a1b7a176be (ALSA: hda - add more NID->Control mapping) which I believe is part of the 1.0.22 release. For reference, it's an MSI GT725 laptop... Basically, snd_hda_add_nids is being called with an array of three nids, the third of which is 0. I've been throwing snd_kprintd statements at it, and it seems that I see input_mux->num_items as 3 (which I _think_ is correct, I have a buit-in microphone, microphone jack and line-in jack) but I only have two analog aud_in nodes (0x8 and 0x9, 0x7 is a vendor node). _From the look of it, this call to snd_hda_add_nids is wrong: err = snd_hda_add_nids(codec, kctl, i, spec->capsrc_nids, spec->input_mux->num_items); it maybe should be err = snd_hda_add_nids(codec, kctl, i, spec->capsrc_nids, spec->num_adc_nids); if I'm understanding patch_alc882 correctly, although that looks wrong in pretty much every other use I can see. It's prolly me not understanding how the HDA stuff ties together very well, but right now the inbuilt sound fails to load with a -22 (-EINVAL) error, which is snd_hda_add_nid rejecting a nid <= 0. I suspect http://bugs.gentoo.org/show_bug.cgi?id=297454 is the same problem, and https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4846 looks like it too. On searching, https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4841 is exactly the same problem, and the same model laptop as mine. I'm happy to do debugging and whatnot, since I hope to actually work out the correct patch overrides to get my laptop speakers properly working so any debugging I do for this problem will hopefully improve my understanding of the HDA driver.

2 1

Re: [alsa-devel] Mic not working on Dell Vostro 1700 by default
by Takashi Iwai 23 Dec '09

23 Dec '09

At Tue, 22 Dec 2009 18:50:28 +0100, Anisse Astier wrote: > > On Tue, 22 Dec 2009 18:44:04 +0100, Anisse Astier <anisse(a)astier.eu> wrote : > > > Hi, > > > > (i'm not subscribed to the list, please cc me in replies) > > > > So I'm on a Dell Vostro 1700 with latest BIOS (A07). In the default > > configuration, the mic is not working. > > > > But if I append model=dell-m42 when loading snd-hda-intel, it works. > > > > My alsa-info: > > http://www.alsa-project.org/db/?f=8d6f7d613b909c0eef67f93e0e86bf13476e9e54 > > > > alsa-info with option model=dell-m42 > > http://www.alsa-project.org/db/?f=233cee7ffea01b9f46451e64c95c4fc482ab4ee4 > > > > I don't know if dell-m42 is enough, I chose it because it was used for the > > Dell Vostro 1500, for which there was a pci quirk in patch_sigmatel.c, > > and that seemed close enough. Everything seems to work properly though. > > > > I don't know if it's possible to add the same pci-quirk (or a similar one) > > in patch_sigmatel.c , or any dmi-based quirk, but I'd like to help in > > doing so. > > > > I compiled a working hda-verb should some remote debugging be needed. > > > > I forgot to add that this is also working with dell-m44. A pointer: > https://wiki.ubuntu.com/InstallingUbuntuOnADellVostro1700#AUDIO : > suggestion to add this option by default on ubuntu. So, which is better, m42 or m44? This can be checked only with a real hardware... thanks, Takashi

1 0

Re: [alsa-devel] Installing a "different" version of Alsa
by Brian Welch 23 Dec '09

23 Dec '09

Message: 1 Date: Sun, 20 Dec 2009 12:47:28 +0000 From: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Subject: Re: [alsa-devel] Installing a "different" version of Alsa To: Brian Welch <Brian-Welch(a)cox.net> Cc: alsa-devel(a)alsa-project.org Message-ID: <20091220124727.GA2881(a)sirena.org.uk> Content-Type: text/plain; charset=us-ascii On Sat, Dec 19, 2009 at 09:48:16PM -0700, Brian Welch wrote: >> When I use kbuild to build my custom sound hardware driver against the >> SDK >> in the kernel, it always trys to pick up the older ALSA header files that >> are in the >> SDK, but I want to use the newer versions that are in the directory with >> the newer >> version of ALSA. What the best way to make sure I get the correct >> headers? >> Is what I'm trying "dangerous" and should I be going about this a >> different way? > The best way of integrating with the toolchain you're using will usually > depend on the toolchain - you'll generally be able to get better advice > about how to work with the toolchain by asking people who work with the > toolchain. I guess I don't understand exactly what you mean by "toolchain." I've already contacted the people that package up the SDK and they said I should solve it myself. I originally hoped that I could just re-build the kernel without Alsa built-in, then add my new version of Alsa, but they claim that causes other issues (i.e. no sound at all).

2 3

[alsa-devel] ASoC updates for 2.6.33
by Mark Brown 22 Dec '09

22 Dec '09

The following changes since commit 48c03ce72f2665f79a3fe54fc6d71b8cc3d30803: Guennadi Liakhovetski (1): ASoC: wm8974: fix a wrong bit definition are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.33 Guennadi Liakhovetski (1): ASoC: add missing parameter to mx27vis_hifi_hw_free() Uwe Kleine-König (1): ASoC: sh: FSI:: don't check platform_get_irq's return value against zero sound/soc/imx/mx27vis_wm8974.c | 3 ++- sound/soc/sh/fsi.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-)

2 1

Re: [alsa-devel] [2.6.33-rc1] [SOUND] HDA: high cpu usage, noise
by Takashi Iwai 22 Dec '09

22 Dec '09

At Tue, 22 Dec 2009 16:15:57 +0100, Éric Piel wrote: > > Op 22-12-09 10:17, Takashi Iwai schreef: > : > >>> It shouldn't. The polling mode doesn't give any behavioral change, > >>> and the CPU usage can't be that high. > >>> > >>> Try is to pass bdl_pos_adj=0 option. This should reduce the CPU hog, > >>> at least. But it doesn't mean it's the right fix... > >> I'll try > Just tried: it doesn't have any effect, as enable_msi=0. Still 25% of > the CPU used, as before. > $ cat bdl_pos_adj > 0,-1,-1,-1,-1,-1,-1,-1 > > Could it be coming from the beeper? Also, just in case it can help, > attached is my .config . Do you have multiple HD-audio devices? See /proc/asound/cards. If there are multiple, you need to pass a value for each. Takashi

1 0

[alsa-devel] [PATCH 7/7] ASoC: sh: FSI:: don't check platform_get_irq's return value against zero
by Uwe Kleine-König 22 Dec '09

22 Dec '09

platform_get_irq returns -ENXIO on failure, so !irq was probably always true. Better use (int)irq <= 0. Note that a return value of zero is still handled as error even though this could mean irq0. This is a followup to 305b3228f9ff4d59f49e6d34a7034d44ee8ce2f0 that changed the return value of platform_get_irq from 0 to -ENXIO on error. Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Cc: David Vrabel <dvrabel(a)arcom.com> Cc: Greg Kroah-Hartman <gregkh(a)suse.de> Cc: Liam Girdwood <lrg(a)slimlogic.co.uk> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.de> Cc: Kuninori Morimoto <morimoto.kuninori(a)renesas.com> Cc: Paul Mundt <lethal(a)linux-sh.org> Cc: alsa-devel(a)alsa-project.org --- sound/soc/sh/fsi.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/sh/fsi.c b/sound/soc/sh/fsi.c index 9c49c11..42813b8 100644 --- a/sound/soc/sh/fsi.c +++ b/sound/soc/sh/fsi.c @@ -876,7 +876,7 @@ static int fsi_probe(struct platform_device *pdev) res = platform_get_resource(pdev, IORESOURCE_MEM, 0); irq = platform_get_irq(pdev, 0); - if (!res || !irq) { + if (!res || (int)irq <= 0) { dev_err(&pdev->dev, "Not enough FSI platform resources.\n"); ret = -ENODEV; goto exit; -- 1.6.5.2

3 3

Re: [alsa-devel] [PATCH] ASoC: add missing parameter to mx27vis_hifi_hw_free()
by Mark Brown 22 Dec '09

22 Dec '09

On Tue, Dec 22, 2009 at 09:26:10AM +0100, Guennadi Liakhovetski wrote: > Commit 2ccafed4 added an extra parameter to the DAI .set_pll() method, but > it missed this call in sound/soc/imx/mx27vis_wm8974.c. Appled, thanks.

1 0

[alsa-devel] io plugin: polling on unix socket, socket buffer sizes ?
by Stefan Schoenleitner 22 Dec '09

22 Dec '09

Hi, I'm currently writing an alsa io plugin that should exchange PCM samples with another piece of software over a unix socket. More precisely exactly 160 PCM samples with 16bit each should be exchanged at a time. AFAIK the alsa plugin framework works by utilizing poll(). Thus if the plugin is used for playback it would use POLLOUT on the socket to see if the next chunk of data can be written to the socket without blocking. By reading quite a lot of alsa code (including pcm_bluetooth.c from bluez) it seems that I need to set the socket buffer size to a value small enough, right ? Thus if I would like to send one period consisting of 160 samples (with 16bits each) at a time, I would need to set the unix send buffer size to 320 bytes. This way some kind of handshaking between my application and the alsa plugin would be established: Each time the application reads a full period of data from the socket, the alsa plugin will start to send the next period as poll() will return the POLLOUT event. (Thus the transfer callback function would be called in the plugin code.) Is this correct so far ? To test the behavior I wrote two small code snippets: One is unix socket reader that reads a chunk of 10 bytes at a time and then sleeps for 10 seconds. The socket recv buffer size SO_RCVBUF has been set to 10 bytes with setsockopt(). The other snippet is the unix socket writer: It sets the socket send buffer size SO_SNDBUF to 10 bytes so that after writing 10 bytes to the socket, poll with POLLOUT would block until the other end (the reader) reads some bytes and the send buffer is drained. The reader polls on the socket with a timeout of 1 sec and in case poll returns the POLLOUT event, it writes a chunk of 10 bytes to the socket. With these small code snippets I would expect the following behavior:

1 0