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

[alsa-devel] HDA: Enable chipset gcap usage
by Tobin Davis 08 Jan '08

08 Jan '08

Summary: hda_intel.c use gcap register to determine number of streams supported by southbridge. This patch removes hardcoded values for the number of streams supported by the southbridge in most chipsets, and reads these values from the chipset directly. Most systems are hardwired for 4 streams in each direction, but newer chipsets change that capability. Signed off by Tobin Davis <tdavis(a)dsl-only.net>

2 5

Re: [alsa-devel] fujitsu siemens amilo la 1703 vt1807 hda intel card problem
by Tobin Davis 07 Jan '08

07 Jan '08

The information you provided is good, we're just a bit behind. I'm trying to get some programming specs for this codec now. In the mean time, could you try using a tip build of the alsa driver? You can download it here: ftp://ftp.suse.com/pub/projects/alsa/snapshot/driver/ This may have some newer code that will enable your audio. Also, try the drivers on http://viaarena.com. THey may have an updated version that hasn't hit the main tree yet. Tobin On Mon, 2008-01-07 at 21:59 +0100, Norayr Chilingaryan wrote: > Excuse me for bothering you. > May be I need to provide other info? > Did you receive the link? > Di you have any ideas? > > Thank you > > Norayr > > > On Jan 5, 2008 5:53 PM, Norayr Chilingaryan < gnorayr(a)gmail.com> > wrote: > > http://pastebin.ca/842745 > > Thank you very much! > > > > > > On Jan 5, 2008 3:56 AM, Tobin Davis <tdavis(a)dsl-only.net> > wrote: > > Could you download and run > http://bulletproof.servebeer.com/alsa/scripts/alsa-info.sh > > This script will provide a lot of useful information. > After running it, please reply to this email with the > link that the script generates, so we can retrieve the > data, thanks. > > Tobin > > > > > On Sat, 2008-01-05 at 02:48 +0100, Norayr Chilingaryan > wrote: > > > > Hello I decided to write here, firtly, because my > > messages in aksa-user have been ingored, and > > secondly, because I understood that my card most > > probably just unsupported and I must contact > > developers. I have tried to pass options > > model=fujitsu, because I have a fujitsu siements > > notebook etc I have also tried to pass amny other > > options in /etc/modules.d/alsa but withnot effect I > > use gentoo, and the only thing I noticed with latest > > kernels and alsa drivers 1.0.15 is that I can hear > > sound through the headphones, but with low volume. > > It is not possible to get volume higher or speaker > > to make sounds now. So, please, this is information > > about the card 04:01.0 Audio device: VIA > > Technologies, Inc. VIA High Definition Audio > > Controller (rev 10) kakraphoon ~ # > > cat /proc/asound/card0/codec#* | grep Codec Codec: > > VIA VIA VT1708 Codec: Motorola Si3054 Thank you very > > much Norayr > > > > _______________________________________________ > > Alsa-devel mailing list > > Alsa-devel(a)alsa-project.org > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > -- Tobin Davis > > > Hain't we got all the fools in town on our side? And hain't that a big > enough majority in any town? > -- Mark Twain, "Huckleberry Finn" > > > > > -- Tobin Davis Anything anybody can say about America is true. -- Emmett Grogan

1 0

[alsa-devel] Cross compiling alsa-lib (again)
by Adrian McMenamin 07 Jan '08

07 Jan '08

Well, I searched through 96 weeks of archived alsa-devel postings to get to this one: http://article.gmane.org/gmane.linux.alsa.devel/37120 (Which shows I am doing the right thing in any case.) This post recommends this: CFLAGS="-Os -m4 -ml" ./configure --prefix=/usr --host=sh4-unknown-linux-gnu --target=sh4-unknown-linux-gnu --build=i686-pc-linux-gnu I admit to not using the additional cflags stuff before, but even if I use this: CFLAGS="-Os -m4 -ml" ./configure --host=sh4-linux --prefix=/usr CC=/home/adrian/dreamy-linux/buildroot/build_sh4/staging_dir/bin/sh4-linux-gcc --disable-python --disable-rawmidi --enable-static --with-confdir=/home/adrian/dreamy-linux/buildroot/project_build_sh4/dreamcast/root/usr/share/alsa --disable-mixer --enable-static=yes --enable-shared=no --target=sh4-linux --build=i686-linux Followed by: make and make DESTDIR=/home/adrian/dreamy-linux/buildroot/project_build_sh4/dreamcast/root install I still get this: $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: AICA [AICA], device 0: AICA PCM [AICA PCM] Subdevices: 1/1 Subdevice #0: subdevice #0 Followed by: $ aplay -L null Discard all samples (playback) or generate zero samples (capture) $ aplay /aine-email.wav Playing WAVE '/aine-email.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to find an usable access for '(null)' aplay: set_params:895: Access type not available $ aplay -D hw:0,0 /aine-email.wav Playing WAVE '/aine-email.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono aplay: set_params:895: Access type not available Just as before. Any clues?

