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

[alsa-devel] [PATCH] hda - HDMI sticky stream tag support
by Wu Fengguang 25 Dec '09

25 Dec '09

When we run the following commands in turn (with CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0), speaker-test -Dhw:0,3 -c2 -twav # HDMI speaker-test -Dhw:0,0 -c2 -twav # Analog The second command will produce sound in the analog lineout _as well as_ HDMI sink. The root cause is, device 0 "reuses" the same stream tag that was used by device 3, and the "intelhdmi - sticky stream id" patch leaves the HDMI codec in a functional state. So the HDMI codec happily accepts the audio samples which reuse its stream tag. The proposed solution is to remember the last device each azx_dev was assigned to, and prefer to 1) reuse the azx_dev (and hence the stream tag) the HDMI codec last used 2) or assign a never-used azx_dev for HDMI With this patch and the above two speaker-test commands, HDMI codec will use stream tag 8 and Analog codec will use 5. The stream tag used by HDMI codec won't be reused by others, as long as we don't run out of the 4 playback azx_dev's. The legacy Analog codec will continue to use stream tag 5 because its device id is 0 (this is a bit tricky). Signed-off-by: Wu Fengguang <fengguang.wu(a)intel.com> --- sound/pci/hda/hda_intel.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) --- sound-2.6.orig/sound/pci/hda/hda_intel.c 2009-12-25 12:17:28.000000000 +0800 +++ sound-2.6/sound/pci/hda/hda_intel.c 2009-12-25 12:41:02.000000000 +0800 @@ -356,6 +356,7 @@ struct azx_dev { */ unsigned char stream_tag; /* assigned stream */ unsigned char index; /* stream index */ + int device; /* last device number assigned to */ unsigned int opened :1; unsigned int running :1; @@ -1441,10 +1442,13 @@ static int __devinit azx_codec_configure */ /* assign a stream for the PCM */ -static inline struct azx_dev *azx_assign_device(struct azx *chip, int stream) +static inline struct azx_dev * +azx_assign_device(struct azx *chip, struct snd_pcm_substream *substream) { int dev, i, nums; - if (stream == SNDRV_PCM_STREAM_PLAYBACK) { + struct azx_dev *res = NULL; + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { dev = chip->playback_index_offset; nums = chip->playback_streams; } else { @@ -1453,10 +1457,15 @@ static inline struct azx_dev *azx_assign } for (i = 0; i < nums; i++, dev++) if (!chip->azx_dev[dev].opened) { - chip->azx_dev[dev].opened = 1; - return &chip->azx_dev[dev]; + res = &chip->azx_dev[dev]; + if (res->device == substream->pcm->device) + break; } - return NULL; + if (res) { + res->opened = 1; + res->device = substream->pcm->device; + } + return res; } /* release the assigned stream */ @@ -1505,7 +1514,7 @@ static int azx_pcm_open(struct snd_pcm_s int err; mutex_lock(&chip->open_mutex); - azx_dev = azx_assign_device(chip, substream->stream); + azx_dev = azx_assign_device(chip, substream); if (azx_dev == NULL) { mutex_unlock(&chip->open_mutex); return -EBUSY;

2 1

Re: [alsa-devel] [PATCH] Fix indentation in pcm_native.c
by Takashi Iwai 25 Dec '09

25 Dec '09

At Thu, 24 Dec 2009 01:17:46 +0100 (CET), Guennadi Liakhovetski wrote: > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski(a)gmx.de> Applied now. Thanks. Takashi > --- > diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c > index ab73edf..cf57964 100644 > --- a/sound/core/pcm_native.c > +++ b/sound/core/pcm_native.c > @@ -1917,13 +1917,13 @@ int snd_pcm_hw_constraints_complete(struct snd_pcm_substream *substream) > > err = snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_RATE, > hw->rate_min, hw->rate_max); > - if (err < 0) > - return err; > + if (err < 0) > + return err; > > err = snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, > hw->period_bytes_min, hw->period_bytes_max); > - if (err < 0) > - return err; > + if (err < 0) > + return err; > > err = snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_PERIODS, > hw->periods_min, hw->periods_max); >

