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

[alsa-devel] hda-intel missing mixer channels
by Orm Finnendahl 26 Aug '13

26 Aug '13

Hi, I sent this to alsa-user a week ago but didn't get any reply. Does anybody know, what is responsible for the missing faders? Did the driver change or is it some module loading mechanism in the distro which prevents the faders from showing up in alsamixer? This is so strange. Please help! -- Orm -------------------------------------------------------------------- Hi everybody, after the last update of Ubuntu (intrepid to jaunty) on my Lenovo Ideapad my microphone input doesn't work anymore (neither internal nor external). I found out that alsamixer lacks quite a lot of faders in the newer kernel/module compared to the older one. Some of the faders now unavailable were crucial for Mic input to work on the older system so I'd very much like to get them back ;-) Some more infos: Soundcard: Intel 82801G (ICH7 Family) Chip: Realtek ALC269 Module: snd_hda_intel (in both kernels) Older kernel: Ubuntu stock 2.6.27-14-generic Newer kernel: Ubuntu stock 2.6.28-13-rt Is there any way to make the missing controls available or did the driver change and I have to compile the older driver for the new kernel? Yours, Orm

2 3

[alsa-devel] [ASoc] TDM over one SSC channel on AT91 possible?
by Friedrich Lobenstock 24 Jun '11

24 Jun '11

Hello! The background: I'm just designing an ATMEL AT91RM9200 based board which got two TLV320AIC33 on board. It is either possible to hook up the two TLV320AIC33 to a separate SSC (synchronous serial control) channel each or use one SSC channel and configure it for TDM (time division multiplex) mode. There is already a driver for TLV320AIC14k/TLV320AIC2k in the development tree, so adding support for the TLV320AIC33 should be feasible. What I'm not sure about is the fact if ASOC is prepared for using channels, especially SSC, in TDM mode. Is the core ASOC structure prepared to handle that? Would we be better off instantiate one drive twice each time with different parameters for the SSC channel? Thanks for any feedback. -- MfG / Regards Friedrich Lobenstock _________________________________________________________ SCOTTY Group Austria GmbH a SCOTTY Group plc company, http://www.scottygroup.com/ _________________________________________________________

4 3

[alsa-devel] Conexant CX20561 - Microphone problems
by Shawn Starr 19 Apr '11

19 Apr '11

Hello ALSA developers, I am having problems with the microphone on the following hardware this is on a Lenovo W500 laptop. Card: HDA Intel Chip: Conexant CX20561 (Hermosa) Here is the problems im noticing: 1) If I use ALSA 'default' with the microphone I get noise interference on output [high/low/high/low]. If I switch this to use the "ALSA Capture on HDA Intel [CONEXANT Analog] I get interference except it is the standard 60Hz electrical noise [steady noise] 2) Using the internal/external microphones gives an inconsistent volume. It also does not seem to work with the microphone cutting out so much. I need to adjust Digital + another microphone but it still drops capturing. Alsamixer shows: Digital/Docking Microphone/External Microphone/Internal Microphone Here is the module options I give to the sound driver: options snd-intel-hda enable_msi=1 power_save=10 power_save_controller=true model=laptop index=0 Assuming power saving/controller causes the microphone to cut out or not. 3) I'm now aware that this card has no pinouts for PCM capture https://bugzilla.redhat.com/show_bug.cgi?id=502293 Thanks for any help, Shawn.

2 12

[alsa-devel] idt STAC927x adat supported (sigmatel HDA codec) ?
by Eric 03 Mar '11

03 Mar '11

Is the ADAT output of the IDT (sigmatel) STAC927x HDA codec supported in alsa ? If not could someone please try to add this incredibly nice feature in the existing alsa driver ? Thank you very much

4 13

[alsa-devel] davinci-i2c,pcm updates
by Troy Kisky 27 Sep '10

27 Sep '10

This patch set is against git://git.alsa-project.org/alsa-kernel.git but the last patch in series won't compile until the sram allocator patch is available.

8 44

Re: [alsa-devel] Patchmix-style application for EMU cards
by Camilo Polymeris 30 Aug '10

30 Aug '10