4 8

Re: [alsa-devel] [PATCH] hda: Advanced power management for codecs.
by Takashi Iwai 07 Jan '08

07 Jan '08

At Mon, 07 Jan 2008 12:31:49 -0500, Matthew Ranostay wrote: > > >> @@ -2830,7 +2883,12 @@ static void stac92xx_hp_detect(struct hd > >> for (i = 0; i < cfg->speaker_outs; i++) > >> stac92xx_set_pinctl(codec, cfg->speaker_pins[i], > >> AC_PINCTL_OUT_EN); > >> - } > >> + for (i = 0; i < cfg->hp_outs; i++) > >> + pwr_state |= 1 << (cfg->hp_pins[i] - 0xa); > >> + } > >> + > >> + /* power down unused ports */ > >> + snd_hda_codec_write(codec, codec->afg, 0, 0x7ec, pwr_state); > >> > > > > Is this verb available on every STAC codec? I took a look at some > > specs but they don't show this verb at all. > > > Ah no this a new one for recent codecs, probably need to some sort of > check for this. Or is it equivalent to power down each unused pin widget? If so, we can do it somehow better in the common code. Takashi

1 0

[alsa-devel] [PATCH] hda: Advanced power management for codecs.
by Matthew Ranostay 07 Jan '08

07 Jan '08