1 0

[alsa-devel] Personal invitation from Kunal Narkhede
by Kunal Narkhede 24 Dec '09

24 Dec '09

If you are not able to click these links, click the following: « Show content » and try again. E-mail sent 12/24/2009 9:01:58 AM, by Kunal Narkhede: Hello, Finally, a smart and simple way to manage your contacts! With UNYK, I put all my contacts together in <b>one address book</b> that is <b>automatically updated</b>. One of my contacts changes his or her information at UNYK.com: My address book is updated. I change information at UNYK.com: My contacts address books are updated. Simple, but life-changing! Can I add you as one of my contacts? To accept, click here! http://www.unyk.com/ml/245/1/?i=C7B72DD0179E4FD7A6DED23A2976A060&s=17267503 You too can create your own smart address book. Kunal Narkhede UNYK : ESJ 288 Please do not reply to this email directly. Questions? Contact us - http://unyk.com/en/Contact UNYK Inc., 1010 de Serigny, suite 820, Longueuil, QC, J4K 5G7, Canada. I no longer wish to receive invitations to join UNYK from Kunal Narkhede: Unsubscribe http://www.unyk.com/ml/245/74/?mid=9E98A4AA807983A0&email=alsa-devel@alsa-p… I never again wish to receive invitation to join UNYK: Unsubscribe http://www.unyk.com/ml/245/2/?i=C7B72DD0179E4FD7A6DED23A2976A060&s=17267503 UNYK, the first smart address book that updates itself!

1 0

Re: [alsa-devel] [PATCH] ASoC: fix params_rate() macro use in several codecs
by Mark Brown 24 Dec '09

24 Dec '09

On Thu, Dec 24, 2009 at 01:13:51AM +0100, Guennadi Liakhovetski wrote: > Sevelar ASoC codec drivers wrongly assume, that the params_rate() macro > returns one of SNDRV_PCM_RATE_* defines instead of the actual numerical > sampling rate. Fix them. > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski(a)gmx.de> Applied, thanks.

1 0

Re: [alsa-devel] [PATCH] ASoC: fix params_rate() macro use in several codecs
by Liam Girdwood 24 Dec '09

24 Dec '09

On Thu, 2009-12-24 at 01:13 +0100, Guennadi Liakhovetski wrote: > Sevelar ASoC codec drivers wrongly assume, that the params_rate() macro > returns one of SNDRV_PCM_RATE_* defines instead of the actual numerical > sampling rate. Fix them. > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski(a)gmx.de> > --- Acked-by: Liam Girdwood <lrg(a)slimlogic.co.uk>

1 0

[alsa-devel] need help with io plugin programming: how to add delay ?
by Stefan Schoenleitner 23 Dec '09

23 Dec '09

