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

[alsa-devel] WM8750 mixer controls
by Harald Radke 05 Sep '08

05 Sep '08

Hi there! I noticed that using "alsamixer" several controls that are connected to sound input (ALC) are listed in the "playback" tab as well as in "capture", as well as certain playback controls as "bass" "trebel" also can be found under "capture". However, changing those controls' values only seem to take effect in the "playback" tab. I was wondering if this is intentional or unintentional done by the WM8750 codec driver or an alsamixer "feature". Thx Greez, Harry

2 1

Re: [alsa-devel] [PATCH] add the nvidia HDMI codec driver for MCP77/79
by Takashi Iwai 05 Sep '08

05 Sep '08

At Wed, 3 Sep 2008 15:58:17 +0800, peerchen wrote: > > Add the nvidia HDMI codec driver for MCP77/79. > The patch based on kernel 2.6.27-rc5. > > Signed-off-by: Wei Ni <wni(a)nvidia.com> > Signed-off-by: Peer Chen <peerchen(a)gmail.com> Thanks for the patch. Some comments below. > diff -uprN -X linux-2.6.26-Orig/Documentation/dontdiff linux-2.6.26-Orig/sound/pci/hda/hda_intel.c linux-2.6.26-New/sound/pci/hda/hda_intel.c > --- linux-2.6.26-Orig/sound/pci/hda/hda_intel.c 2008-08-28 13:47:20.000000000 +0800 > +++ linux-2.6.26-New/sound/pci/hda/hda_intel.c 2008-08-28 15:33:51.000000000 +0800 > @@ -223,8 +223,8 @@ enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO > #define RIRB_INT_MASK 0x05 > > /* STATESTS int mask: SD2,SD1,SD0 */ > -#define AZX_MAX_CODECS 3 > -#define STATESTS_INT_MASK 0x07 > +#define AZX_MAX_CODECS 4 > +#define STATESTS_INT_MASK 0x0f This may break other platforms. Expanding STATESTS_INT_MASK is OK and would be harmless, but AZX_MAX_CODECS is not. AZX_MAX_CODECS is the default number of max codecs. The chipset specific max number of codecs is defined in azx_max_codecs[]. If Nvidia chipsets supports properly more than 3, change azx_max_codecs[AZX_DRIVER_NVIDIA] to 4. > +static unsigned short convert_from_spdif_status_nv(unsigned int sbits) > +{ > + unsigned short val = 0; > + > + if (sbits & IEC958_AES0_PROFESSIONAL) > + val |= AC_DIG1_PROFESSIONAL; > + if (sbits & IEC958_AES0_NONAUDIO) > + val |= AC_DIG1_NONAUDIO; > + if (sbits & IEC958_AES0_PROFESSIONAL) { > + if ((sbits & IEC958_AES0_PRO_EMPHASIS) == > + IEC958_AES0_PRO_EMPHASIS_5015) > + val |= AC_DIG1_EMPHASIS; > + } else { > + if ((sbits & IEC958_AES0_CON_EMPHASIS) == > + IEC958_AES0_CON_EMPHASIS_5015) > + val |= AC_DIG1_EMPHASIS; > + if (!(sbits & IEC958_AES0_CON_NOT_COPYRIGHT)) > + val |= AC_DIG1_COPYRIGHT; > + if (sbits & (IEC958_AES1_CON_ORIGINAL << 8)) > + val |= AC_DIG1_LEVEL; > + val |= sbits & (IEC958_AES1_CON_CATEGORY << 8); > + } > + return val; > +} > + > +static unsigned int convert_to_spdif_status_nv(unsigned short val) > +{ > + unsigned int sbits = 0; > + > + if (val & AC_DIG1_NONAUDIO) > + sbits |= IEC958_AES0_NONAUDIO; > + if (val & AC_DIG1_PROFESSIONAL) > + sbits |= IEC958_AES0_PROFESSIONAL; > + if (sbits & IEC958_AES0_PROFESSIONAL) { > + if (sbits & AC_DIG1_EMPHASIS) > + sbits |= IEC958_AES0_PRO_EMPHASIS_5015; > + } else { > + if (val & AC_DIG1_EMPHASIS) > + sbits |= IEC958_AES0_CON_EMPHASIS_5015; > + if (!(val & AC_DIG1_COPYRIGHT)) > + sbits |= IEC958_AES0_CON_NOT_COPYRIGHT; > + if (val & AC_DIG1_LEVEL) > + sbits |= (IEC958_AES1_CON_ORIGINAL << 8); > + sbits |= val & (0x7f << 8); > + } > + return sbits; > +} > + > +static int snd_hda_hdmi_cmask_get(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + ucontrol->value.iec958.status[0] = IEC958_AES0_PROFESSIONAL | > + IEC958_AES0_NONAUDIO | > + IEC958_AES0_CON_EMPHASIS_5015 | > + IEC958_AES0_CON_NOT_COPYRIGHT; > + ucontrol->value.iec958.status[1] = IEC958_AES1_CON_CATEGORY | > + IEC958_AES1_CON_ORIGINAL; > + return 0; > +} > + > +static int snd_hda_hdmi_pmask_get(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + ucontrol->value.iec958.status[0] = IEC958_AES0_PROFESSIONAL | > + IEC958_AES0_NONAUDIO | > + IEC958_AES0_PRO_EMPHASIS_5015; > + return 0; > +} > + > +static int snd_hda_hdmi_mask_info(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_info *uinfo) > +{ > + uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958; > + uinfo->count = 1; > + return 0; > +} > + > +static int snd_hda_hdmi_default_get(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); > + > + ucontrol->value.iec958.status[0] = codec->spdif_status & 0xff; > + ucontrol->value.iec958.status[1] = (codec->spdif_status >> 8) & 0xff; > + ucontrol->value.iec958.status[2] = (codec->spdif_status >> 16) & 0xff; > + ucontrol->value.iec958.status[3] = (codec->spdif_status >> 24) & 0xff; > + > + return 0; > +} > + > +static int snd_hda_hdmi_default_put(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); > + hda_nid_t nid = kcontrol->private_value; > + unsigned short val; > + int change; > + > + mutex_lock(&codec->spdif_mutex); > + codec->spdif_status = ucontrol->value.iec958.status[0] | > + ((unsigned int)ucontrol->value.iec958.status[1] << 8) | > + ((unsigned int)ucontrol->value.iec958.status[2] << 16) | > + ((unsigned int)ucontrol->value.iec958.status[3] << 24); > + val = convert_from_spdif_status_nv(codec->spdif_status); > + val |= codec->spdif_ctls & 1; > + change = codec->spdif_ctls != val; > + codec->spdif_ctls = val; > + > + if (change) { > + snd_hda_codec_write_cache(codec, nid, 0, > + AC_VERB_SET_DIGI_CONVERT_1, > + val & 0xff); > + snd_hda_codec_write_cache(codec, nid, 0, > + AC_VERB_SET_DIGI_CONVERT_2, > + val >> 8); > + } > + > + mutex_unlock(&codec->spdif_mutex); > + return change; > +} > + > +#define snd_hda_hdmi_out_switch_info snd_ctl_boolean_mono_info > + > +static int snd_hda_hdmi_out_switch_get(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); > + > + ucontrol->value.integer.value[0] = codec->spdif_ctls & AC_DIG1_ENABLE; > + return 0; > +} > + > +static int snd_hda_hdmi_out_switch_put(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); > + hda_nid_t nid = kcontrol->private_value; > + unsigned short val; > + int change; > + > + mutex_lock(&codec->spdif_mutex); > + val = codec->spdif_ctls & ~AC_DIG1_ENABLE; > + if (ucontrol->value.integer.value[0]) > + val |= AC_DIG1_ENABLE; > + change = codec->spdif_ctls != val; > + if (change) { > + codec->spdif_ctls = val; > + snd_hda_codec_write_cache(codec, nid, 0, > + AC_VERB_SET_DIGI_CONVERT_1, > + val & 0xff); > + /* unmute amp switch (if any) */ > + if ((get_wcaps(codec, nid) & AC_WCAP_OUT_AMP) && > + (val & AC_DIG1_ENABLE)) > + snd_hda_codec_amp_stereo(codec, nid, HDA_OUTPUT, 0, > + HDA_AMP_MUTE, 0); > + } > + mutex_unlock(&codec->spdif_mutex); > + return change; > +} These are almost identical with the functions in hda_codec.c. Is your intention to allow a different set of IEC958 status bits controls for HDMI *in addition* to SPDIF? If so, we should change the codes in hda_codec.c to allow other control names. > +struct snd_kcontrol_new hdmi_mixes[] = { > + { > + .access = SNDRV_CTL_ELEM_ACCESS_READ, > + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, > + .name = "IEC958 Playback Con Mask HDMI", > + .info = snd_hda_hdmi_mask_info, > + .get = snd_hda_hdmi_cmask_get, > + }, These have also different names from the standard ones. Any reason? > +static struct hda_pcm_stream nvhdmi_pcm_digital_playback = { > + .substreams = 1, > + .channels_min = 2, > + .channels_max = 2, > + .nid = 0x4, /* NID to query formats and rates and setup streams */ > + .rates = SNDRV_PCM_RATE_48000, > + .maxbps = 16, > + .formats = SNDRV_PCM_FMTBIT_S16_LE, Use tabs please. > +static int nvhdmi_build_pcms(struct hda_codec *codec) > +{ > + struct nvhdmi_spec *spec = codec->spec; > + struct hda_pcm *info = &spec->pcm_rec; > + > + codec->num_pcms = 1; > + codec->pcm_info = info; > + > + info->name = "NVIDIA HDMI"; > + info->pcm_type = HDA_PCM_TYPE_HDMI Ditto. thanks, Takashi