Added support for advanced power management features in new IDT codecs. Inactive ADCs and DACs are changed to D3 mode when not in playback or capture, also inactive line-out/headphone ports are disabled when jack detect does not sense a connection. --- Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> diff -r 5b03c0176aa5 pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Mon Jan 07 13:33:45 2008 +0100 +++ b/pci/hda/patch_sigmatel.c Mon Jan 07 11:22:56 2008 -0500 @@ -160,6 +160,7 @@ struct sigmatel_spec { /* i/o switches */ unsigned int io_switch[2]; + unsigned int io_state[2]; unsigned int clfe_swap; unsigned int aloopback; @@ -438,6 +439,52 @@ static int stac92xx_aloopback_put(struct kcontrol->private_value >> 16, dac_mode); return 1; +} + +static int is_in_dac_nids(struct sigmatel_spec *spec, hda_nid_t nid) +{ + int i; + + for (i = 0; i < spec->multiout.num_dacs; i++) { + if (spec->multiout.dac_nids[i] == nid) + return 1; + } + + return 0; +} + +static int stac92xx_mixer_amp_switch_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); + struct sigmatel_spec *spec = codec->spec; + hda_nid_t nid = kcontrol->private_value & 0xffff; + int idx = (kcontrol->private_value >> 19) & 0xf; + int chs = (kcontrol->private_value >> 16) & 0x3; + long *valp = ucontrol->value.integer.value; + unsigned int wid_caps, val, change; + + change = snd_hda_mixer_amp_switch_put(kcontrol, ucontrol); +#ifdef CONFIG_SND_HDA_POWER_SAVE + if (!is_in_dac_nids(spec, nid)) + nid = spec->adc_nids[idx]; + + val = *valp++; + wid_caps = get_wcaps(codec, nid); + if (wid_caps & AC_WCAP_POWER) { + if (chs == 3) + val |= *valp; + else { /* Center/LFE mixers workaround */ + spec->io_state[--chs] = val; + val |= spec->io_state[chs ? 0 : 1]; + } + + /* set to power state D3 mode if DAC/ADC isn't being used */ + snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_POWER_STATE, + val ? 0: AC_PWRST_D3); + } +#endif + return change; } static struct hda_verb stac9200_core_init[] = { @@ -622,6 +669,20 @@ static struct hda_verb stac9205_core_ini .private_value = verb_read | (verb_write << 16), \ } +#define STAC_CODEC_MUTE_IDX(xname, xcidx, nid, xindex, direction) \ + { \ + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, \ + .name = xname, \ + .index = xcidx, \ + .info = snd_hda_mixer_amp_switch_info, \ + .get = snd_hda_mixer_amp_switch_get, \ + .put = stac92xx_mixer_amp_switch_put, \ + .private_value = HDA_COMPOSE_AMP_VAL(nid, 3, xindex, direction), \ + } + +#define STAC_CODEC_MUTE(xname, nid, xindex, direction) \ + STAC_CODEC_MUTE_IDX(xname, 0, nid, xindex, direction) + static struct snd_kcontrol_new stac9200_mixer[] = { HDA_CODEC_VOLUME("Master Playback Volume", 0xb, 0, HDA_OUTPUT), HDA_CODEC_MUTE("Master Playback Switch", 0xb, 0, HDA_OUTPUT), @@ -640,10 +701,10 @@ static struct snd_kcontrol_new stac92hd7 HDA_CODEC_VOLUME_IDX("Digital Mic Volume", 0x1, 0x14, 0x0, HDA_INPUT), HDA_CODEC_VOLUME_IDX("Capture Volume", 0x0, 0x20, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x20, 0x0, HDA_OUTPUT), - - HDA_CODEC_VOLUME_IDX("Capture Volume", 0x1, 0x21, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE_IDX("Capture Switch", 0x1, 0x21, 0x0, HDA_OUTPUT), + STAC_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x20, 0x0, HDA_OUTPUT), + + HDA_CODEC_VOLUME_IDX("Capture Volume", 0x1, 0x21, 0x1, HDA_OUTPUT), + STAC_CODEC_MUTE_IDX("Capture Switch", 0x1, 0x21, 0x1, HDA_OUTPUT), HDA_CODEC_VOLUME("Front Mic Mixer Capture Volume", 0x1d, 0, HDA_INPUT), HDA_CODEC_MUTE("Front Mic Mixer Capture Switch", 0x1d, 0, HDA_INPUT), @@ -670,10 +731,10 @@ static struct snd_kcontrol_new stac92hd7 HDA_CODEC_VOLUME_IDX("Digital Mic Volume", 0x1, 0x14, 0x0, HDA_INPUT), HDA_CODEC_VOLUME_IDX("Capture Volume", 0x0, 0x20, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x20, 0x0, HDA_OUTPUT), - - HDA_CODEC_VOLUME_IDX("Capture Volume", 0x1, 0x21, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE_IDX("Capture Switch", 0x1, 0x21, 0x0, HDA_OUTPUT), + STAC_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x20, 0x0, HDA_OUTPUT), + + HDA_CODEC_VOLUME_IDX("Capture Volume", 0x1, 0x21, 0x1, HDA_OUTPUT), + STAC_CODEC_MUTE_IDX("Capture Switch", 0x1, 0x21, 0x1, HDA_OUTPUT), HDA_CODEC_VOLUME("Front Mic Mixer Capture Volume", 0x1d, 0, HDA_INPUT), HDA_CODEC_MUTE("Front Mic Mixer Capture Switch", 0x1d, 0, HDA_INPUT), @@ -700,10 +761,10 @@ static struct snd_kcontrol_new stac92hd7 HDA_CODEC_VOLUME_IDX("Digital Mic Volume", 0x1, 0x14, 0x0, HDA_INPUT), HDA_CODEC_VOLUME_IDX("Capture Volume", 0x0, 0x20, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x20, 0x0, HDA_OUTPUT), - - HDA_CODEC_VOLUME_IDX("Capture Volume", 0x1, 0x21, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE_IDX("Capture Switch", 0x1, 0x21, 0x0, HDA_OUTPUT), + STAC_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x20, 0x0, HDA_OUTPUT), + + HDA_CODEC_VOLUME_IDX("Capture Volume", 0x1, 0x21, 0x1, HDA_OUTPUT), + STAC_CODEC_MUTE_IDX("Capture Switch", 0x1, 0x21, 0x1, HDA_OUTPUT), HDA_CODEC_VOLUME("Front Mic Mixer Capture Volume", 0x1d, 0, HDA_INPUT), HDA_CODEC_MUTE("Front Mic Mixer Capture Switch", 0x1d, 0, HDA_INPUT), @@ -730,12 +791,12 @@ static struct snd_kcontrol_new stac92hd7 HDA_CODEC_VOLUME_IDX("Digital Mic Volume", 0x1, 0x19, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME_IDX("Capture Volume", 0x0, 0x1c, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x1c, 0x0, HDA_OUTPUT), + STAC_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x1c, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME_IDX("Capture Mux Volume", 0x0, 0x1a, 0x0, HDA_OUTPUT), - HDA_CODEC_VOLUME_IDX("Capture Volume", 0x1, 0x1d, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE_IDX("Capture Switch", 0x1, 0x1d, 0x0, HDA_OUTPUT), - HDA_CODEC_VOLUME_IDX("Capture Mux Volume", 0x1, 0x1b, 0x0, HDA_OUTPUT), + HDA_CODEC_VOLUME_IDX("Capture Volume", 0x1, 0x1d, 0x1, HDA_OUTPUT), + STAC_CODEC_MUTE_IDX("Capture Switch", 0x1, 0x1d, 0x1, HDA_OUTPUT), + HDA_CODEC_VOLUME_IDX("Capture Mux Volume", 0x1, 0x1b, 0x1, HDA_OUTPUT), HDA_CODEC_MUTE("Analog Loopback 1", 0x17, 0x3, HDA_INPUT), HDA_CODEC_MUTE("Analog Loopback 2", 0x17, 0x4, HDA_INPUT), @@ -751,12 +812,12 @@ static struct snd_kcontrol_new stac92hd7 HDA_CODEC_VOLUME_IDX("Digital Mic Volume", 0x1, 0x19, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME_IDX("Capture Volume", 0x0, 0x1c, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x1c, 0x0, HDA_OUTPUT), + STAC_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x1c, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME_IDX("Capture Mux Volume", 0x0, 0x1a, 0x0, HDA_OUTPUT), - HDA_CODEC_VOLUME_IDX("Capture Volume", 0x1, 0x1d, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE_IDX("Capture Switch", 0x1, 0x1d, 0x0, HDA_OUTPUT), - HDA_CODEC_VOLUME_IDX("Capture Mux Volume", 0x1, 0x1b, 0x0, HDA_OUTPUT), + HDA_CODEC_VOLUME_IDX("Capture Volume", 0x1, 0x1d, 0x1, HDA_OUTPUT), + STAC_CODEC_MUTE_IDX("Capture Switch", 0x1, 0x1d, 0x1, HDA_OUTPUT), + HDA_CODEC_VOLUME_IDX("Capture Mux Volume", 0x1, 0x1b, 0x1, HDA_OUTPUT), { } /* end */ }; @@ -857,7 +918,7 @@ static int stac92xx_build_controls(struc if (err < 0) return err; } - return 0; + return 0; } static unsigned int ref9200_pin_configs[8] = { @@ -1962,7 +2023,7 @@ enum { static struct snd_kcontrol_new stac92xx_control_templates[] = { HDA_CODEC_VOLUME(NULL, 0, 0, 0), - HDA_CODEC_MUTE(NULL, 0, 0, 0), + STAC_CODEC_MUTE(NULL, 0, 0, 0), STAC_CODEC_IO_SWITCH(NULL, 0), STAC_CODEC_CLFE_SWITCH(NULL, 0), }; @@ -2059,19 +2120,6 @@ static int stac92xx_add_dyn_out_pins(str return 0; } - -static int is_in_dac_nids(struct sigmatel_spec *spec, hda_nid_t nid) -{ - int i; - - for (i = 0; i < spec->multiout.num_dacs; i++) { - if (spec->multiout.dac_nids[i] == nid) - return 1; - } - - return 0; -} - /* * Fill in the dac_nids table from the parsed pin configuration * This function only works when every pin in line_out_pins[] @@ -2806,6 +2854,7 @@ static void stac92xx_hp_detect(struct hd struct sigmatel_spec *spec = codec->spec; struct auto_pin_cfg *cfg = &spec->autocfg; int i, presence; + unsigned char pwr_state = 0; presence = 0; for (i = 0; i < cfg->hp_outs; i++) { @@ -2816,12 +2865,16 @@ static void stac92xx_hp_detect(struct hd if (presence) { /* disable lineouts, enable hp */ - for (i = 0; i < cfg->line_outs; i++) + for (i = 0; i < cfg->line_outs; i++) { stac92xx_reset_pinctl(codec, cfg->line_out_pins[i], AC_PINCTL_OUT_EN); - for (i = 0; i < cfg->speaker_outs; i++) + pwr_state |= 1 << (cfg->line_out_pins[i] - 0xa); + } + for (i = 0; i < cfg->speaker_outs; i++) { stac92xx_reset_pinctl(codec, cfg->speaker_pins[i], AC_PINCTL_OUT_EN); + pwr_state |= 1 << (cfg->speaker_pins[i] - 0xa); + } } else { /* enable lineouts, disable hp */ for (i = 0; i < cfg->line_outs; i++) @@ -2830,7 +2883,12 @@ static void stac92xx_hp_detect(struct hd for (i = 0; i < cfg->speaker_outs; i++) stac92xx_set_pinctl(codec, cfg->speaker_pins[i], AC_PINCTL_OUT_EN); - } + for (i = 0; i < cfg->hp_outs; i++) + pwr_state |= 1 << (cfg->hp_pins[i] - 0xa); + } + + /* power down unused ports */ + snd_hda_codec_write(codec, codec->afg, 0, 0x7ec, pwr_state); } static void stac92xx_unsol_event(struct hda_codec *codec, unsigned int res)

