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

[alsa-devel] No digital output on HP Pavilion dv6936us (intel_hda ALC268), also volume low--help me hack?
by Jens Jorgensen 30 Jan '09

30 Jan '09

Hello, I've got sound working on my laptop but there are two problems I'd like to solve. One is the volume is kind of low. Not so low I'm positive something is wrong, but it seems like it isn't right. Second, and more interesting, is this laptop seems to digital audio output that goes over the HDMI connector. Or, I should say, in Windows XP (installing that was another adventure I would have preferred not to have done) The mixer has a control to enable S/PDIF output. I'm a (non-kernel) c++ developer by trade and I've got a local kernel tree from git and should be able to manage pulling the alsa git as well, so if some alsa person could guide me along in hacking the driver to help me try to get this working that would be great. I ran alsa-info.sh on my box, here's the URL: http://www.alsa-project.org/db/?f=1b5a45d1336cee176dbd99e725a56f7ad4e20b42 -- Jens B. Jorgensen jbj1(a)ultraemail.net

1 0

[alsa-devel] Can DMA address, periods, buffer size, etc change after hw_params is called?
by Hans-Christian Egtvedt 29 Jan '09

29 Jan '09

Hi, I wonder if I must take care handling changes in DMA address, number of periods and period size in the prepare callback? Or are these locked after the first time prepare is called? The reason I ask is because I'm developing a new ALSA driver and I prepare a cyclic DMA transfer in the first prepare callback. Additional calls to prepare will not do anything DMA stuff. The cyclic DMA transfer is then released in the close callback. Should I after the open and hw_params calls be ready to handle any change at all regarding DMA buffer address, periods and/or number of periods? I hope I made sense in this email (-: -- Best regards, Hans-Christian Egtvedt

3 7

[alsa-devel] [PATCH 0/1] ASoC: TWL4030: Analog bypass implementation - try2
by Peter Ujfalusi 29 Jan '09

29 Jan '09

Hello, Second try for the analog bypass implementation. Since the first try most of the things has been turned around - I tried to follow Mark's advice, I hope I managed well enough: [1] New power, codec state handling The codec will be powered at all time, except if the codec's bias level has been set to SND_SOC_BIAS_OFF via the twl4030_set_bias_level call. [2] Keeping the power consumption on the lowest level When the codec is in SND_SOC_BIAS_ON state (playback/recording), there is nothing can be done, the amplifiers are powered, PLL is enabled. When the codec enters to SND_SOC_BIAS_STANDBY state, two thing can happen: - If none of the bypass switches are enabled, than the gain controls for the outputs are forced to power-down mode and the PLL is disabled - If one of the bypass switches are enabled, than the gain controls will be kept in their user configured state and the PLL stays enabled. When the codec is in SND_SOC_BIAS_STANDBY (gains and PLL are disabled), change in the bypass config will trigger an event and if it is needed the gains and PLL will be enabled. Switching all bypass off will switch the gains and PLL off. With the this implementation, there is no visible difference in power consumption compared to the previous, codec off way. So when the codec is in SND_SOC_BIAS_STANDBY mode and all of the bypasses are disabled, the additional power consumption is minimal, if any. --- Peter Ujfalusi (1): ASoC: TWL4030: Add analog loopback support sound/soc/codecs/twl4030.c | 212 +++++++++++++++++++++++++++++++++++++++++--- sound/soc/codecs/twl4030.h | 15 +++ 2 files changed, 214 insertions(+), 13 deletions(-)

2 4

[alsa-devel] [PATCH] ALSA: hda - make alc882_auto_init_input_src aware of selectors
by Herton Ronaldo Krzesinski 29 Jan '09

29 Jan '09

In the case of having a selector instead of mixer while initing input sources, the case that happens with ALC889, we must select instead of muting input. Problem was found while testing with hda-emu. Signed-off-by: Herton Ronaldo Krzesinski <herton(a)mandriva.com.br> --- sound/pci/hda/patch_realtek.c | 21 ++++++++++++++++++--- 1 files changed, 18 insertions(+), 3 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 56adbb8..31a6d40 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6924,18 +6924,21 @@ static void alc882_auto_init_analog_input(struct hda_codec *codec) static void alc882_auto_init_input_src(struct hda_codec *codec) { struct alc_spec *spec = codec->spec; - const struct hda_input_mux *imux = spec->input_mux; int c; for (c = 0; c < spec->num_adc_nids; c++) { hda_nid_t conn_list[HDA_MAX_NUM_INPUTS]; hda_nid_t nid = spec->capsrc_nids[c]; + unsigned int mux_idx; + const struct hda_input_mux *imux; int conns, mute, idx, item; conns = snd_hda_get_connections(codec, nid, conn_list, ARRAY_SIZE(conn_list)); if (conns < 0) continue; + mux_idx = c >= spec->num_mux_defs ? 0 : c; + imux = &spec->input_mux[mux_idx]; for (idx = 0; idx < conns; idx++) { /* if the current connection is the selected one, * unmute it as default - otherwise mute it @@ -6948,8 +6951,20 @@ static void alc882_auto_init_input_src(struct hda_codec *codec) break; } } - snd_hda_codec_write(codec, nid, 0, - AC_VERB_SET_AMP_GAIN_MUTE, mute); + /* check if we have a selector or mixer + * we could check for the widget type instead, but + * just check for Amp-In presence (in case of mixer + * without amp-in there is something wrong, this + * function shouldn't be used or capsrc nid is wrong) + */ + if (get_wcaps(codec, nid) & AC_WCAP_IN_AMP) + snd_hda_codec_write(codec, nid, 0, + AC_VERB_SET_AMP_GAIN_MUTE, + mute); + else if (mute != AMP_IN_MUTE(idx)) + snd_hda_codec_write(codec, nid, 0, + AC_VERB_SET_CONNECT_SEL, + idx); } } } -- 1.6.1

