December 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] CA0110 taints kernel
by Vedran Miletić 13 Apr '11

13 Apr '11

Hi, I experience frequent kernel crashes with 2.6.31 and CA0110. I know this card doesn't work, and there is no problem with that; however, it crashing non-stop is not very nice. Also, card doesn't get any controls (and I believe it does get some controls when it's the only card using HDA driver, that is when I disable onboard one). dmesg is here: http://pastebin.com/m7c53562f lspci: 02:00.0 PCI bridge: Creative Labs Device 7006 (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=02, secondary=03, subordinate=03, sec-latency=64 Memory behind bridge: fe900000-fe9fffff Capabilities: [50] Power Management version 3 Capabilities: [60] MSI: Enable- Count=1/16 Maskable- 64bit+ Capabilities: [80] Subsystem: Creative Labs Device 0010 Capabilities: [90] Express PCI/PCI-X Bridge, MSI 00 Capabilities: [100] Advanced Error Reporting Kernel modules: shpchp 03:00.0 Audio device: Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG Subsystem: Creative Labs Device 0018 Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at fe9fc000 (32-bit, non-prefetchable) [size=16K] Capabilities: [dc] Power Management version 3 Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel Any ideas? -- Vedran Miletić P.S. Please CC me, as I'm not subscribed to mailing list at the moment.

2 2

[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

[alsa-devel] 2.6.30-rc8 skipping regression also affects cmipci
by Frédéric Brière 07 Mar '10

07 Mar '10

Hi everybody, I was only recently able to upgrade from 2.6.26 to 2.6.32 (long story). In so doing, I noticed infrequent occurrences of audio skipping, which I managed to bisect down to c87d973. It would appear that this commit also affects cmipci (CMI8738), albeit not as badly as it did for intel8x0. (I guess I'm the only person left on Earth still using a stand-alone PCI sound card, which is why this was never reported. <g>) Here's a sample log output after turning xrun debugging on: [ 171.555860] PCM: hw_ptr skipping! (pos=6341, delta=16383, period=1024, jdelta=0/85) [ 181.114680] PCM: hw_ptr skipping! (pos=12529, delta=16370, period=1024, jdelta=0/85) [ 181.114770] PCM: hw_ptr skipping! (pos=12534, delta=16375, period=1024, jdelta=0/85) [ 1713.774316] PCM: hw_ptr skipping! (pos=9456, delta=16369, period=1024, jdelta=0/85) [ 1713.774346] PCM: hw_ptr skipping! (pos=9458, delta=16371, period=1024, jdelta=0/85) [ 1713.774409] PCM: hw_ptr skipping! (pos=9461, delta=16374, period=1024, jdelta=0/85) [ 1713.774613] PCM: hw_ptr skipping! (pos=9470, delta=16383, period=1024, jdelta=0/85) [ 1831.092000] PCM: hw_ptr skipping! (pos=1712, delta=16373, period=1024, jdelta=0/85) [ 1953.347453] PCM: hw_ptr skipping! (pos=3723, delta=16316, period=1024, jdelta=0/84) [ 1953.347465] PCM: hw_ptr skipping! (pos=3724, delta=16317, period=1024, jdelta=0/84) [ 1953.347485] PCM: hw_ptr skipping! (pos=3725, delta=16318, period=1024, jdelta=0/84) You'll notice that this occurs much less frequently than it did for intel8x0. However, I left MPlayer on pause for the night, and at some point the kernel started spewing several syslog messages every couple of seconds: [25332.211286] PCM: hw_ptr skipping! [Q] (pos=4, delta=-1073740800, period=1024, jdelta=5/44744/0) [25332.232637] PCM: hw_ptr skipping! [Q] (pos=1029, delta=-1073739771, period=1024, jdelta=6/44749/0) [25332.253957] PCM: hw_ptr skipping! [Q] (pos=2053, delta=-1073738747, period=1024, jdelta=5/44755/0) [25332.275292] PCM: hw_ptr skipping! [Q] (pos=3077, delta=-1073737723, period=1024, jdelta=5/44760/0) [25332.296616] PCM: hw_ptr skipping! [Q] (pos=4101, delta=-1073736699, period=1024, jdelta=6/44765/0) [25332.317932] PCM: hw_ptr skipping! [Q] (pos=5125, delta=-1073735675, period=1024, jdelta=5/44771/0) [25332.339269] PCM: hw_ptr skipping! [Q] (pos=6149, delta=-1073734651, period=1024, jdelta=5/44776/0) [25332.360600] PCM: hw_ptr skipping! [Q] (pos=7173, delta=-1073733627, period=1024, jdelta=6/44781/0) [25332.381942] PCM: hw_ptr skipping! [Q] (pos=8197, delta=-1073732603, period=1024, jdelta=5/44787/0) [25332.403261] PCM: hw_ptr skipping! [Q] (pos=9221, delta=-1073731579, period=1024, jdelta=5/44792/0) [25337.244901] PCM: hw_ptr skipping! [Q] (pos=12293, delta=-1073728507, period=1024, jdelta=6/44808/0) [25337.266223] PCM: hw_ptr skipping! [Q] (pos=13317, delta=-1073727483, period=1024, jdelta=5/44813/0) This kept going on until I quit MPlayer (which, as I said, was not actually playing anything all this time). Not that skipped silence is much of an issue, but I thought this might add useful information. Let me know if I can be of any help in resolving this. -- If you want to travel around the world and be invited to speak at a lot of different places, just write a Unix operating system. -- Linus Torvalds

2 3