2 1

[alsa-devel] snd_pcm_status_get_tstamp()
by Lennart Poettering 07 Jan '08

07 Jan '08

Hi! The documentation for snd_pcm_status_get_tstamp() is not really enlightening. After a call to snd_pcm_status() what data does the tstamp field actually carry? Some kind of system clock timestamp when the data in the status struct was valid, or some kind of sound card clock timestamp that is relative to the point in time where the device was opened/started? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

3 4

[alsa-devel] Status of snd_pcm_rewind()
by Lennart Poettering 07 Jan '08

07 Jan '08

Hi! What's the status of snd_pcm_rewind()? Is it available on all devices? I assume not (at least dmix doesn't...). But I guess I can safely assume it is available when mmap is used? Is there any API function to test if it is available? I am working on adding "glitch-free" support to PulseAudio. I.e. have a huge playback buffer (> 2s), and schedule playback based on system timers instead of sound card interrupts, thus allowing us to dynamically adjust the inetrrupt frequency to the clients that are connected, and thus save power. I can enable this technique only if I can rewrite the playback buffer whenever I need to, thus I need to in advance if snd_pcm_rewind() will work or not. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

2 3

[alsa-devel] Hello and providing ALSA support to sdl
by M-.-n 07 Jan '08

07 Jan '08