3 5

Re: [alsa-devel] noise and consume pcm faster
by Nie Jun 05 Sep '08

05 Sep '08

It is strange that there is no noise in the first several seconds. It seems like a buffer overflow with too much data accumulated. However, there should not be overflow in playback, right? 2008/9/5 Nie Jun <niej0001(a)gmail.com> > I do not know how these two params will be modified by ALSA lib. It does > not directly accept specified value. > With this cmd: > ./aplay 48k_stero.wav -F5120 -B106400 > I get the nearest setting as following, but still has noise. > > channels: 2 > rate: 48000 (48000/1) > period_size: 248 > buffer_size: 5208 > > > > 2008/9/5 Takashi Iwai <tiwai(a)suse.de> > > At Fri, 5 Sep 2008 14:34:51 +0800, >> Nie Jun wrote: >> > >> > I can not figure out the reason of noise and faster consumption from >> these >> > different. Do you have any idea about these different? Or any other data >> may >> > contain clue? >> >> So, do you mean that the problem persists even if you use the exactly >> same period_size and buffer_size as OSS (i.e. 256 and 5120)? >> >> >> Takashi >> > >

1 0

[alsa-devel] Making envy24control/kenvy24 work on Envy24 HT/HT-S cards
by Vedran Miletić 05 Sep '08