Hello > That is more or less what I had figured out, but it how are playback_1 to > > _16 channels routed to DSP0-15? It seems that it depends on the setting > of > > Front, Surround, LFE, etc. mixer controls. If they are turned up, I > don't > > understand what happens, sound to playback channels appears on various > DSP > > buses, at different levels. > > Really? Well, I didn't much experiment with surround mode. In source code, > I > can see that there are up to playback 8 channels at hw:0,0 with can be > controlled by faders in alsamixer. I tried surround40 and surroun51 on my > emu1616m and it worked as expected. The channles were mapped to first > couple > of DSP ports in a correct order. In fact this should work the same as > audigy > does, except the result is passed to DSP ports instead of physical > outputs. > On my card, playback channels 1 & 2 (hw:0,3) appear on all DSP busses associated with surround. Say you turn up the "Side" fader in alsamixer, channels 1 & 2 will appear at the relevant DSPs (6-7, I think) Whatever, for now I am just keeping all surround controls down (that is, Front, Surround, Center, Side & LFE). > Anyway, I think if there is another layer of routing done in audigy DSP, > it > shouldn't be used in EMU specific application. Or at least not for now. > The > most important thing is to provide all the switches and FPGA routing > scheme > for each EMU model. Or, to be precise, three routing schemes for each EMU > model, because for "double speed" (e.g. 96kHz) and "quadro speed" (e.g. > 192kHz) modes of operation the numebr of both physical and virtual > channels > changes. > I think the switches and enums for the card models are rather trivial, one can handle it with a customized version of qamix (done with a simple XML file), for example. A separate application would not be necessary for only that. > > If I turn the Front/Surround/LFE/etc. faders down, I can mix playback > > channels to DSP using the "Multichannel PCM Send/Routing/Volume" faders, > in > > a more or less intuitive way, besides that routing values do not map > > directly to DSP buses (i.e. 14-15 map to DSP0-1, but 2-3 map to DSP2-3). > Handling of this controls motivated me to write the application in the first place. No sound at all will appear if I don't set the appropiate controls for each playback channel: Multichannel PCM Volume (full), Multichannel PCM Send (an index of 8 controls, the first 4 select the target DSP) & Multichannel PCM Send Volume (again faders 0-3 of 8) By the way, only DSP0-7 work in this way. I have no idea how to make DSP8-31 work. On which card you did tested it? The driver was primary written for the > 1820M/1212M V1, so some things may not work well on other models and need > to > be fixed. I have a 1212m, don't know which version, but I think it's V1-- it does have firewire. I am using driver version 1.0.16. Thanks, Camilo.

3 3

[alsa-devel] [PATCH 1/4] ASoC: DaVinci: remove requirement that dma_params is 1st in structure
by Troy Kisky 13 Jul '10

13 Jul '10