Hi there, My name is Marc and I'm writing a tracker software originally geared towards gameconsole (first GP32 but now GP2X, PC, Mac) and since I got this lovely eee, I'm planning on porting it to debian-derived platforms. Actually it works already but the SDL version I have uses oss and it seems to hickup sometimes although the cpu power consumption seems fine. Other programs (vlc/audacity) seems no to reflect this problem so I guess it's due to the fact they use ALSA while the SDL I got doesn't. When configuring SDL, it seems not to include ALSA (by not finding alsa/soundlib.h) and I'd like to add it but I'm a little confused on the step to follow. ALSA seems to be installed but I guess I miss the includes and compiling libs. Does it mean I need to configure/compile alsa-lib ? Do I risk corrupting my system if the installed libraries are not compatible ? Sorry for the rambling, but I'm only a beginner in terms of developping audio apps under linux. Regards, Marc.

2 1

Re: [alsa-devel] snd-hda-intel support for SPDIF-in wiht vt1708 card?
by forumjunk＠comcast.net 07 Jan '08

07 Jan '08

-------------- Original message ---------------------- [...] > > I'd like to get this card's spdif working. What else can I do to help? > > Although the driver loads, the user space tools can't use the card any > > more. Thank you. > > > Should I assume at this point no more work will be done on the > snd-hda-intel driver to fixing SPDIF-in for the vt1708 sound card? > Thank you for all your work so far. > I think it is a bit early to make that assumption. There isn't a lot of demand for this particular card, but it doesn't seem that it will take too much work to get it going again... after all, it did basically work before the last patch, and I am hoping that Takashi will find some time soon to address the issues. As of this moment, I assume you're in the same boat I'm in, where the user space tools report an inappropriate ioctl for the device. -- Darryl

3 2

[alsa-devel] Conexant CX2051 on HP Spartan
by Claudio Matsuoka 07 Jan '08

07 Jan '08

Hi, I'm working with Herton Krzesinski on a HP Spartan laptop which has a Conexant CX2051 configured with internal and external microphones connected to two different ADC nodes (0x14 and 0x15 in http://helllabs.org/tmp/hp-spartan-ng.png). We were able to get input from one or other ADC, but we weren't able to switch from one capture source to another (switching between 0x17 and 0x1d would be simple, but HP chose to route the external and internal mics to two different ADCs). What is the recommended way to handle this kind of setup?

2 1