05 Sep '08

Hi, any ideas if it would be possible to make envy24control or kenvy24 work on HT/HT-S cards? I'm referring to VU-meters / mixer / settings / profiles part, not the routing since those chipsets don't support it, according to VIA. -- Vedran Miletić

1 0

Re: [alsa-devel] noise and consume pcm faster
by Takashi Iwai 05 Sep '08

05 Sep '08

At Fri, 5 Sep 2008 14:34:51 +0800, Nie Jun wrote: > > I can not figure out the reason of noise and faster consumption from these > different. Do you have any idea about these different? Or any other data may > contain clue? So, do you mean that the problem persists even if you use the exactly same period_size and buffer_size as OSS (i.e. 256 and 5120)? Takashi

1 0

[alsa-devel] Playing silence instead of pausing during underrun
by Timur Tabi 05 Sep '08

05 Sep '08

If I understand it correctly, when ALSA detects an underrun during playback, it throttles the driver by sending pause and resume commands. It turns out that our hardware doesn't really like this. We're looking at various solutions, but one proposal would be to keep the hardware running during a pause, but just have it play silence instead. That is, ALSA keeps feeding silence data during an underrun recovery. Is there an easy way to do this in ALSA? Is there another driver that does this? -- Timur Tabi Linux kernel developer at Freescale

3 3

Re: [alsa-devel] noise and consume pcm faster
by Nie Jun 05 Sep '08

05 Sep '08