Remove requirement that dma_params is 1st in the structures davinci_audio_dev and davinci_mcbsp_dev. Signed-off-by: Troy Kisky <troy.kisky(a)boundarydevices.com> --- sound/soc/davinci/davinci-i2s.c | 6 +----- sound/soc/davinci/davinci-mcasp.c | 1 + sound/soc/davinci/davinci-mcasp.h | 5 ----- sound/soc/davinci/davinci-pcm.c | 7 ++++--- 4 files changed, 6 insertions(+), 13 deletions(-) diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c index 4ae7070..9e69a4e 100644 --- a/sound/soc/davinci/davinci-i2s.c +++ b/sound/soc/davinci/davinci-i2s.c @@ -98,11 +98,6 @@ enum { }; struct davinci_mcbsp_dev { - /* - * dma_params must be first because rtd->dai->cpu_dai->private_data - * is cast to a pointer of an array of struct davinci_pcm_dma_params in - * davinci_pcm_open. - */ struct davinci_pcm_dma_params dma_params[2]; void __iomem *base; #define MOD_DSP_A 0 @@ -547,6 +542,7 @@ static int davinci_i2s_probe(struct platform_device *pdev) dev->dma_params[SNDRV_PCM_STREAM_CAPTURE].channel = res->start; davinci_i2s_dai.private_data = dev; + davinci_i2s_dai.dma_data = dev->dma_params; ret = snd_soc_register_dai(&davinci_i2s_dai); if (ret != 0) goto err_free_mem; diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 5d1f98a..5023915 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -907,6 +907,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev) dma_data->channel = res->start; davinci_mcasp_dai[pdata->op_mode].private_data = dev; + davinci_mcasp_dai[pdata->op_mode].dma_data = dev->dma_params; davinci_mcasp_dai[pdata->op_mode].dev = &pdev->dev; ret = snd_soc_register_dai(&davinci_mcasp_dai[pdata->op_mode]); diff --git a/sound/soc/davinci/davinci-mcasp.h b/sound/soc/davinci/davinci-mcasp.h index 9d179cc..582c924 100644 --- a/sound/soc/davinci/davinci-mcasp.h +++ b/sound/soc/davinci/davinci-mcasp.h @@ -39,11 +39,6 @@ enum { }; struct davinci_audio_dev { - /* - * dma_params must be first because rtd->dai->cpu_dai->private_data - * is cast to a pointer of an array of struct davinci_pcm_dma_params in - * davinci_pcm_open. - */ struct davinci_pcm_dma_params dma_params[2]; void __iomem *base; int sample_rate; diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index c73a915..c2c2e85 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -238,10 +238,11 @@ static int davinci_pcm_open(struct snd_pcm_substream *substream) struct davinci_runtime_data *prtd; int ret = 0; struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct davinci_pcm_dma_params *pa = rtd->dai->cpu_dai->private_data; - struct davinci_pcm_dma_params *params = &pa[substream->stream]; - if (!params) + struct davinci_pcm_dma_params *pa = rtd->dai->cpu_dai->dma_data; + struct davinci_pcm_dma_params *params; + if (!pa) return -ENODEV; + params = &pa[substream->stream]; snd_soc_set_runtime_hwparams(substream, &davinci_pcm_hardware); /* ensure that buffer size is a multiple of period size */ -- 1.5.6.3

3 5

[alsa-devel] snd-hda-intel: no data when recording from mic, "IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj" logged in kern.log
by Aleksander Adamowski 17 Mar '10

17 Mar '10

Hi! I think I have some interesting problems to analyse for Takashi. Maybe my sound card model is a non typical one, but I have a continuous stream of capture-related problems with it. It's an integrated sound card on my Gigabyte GA-MA74GM-S2H Rev. 1.1 motherboard. "grep ^Codec /proc/asound/card0/codec#0" shows: Codec: Realtek ALC888 I'm attaching the full contents of /proc/asound/card0/codec#0 for identification. But first, some background. With this particular card, I've been continuously hit by the "azx_get_response timeout, switching to single_cmd mode" problem, described here: http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html#_cod… However, in my case setting probe_mask=1 (experimentally determined) didn't make the problem go away, although it seemed to reduce its frequency (might be just a coincidence). Whenever the dreaded "azx_get_response timeout, switching to single_cmd mode" message appeared in the kernel log, recording stopped working. The card got into the bad state where it would not record sound, and arecord would be giving a stream of "overrun" error messages: arecord -f cd output.wav Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo overrun!!! (at least 27.876 ms long) overrun!!! (at least 26.965 ms long) overrun!!! (at least 16.169 ms long) overrun!!! (at least 11.749 ms long) overrun!!! (at least 11.298 ms long) overrun!!! (at least 11.814 ms long) overrun!!! (at least 11.190 ms long) overrun!!! (at least 11.190 ms long) overrun!!! (at least 11.747 ms long) overrun!!! (at least 11.819 ms long) overrun!!! (at least 11.149 ms long) overrun!!! (at least 11.257 ms long) overrun!!! (at least 11.315 ms long) overrun!!! (at least 11.651 ms long) overrun!!! (at least 11.745 ms long) overrun!!! (at least 11.235 ms long) overrun!!! (at least 11.169 ms long) overrun!!! (at least 11.776 ms long) overrun!!! (at least 11.391 ms long) overrun!!! (at least 11.669 ms long) overrun!!! (at least 11.714 ms long) overrun!!! (at least 11.671 ms long) overrun!!! (at least 11.190 ms long) What's notable, sound playback would continue to work OK. After being fed up with interrupted Skype conversations (where I weren't immediately aware that the other side stopped hearing me, since I was hearing them), I've decided to upgrade do kernel 2.6.29 (citing the http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html#_cod… document: "Since 2.6.29 kernel, the driver has a more robust probing method, so this error might happen rarely, though"). After upgrading to 2.6.29 I've removed any extra snd-hda-intel options from modprobe config files. Now the azx_get_response timeout seems to be gone, but I'm experiencing another problem: after some powered up time, recording starts giving empty streams - there's no error, but audio data has zero lengh. e.g. when I arecord, I get a .wav file that is only 44 bytes long (which seems to be the length of the WAV header). When I make a Skype test call to echo123, and it starts playing back my message, it's zero length too - the playback end signal can be heard immediately after the playback start signal. This problem seems to concide with the following error message in the kernel log: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. Do you have any idea what could be the cause and how to debug this issue further? -- Best Regards, Aleksander Adamowski http://olo.org.pl

2 10

Re: [alsa-devel] [alsa-cvslog] alsa-kernel: Official ALSA project GIT repository for Linux 2.6 branch, master now at v2.6.31-rc8-407-gfc9e4a3
by Takashi Iwai 26 Feb '10

26 Feb '10

At Tue, 6 Oct 2009 08:36:04 +0200 (CEST), noreply-git(a)alsa-project.org wrote: > commit fc9e4a3811567f8d1d4c263a89e27b52c90d6098 > Author: Clemens Ladisch <clemens(a)ladisch.de> > AuthorDate: Tue Oct 6 08:21:04 2009 +0200 > Commit: Clemens Ladisch <clemens(a)ladisch.de> > CommitDate: Tue Oct 6 08:21:04 2009 +0200 > > sound: via82xx: move DXS volume controls to PCM interface > > The "VIA DXS" controls are actually volume controls that apply to the > four PCM substreams, so we better indicate this connection by moving the > controls to the PCM interface. > > Commit b452e08e73c0e3dbb0be82130217be4b7084299e in 2.6.30 broke the > restoring of these volumes by "amixer restore" that most distributions > use; the renaming in this patch cures that regression by preventing > amixer from applying the old, wrong volume levels to the new controls. > http://bugzilla.kernel.org/show_bug.cgi?id=14151 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532613 > > Signed-off-by: Clemens Ladisch <clemens(a)ladisch.de> > Cc: <stable(a)kernel.org> Well, this control was once removed, and then revived due to complains by users who have used it in mixer. Moving this to PCM iface does almost the same thing, disabling an easy way to access it. I'm afraid that this patch might be regarded as another "regression". For such an old driver, the compatibility is the most important item. If any, we must provide a way to back to the old behavior. thanks, Takashi > > ----------------------------------------------------------------------- > > Diffstat: > sound/pci/via82xx.c | 27 ++++++++++++++++++--------- > 1 files changed, 18 insertions(+), 9 deletions(-) > > > Patch -------------- (max 1500 lines) > diff --git a/sound/pci/via82xx.c b/sound/pci/via82xx.c > index acfa476..91683a3 100644 > --- a/sound/pci/via82xx.c > +++ b/sound/pci/via82xx.c > @@ -1626,7 +1626,7 @@ static int snd_via8233_dxs_volume_get(struct snd_kcontrol *kcontrol, > struct snd_ctl_elem_value *ucontrol) > { > struct via82xx *chip = snd_kcontrol_chip(kcontrol); > - unsigned int idx = snd_ctl_get_ioff(kcontrol, &ucontrol->id); > + unsigned int idx = kcontrol->id.subdevice; > > ucontrol->value.integer.value[0] = VIA_DXS_MAX_VOLUME - chip->playback_volume[idx][0]; > ucontrol->value.integer.value[1] = VIA_DXS_MAX_VOLUME - chip->playback_volume[idx][1]; > @@ -1646,7 +1646,7 @@ static int snd_via8233_dxs_volume_put(struct snd_kcontrol *kcontrol, > struct snd_ctl_elem_value *ucontrol) > { > struct via82xx *chip = snd_kcontrol_chip(kcontrol); > - unsigned int idx = snd_ctl_get_ioff(kcontrol, &ucontrol->id); > + unsigned int idx = kcontrol->id.subdevice; > unsigned long port = chip->port + 0x10 * idx; > unsigned char val; > int i, change = 0; > @@ -1705,11 +1705,12 @@ static struct snd_kcontrol_new snd_via8233_pcmdxs_volume_control __devinitdata = > }; > > static struct snd_kcontrol_new snd_via8233_dxs_volume_control __devinitdata = { > - .name = "VIA DXS Playback Volume", > - .iface = SNDRV_CTL_ELEM_IFACE_MIXER, > + .iface = SNDRV_CTL_ELEM_IFACE_PCM, > + .device = 0, > + /* .subdevice set later */ > + .name = "PCM Playback Volume", > .access = (SNDRV_CTL_ELEM_ACCESS_READWRITE | > SNDRV_CTL_ELEM_ACCESS_TLV_READ), > - .count = 4, > .info = snd_via8233_dxs_volume_info, > .get = snd_via8233_dxs_volume_get, > .put = snd_via8233_dxs_volume_put, > @@ -1936,10 +1937,18 @@ static int __devinit snd_via8233_init_misc(struct via82xx *chip) > } > else /* Using DXS when PCM emulation is enabled is really weird */ > { > - /* Standalone DXS controls */ > - err = snd_ctl_add(chip->card, snd_ctl_new1(&snd_via8233_dxs_volume_control, chip)); > - if (err < 0) > - return err; > + for (i = 0; i < 4; ++i) { > + struct snd_kcontrol *kctl; > + > + kctl = snd_ctl_new1( > + &snd_via8233_dxs_volume_control, chip); > + if (!kctl) > + return -ENOMEM; > + kctl->id.subdevice = i; > + err = snd_ctl_add(chip->card, kctl); > + if (err < 0) > + return err; > + } > } > } > /* select spdif data slot 10/11 */ > ------- End of patch > > hooks/update > --- > Git Source Code Management System > hooks/update refs/heads/master \ > 62f08ef9739c5cb5fff5b5bdec3bc02d522b9a12 \ > fc9e4a3811567f8d1d4c263a89e27b52c90d6098 > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Alsa-cvslog mailing list > Alsa-cvslog(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/alsa-cvslog >

6 22

[alsa-devel] Sound distortion with Realtek ALC889A
by Damien Brossard 11 Feb '10

11 Feb '10

Hi. I recently bought a Gigabyte GA-MA78GM-S2H motherboard. This board uses the (in)famous (from what i've read for now) alc889a chip. While playing 5.1 content, I can hear noise or distortion coming from the center channel. I can not test my configuration with another OS, so I can't fully dismiss a HW problem. However, i made several tests with 5.1 and 2.0 speakers which points me to soundcard problem. I've made some tests with speaker-test (speaker-test -D surround51 -c 6) : 1) Each time a sound is played either on front left channel or rear left channel, a noise can be heared on the center channel (and subwoofer, this is confirmed pluging a stereo headphone on the center/lfe jack). No noise when a sound is played on right channels (front or rear). 2) In alsamixer, if I set the volume to 0 for the front or rear left channels, i can hear the noise on center/lfe when a sound is "played" on this channels 3) In alsamixer, if I mute the front or rear left channels, i can hear no more noise on center/lfe Complementary tests have been made with alsaplayer and using a simple mp3 file. In this configuration (stereo output), center and rear channels play the same sound as front channel. 1) If all channels are unmuted, I hear no noise. 2) If either the front channel or the rear channel are muted, I can hear the noise on center channel. I tried this with alsa-driver 1.0.20 and 1.0.21 with the same result, I recently went back to 1.0.20 due to kernel upgrade. Things that seem strange to me (maybe not so strange to alsa dev :)) : 1) alsamixer shows volumes in percentage, however when I set a channel volume to 50% and the master volume to 50%, I hope to find a resulting volume of 25%, not 0. 2) lspci reports my soundcard subsystem id as 1458:a022, but in /proc/asound/card0/codec#0 the subsystem id is 1458:a002 Googling around made me find few references (in alsa-devel list) to a similar problem : http://mailman.alsa-project.org/pipermail/alsa-devel/2008-July/008942.html http://mailman.alsa-project.org/pipermail/alsa-devel/2008-August/009754.html The distortion / noise described here is exactly what i can hear with my system. Apparently the user solved the issue buying another soundcard. I'd like to be sure it is the only way to go. Attached is the file produced by alsa-info.sh Thanks in advance. Best regards Damien Brossard

2 3