Hi, I would like to write a simple alsa io plugin that takes some amount of PCM samples and sends them to a socket in a timely manner (this would be playback). Later on it should work the other way round as well (recording). (Well, actually I have been working on this for a month already but so far I still did not manage to get a working solution.) However, if the PCM stream comes from something prerecorded (i.e. a wav file) there needs to be some kind of delay. If for example the wav file would have a sampling rate of 8 kHz, 16 bit resolution and one period should consist of 160 samples, it would be necessary to write on period exactly each 20ms. For this reason delay needs to be added somewhere so that each 20ms exactly one period is begin sent to the socket. Otherwise all the PCM samples would be just immediately written to the socket without any delay. I read a lot of other alsa plugin code but still I have found no way to properly solve the delay problem. * Where and how do I need to add delay ?? My first approach was to add delay by sleeping in the transfer callback function. After I had implemented that solution (and it did not work that well) I was told that this is not the proper way to do it. * What is the proper way then ? I was told that the alsa plugin framework is poll based and I should come up with a poll based solution. However, I can not just let the alsa io plugin poll for POLLOUT on the socket as this would not add any delay at all. (It would just wait until new data can be written to the socket.) After looking at the bluetooth alsa plugin I came up with another idea (and my second approach): Basically it should be possible to create an independent timing thread in the alsa plugin that writes dummy data (e.g. a single byte) to a pipe each period (thus in my case each 20ms). The plugin would then poll for POLLIN on the above mentioned pipe and poll for POLLOUT on the socket at the same time. This way the transfer callback function would be called if and only if the following two conditions are met: * 20 ms period time has passed * the socket can accept new data * Would this solution be the proper way ? Another solution (my third one already) would be to introduce *no* delay in the alsa plugin itself, but do everything in the application that is listening on the socket. For this reason the application would read one period, process the data and then sleep for the rest of the time until the time for one period (i.e. 20ms) is over. After that the next period is read from the socket and so forth. The alsa plugin would then "automatically" write new data to the socket each time the application listening to that socket reads data and there is free space in the socket send buffer. * Once again, would this be a proper solution ? * If so, how do I know when to increment the hardware pointer ? (- After the send() call in the transfer callback function ? - Using an independent thread in the plugin that just increments the hardware pointer each 20ms ?) - something even more complex ?) My guess is that the third solution (delay is added in the application that listens to the socket) might work well as the delay is added at the end of the "audio processing chain" which makes it less sensitive to delays that are introduced in between. * Is this correct ? I would appreciate any help as I have invested way too much time in this already. cheers, stefan

4 11

[alsa-devel] ASoC update for 2.6.33
by Mark Brown 23 Dec '09

23 Dec '09

The following changes since commit 1628af5adf64cc2960bce81009f119de822f876e: Guennadi Liakhovetski (1): ASoC: add missing parameter to mx27vis_hifi_hw_free() 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 Eric Millbrandt (1): ASoC: Do not write to invalid registers on the wm9712. sound/soc/codecs/wm9712.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)

2 1

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 17:47:21 +0100, Anisse Astier wrote: > > On Wed, 23 Dec 2009 17:28:45 +0100, Anisse Astier <anisse(a)astier.eu> wrote : > > > > > I was confused previously, and i didn't know a pci device could have a > > subsystem vendor/device with id's. > > > > I cleared my head, and did this patch. It's on top of alsa-kernel tree. > > > > Compiling now, I don't see why it wouldn't work, I'll give you an update > > ASAP. > > I works as expected. OK, applied now. Thanks. Takashi

1 0

[alsa-devel] [PATCH 1/1] Do not write to invalid registers on the wm9712.
by Eric Millbrandt 23 Dec '09

23 Dec '09

This patch fixes a bug where "virtual" registers were being written to the ac97 bus. This was causing unrelated registers to become corrupted (headphone 0x04, touchscreen 0x78, etc). This patch duplicates protection that was included in the wm9713 driver. Signed-off-by: Eric Millbrandt <emillbrandt(a)dekaresearch.com> --- sound/soc/codecs/wm9712.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/wm9712.c b/sound/soc/codecs/wm9712.c index 0ac1215..e237bf6 100644 --- a/sound/soc/codecs/wm9712.c +++ b/sound/soc/codecs/wm9712.c @@ -463,7 +463,8 @@ static int ac97_write(struct snd_soc_codec *codec, unsigned int reg, { u16 *cache = codec->reg_cache; - soc_ac97_ops.write(codec->ac97, reg, val); + if (reg < 0x7c) + soc_ac97_ops.write(codec->ac97, reg, val); reg = reg >> 1; if (reg < (ARRAY_SIZE(wm9712_reg))) cache[reg] = val; -- 1.6.3.1 This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email.

3 4

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