Thank Takashi for your advice. I check /proc/asound/card0/pcm0p/sub0/* files, buffer_sizes of both ALSA and OSS have integer period_size. Maybe other setting causes this issue, but I can not find it. Would you guys please help have a look at these file? Thank you very much! =========== ALSA hw_params =========== access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 480 buffer_size: 9600 ----------------- OSS hw_params --------------------- access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 256 buffer_size: 5120 OSS format: S16_LE OSS channels: 2 OSS rate: 48000 OSS period bytes: 1024 OSS periods: 20 OSS period frames: 256 =========== ALSA sw_params =========== tstamp_mode: NONE period_step: 1 avail_min: 480 start_threshold: 9600 stop_threshold: 9600 silence_threshold: 0 silence_size: 0 boundary: 1258291200 ----------------- OSS sw_params --------------------- tstamp_mode: NONE period_step: 1 avail_min: 1 start_threshold: 1 stop_threshold: 5120 silence_threshold: 272 silence_size: 272 boundary: 1342177280 =========== ALSA status ========== state: RUNNING trigger_time: 946744218.914947510 tstamp : 946744304.440704346 delay : 8924 avail : 676 avail_max : 1940 ----- hw_ptr : 4105180 appl_ptr : 4114104 ---------------------- OSS status -------------------------- state: RUNNING trigger_time: 946744382.661376953 tstamp : 946744410.868988037 delay : 4908 avail : 212 avail_max : 4876 ----- hw_ptr : 1353952 appl_ptr : 1358860 ============= ALSA OSS has same info ----------------------------- card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: I2S HiFi I2S HiFi-PCM-0 name: subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 0 2008/9/3 Takashi Iwai <tiwai(a)suse.de>:- 显示引用文字 -

2 1

Re: [alsa-devel] are freebob firewire cards likely to be supported by alsa in the future?
by Jonathan Woithe 05 Sep '08

05 Sep '08

Hi Andy > Just wondering if there are any plans to develop alsa support for > firewire freebob cards like the M-Audio firewire solo (which I have). I > have this working fine under jackd using the freebob driver, but as far > as I know there isn't an alsa driver for it. I assume that since there > is already open source code to drive the chip, it should be possible to > write an alsa driver? Yes, it would be possible. However, doing so would require that almost everything freebob/ffado currently does (which is a lot) would have to be ported and/or reimplemented. This doesn't seem like the best use of anyone's time. Instead, there are plans to write an alsa driver interface to libffado and some preliminary work has been done, but there's no ETA on this at present. Currently our (ffado's) focus is on getting things working well under JACK because users of firewire devices will also tend to be JACK users due to the nature of the firewire devices and the kind of work one normally does with them. > This isn't an urgent thing for me - for the moment I'm quite happy to use > my onboard card for playing music / movies etc, and keep the firewire card > for recording music etc, but it might be useful sometimes to have an alsa > driver for this card as well. Many media players are capable of connecting to JACK. xine, ecasound and mplayer are a few which come to mind off the top of my head. If your chosen applications don't do JACK, then you might have some success with oss2jack assuming your applications can use OSS devices (I haven't personally tried it so I don't know how well it works). There might even be an equivalent "alsa2jack" bridge but I haven't seen it if there is. Obviously your best bet would be to find media players which support JACK natively. Regards jonathan

1 0

[alsa-devel] alsa-lib, dmix, and snd_pcm_open_conf function
by Simon Tremblay 05 Sep '08

05 Sep '08

Hi, I have a problem using dmix on my embedded system (manual installation of alsa-lib 1.0.15) When I play a sound with aplay, it works well. When I try -D dmix or -D plug:dmix parameter, it doesn't work. The output is: aplay: main:547: audio open error: Operation not permitted I located my problem in alsa-lib, around line 2154 of alsa-lib/src/pcm/pcm.c: err = snd_pcm_open_conf(pcmp, name, root, pcm_conf, stream, mode); (in snd_pcm_open_noupdate function) err result is -1 when it's used with dmix... I don't know how works alsa-lib. I suppose snd_pcm_open_conf has something related with configuration files... Since I have all default configuration files... Maybe I must tweak some to be able to use dmix...

2 3

[alsa-devel] Using GDB for ALSA How to?
by William Estrada 05 Sep '08

05 Sep '08

Hi group, I am trying to use GDB with my ALSA program. I wish to display (print) a handle for an snd_pcm_t pointer. I am getting the following error: > (gdb) p Device > $9 = (snd_pcm_t *) 0x92be458 > (gdb) p *Device > $10 = <incomplete type> How do I display the snd_pcm_t structure? Thanks for your time. -- William Estrada MrUmunhum(a)popdial.com Mt-Umunhum-Wireless.net ( http://Mt-Umunhum-Wireless.net ) Ymessenger: MrUmunhum

2 5