2 1

[alsa-devel] CS4232 Playback bug on Tecra 500
by Stanley Pinchak 29 Jan '09

29 Jan '09

I have been running into the problem briefly mentioned at the wiki entry http://alsa.opensrc.org/index.php/Toshiba_Tecra_500CDT. Playback using the CS4232 driver in native or oss emulation mode fails randomly. Once the failure occurs, subsequent attempts to playback stop shortly after opening the device and tickling the speakers (perhaps the buffer gets filled once). Under heavy network load, the initial failure will occur rather soon, within 15 minutes or so of playback. When I am playing songs from the hard drive, the failure takes a very long time, and when I use oss emulation and play from the harddrive, I have been unable to replicate the bug. The CPU does have the F00F bug if that might make some difference. I have attached a backtrace resulting from the attempts to use aplay after the failure has occurred. I may be able to attempt to capture a backtrace at the initial failure if this would be helpful. There are no obvious error messages in my logfiles or printed to the console when the bug occurs. Please let me know how I can assist in squashing this bug. I attempted to use the alsa-info script, but it appears that the database where it uploads the results is broken at the moment. I have pastebinned the results at http://pastebin.ca/1315459 Thanks Stanley Pinchak

3 11

[alsa-devel] alsa-utils compile issues
by Will Wagner 29 Jan '09

29 Jan '09

Hi All, I have configured alsa-lib 1.0.19 to remove the components I do not want for my embedded arm target. I do this with the configure options: --disable-docs \ --disable-aload \ --disable-rawmidi \ --disable-hwdep \ --disable-seq \ --disable-alisp \ --disable-old-symbols \ --disable-python \ --with-alsa-devdir=/dev \ --with-pcm-plugins="copy linear adpcm rate plug dmix softvol" \ --with-ctl-plugins="" \ --with-versioned="no" \ This builds a much reduced in size alsa-lib However when I then try to build alsa-utils this fails because amidi and seq will not compile with the reduced alsa-lib It seems to be there should be configure options in alsa-utils to disable more of its components than just alsamixer and alsatest. I have worked around this by just removing amidi and seq from the SUBDIRS variable in Makefile.in but perhaps there is a better way of doing this? Thanks, Will -- ------------------------------------------------------------------------ Will Wagner will_wagner(a)carallon.com Development Manager Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA ------------------------------------------------------------------------

2 1

[alsa-devel] ASoC updates for 2.6.30
by Mark Brown 29 Jan '09

29 Jan '09

The following changes since commit 67fcdead3c7424d51e7108c220c9ab1a5e752ed3: Takashi Iwai (1): Merge branch 'topic/snd_card_new-err' into topic/asoc are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.30 Mark Brown (2): ASoC: Fix null string usage with WM8753 DAIs Merge branch 'for-2.6.29' into for-2.6.30 Misael Lopez Cruz (1): ASoC: OMAP: Initialize XCCR and RCCR registers in McBSP DAI driver Peter Ujfalusi (1): ASoC: TWL4030: Add analog loopback support sound/soc/codecs/twl4030.c | 212 ++++++++++++++++++++++++++++++++++++++++--- sound/soc/codecs/twl4030.h | 15 +++ sound/soc/codecs/wm8753.c | 9 ++- sound/soc/omap/omap-mcbsp.c | 4 + 4 files changed, 226 insertions(+), 14 deletions(-)

2 1

[alsa-devel] Cannot record from front pluggable mic on 82801H (ICH8 Family) sound card
by Vincent 29 Jan '09

29 Jan '09

Hi, I'm working on a Dell 1525 and I want to plug a mic into the front mic port in order to have a "clean" record. But when it doesn't record anything, all I can have is the noise from the external mic. Is there any specific actions I forgot to do? Here is my alsa-info output : http://www.alsa-project.org/db/?f=a9066fcfe52fa0dd7d9bcd65214855c84592bd25 Thanks, Vincent

4 9

[alsa-devel] ASoC updates for 2.6.29
by Mark Brown 29 Jan '09

29 Jan '09

The following changes since commit 43d50807dbf47a139f83660fec14aebe936b3c80: Peter Ujfalusi (1): ASoC: Add missing comma to SND_SOC_DAPM_SWITCH_E in soc-dapm.h are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.29 Mark Brown (1): ASoC: Fix null string usage with WM8753 DAIs Misael Lopez Cruz (1): ASoC: OMAP: Initialize XCCR and RCCR registers in McBSP DAI driver sound/soc/codecs/wm8753.c | 9 ++++++++- sound/soc/omap/omap-mcbsp.c | 4 ++++ 2 files changed, 12 insertions(+), 1 deletions(-)

2 1

[alsa-devel] [2.6.29-rc3][PATCH 0/1] ASoC: OMAP: Initialize XCCR and RCCR registers in McBSP DAI driver
by Jarkko Nikula 29 Jan '09

29 Jan '09

Hi I'm sending this on behalf of Misael Lopez Cruz with commit id for counterpart patch corrected. This is a fix for 2.6.29. There are some OMAP3 based boards where bootloader is clearing the McBSP XCCR and RCCR register thus causing that DMA is not working with OMAP McBSP DAI driver. As now there is commit 3127f8f8595a064b3f1a1837fea2177902589ac3 in mainline writing those registers, we must initialize them here since otherwise DMA is not working with McBSP DAI driver in any OMAP3 or 2430 based board. -- Jarkko

2 3