- 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 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

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

22 Dec '09

On Tue, 2009-12-22 at 09:26 +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. > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski(a)gmx.de> > --- > sound/soc/imx/mx27vis_wm8974.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/sound/soc/imx/mx27vis_wm8974.c b/sound/soc/imx/mx27vis_wm8974.c > index 0267d2d..07d2a24 100644 > --- a/sound/soc/imx/mx27vis_wm8974.c > +++ b/sound/soc/imx/mx27vis_wm8974.c > @@ -180,7 +180,8 @@ static int mx27vis_hifi_hw_free(struct snd_pcm_substream *substream) > struct snd_soc_dai *codec_dai = rtd->dai->codec_dai; > > /* disable the PLL */ > - return codec_dai->ops->set_pll(codec_dai, IGNORED_ARG, 0, 0); > + return codec_dai->ops->set_pll(codec_dai, IGNORED_ARG, IGNORED_ARG, > + 0, 0); > } > > /* Acked-by: Liam Girdwood <lrg(a)slimlogic.co.uk>

1 0

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 10:15:20 +0100, Éric Piel wrote: > > Op 22-12-09 08:04, Takashi Iwai schreef: > > At Mon, 21 Dec 2009 20:08:34 +0100, > > Éric Piel wrote: > : > >> Could it be coming from this timeout? > > > > 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 > > > > > 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. Takashi

1 0

[alsa-devel] [PATCH 1/2] ALSA: pcm - Ensure wakeup at each periodic interrupt
by jassisinghbrar＠gmail.com 22 Dec '09

22 Dec '09

From: Jassi Brar <jassi.brar(a)samsung.com> The check for at least 'avail_min' available data before calling wake_up doesn't always hold good as it does not guarantee callbacks at each periodic interrupt. An example of such situation is snd_pcm_lib_read1/write1 consuming some space of the period and going to sleep from wait_for_avail_min upon syncing with the DMA pointer. Clearly just the remainder of period size is needed, but wake_up is called only after _two_ periodic interrupts from that point. Signed-off-by: Jassi Brar <jassi.brar(a)samsung.com> --- sound/core/pcm_lib.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index 30f4108..ee2d7b9 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -189,7 +189,7 @@ snd_pcm_update_hw_ptr_pos(struct snd_pcm_substream *substream, static int snd_pcm_update_hw_ptr_post(struct snd_pcm_substream *substream, struct snd_pcm_runtime *runtime) { - snd_pcm_uframes_t avail; + snd_pcm_uframes_t avail, prd_short; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) avail = snd_pcm_playback_avail(runtime); @@ -208,8 +208,14 @@ static int snd_pcm_update_hw_ptr_post(struct snd_pcm_substream *substream, return -EPIPE; } } - if (avail >= runtime->control->avail_min) + + prd_short = runtime->period_size + - runtime->status->hw_ptr % runtime->period_size; + + if (avail >= runtime->control->avail_min + || avail >= prd_short) wake_up(&runtime->sleep); + return 0; } -- 1.6.2.5

3 8