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

[alsa-devel] Kernel 2.6.21 M-Audio Delta 1010L
by Suso Comesaña 20 Jun '07

20 Jun '07

Hello... My name is Suso Comesaña...I have 2 computers with a M-Audio card Delta 1010L...the problem is the following one: With kernel 2.6.17-2-multimedia-486... I can record sounds perfectly... but, kernel 2.6.21... I cannot record nothing... You have some idea?... You need that she sends some information to you? Tanks... Suso Comesaña. Peatón. susobaco(a)yahoo.es Usuario de Musix, GNU-Linux, basada en Debian/Knoppix. 100% Software Libre. ¡Descubre una nueva forma de obtener respuestas a tus preguntas! Entra en Yahoo! Respuestas. LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com ____________________________________________________________________________________ ¡Descubre una nueva forma de obtener respuestas a tus preguntas! Entra en Yahoo! Respuestas. http://es.answers.yahoo.com/info/welcome

1 0

[alsa-devel] [PATCH] Output MFG information for HDA devices
by Jonathan Phénix 19 Jun '07

19 Jun '07

Hi, this patch output information about the MFG (Modem Function Group) to the /proc/asound/card?/codec#? file. This information is important to identify if a HDA device has a modem or not. Regards, Jonathan Phénix Technical specialist / Linuxant www.linuxant.com jonathan(a)linuxant.com

2 3

Re: [alsa-devel] Writing an AT91SAM9260-EK Dumb Codec Driver
by Paul Kavan 19 Jun '07

19 Jun '07

On 6/19/07, Liam Girdwood <lg(a)opensource.wolfsonmicro.com> wrote: > > On Mon, 2007-06-18 at 14:30 -0500, Paul Kavan wrote: > > > > > Am I at a point now where I can try to get alsa-lib and alsa-util in > > place? If so, what version? I found some tars at: > > > > http://www.alsa-project.org/alsa/ftp/lib/ > > > > Is that the best place to get them? I am using buildroot, but not sure > > if ALSA stuff is ready for primetime there. I guess I should check on > > this asap. > > > > Afaik, there is an issue with buildroot atm (please someone correct me > if it's now fixed) when it comes to building alsa-lib for ARM. (please > search archives for details). No, I think you are right. I have tried a few recommended patches, but they do not work. Fwiw, I use openembedded for all my embedded builds without any problems > atm. http://www.openembedded.org At some point when I have some time, I am going to give it a try. I have managed to build the libs and have those in my rfs using: CC=arm-linux-gcc ./configure --host=arm-linux --prefix=$HOME/buildroot/build_arm/root/usr --with-versioned=no ...and then... make install With this, I get the /usr/ entries in my rfs. However, I have had troubles building alsa-utils. When I try: CC=arm-linux-gcc ./configure --host=arm-linux --prefix=$HOME/buildroot/build_arm/root/usr --with-versioned=no I get: grhuser@pcL7:$ CC=arm-linux-gcc ./configure --host=arm-linux --prefix=$HOME/buildroot/build_arm/root/usr --with-versioned=no configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for arm-linux-strip... arm-linux-strip checking whether NLS is requested... yes checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for style of include used by make... GNU checking for arm-linux-gcc... arm-linux-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... yes checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether arm-linux-gcc accepts -g... yes checking for arm-linux-gcc option to accept ISO C89... none needed checking dependency style of arm-linux-gcc... gcc3 checking build system type... i686-pc-linux-gnu checking host system type... arm-unknown-linux-gnu checking for ld used by GCC... /home/grhuser/buildroot/build_arm/staging_dir/arm-linux-uclibc/bin/ld checking if the linker (/home/grhuser/buildroot/build_arm/staging_dir/arm-linux-uclibc/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking for CFPreferencesCopyAppValue... no checking for CFLocaleCopyCurrent... no checking for GNU gettext in libc... no checking for iconv... no, consider installing GNU libiconv checking for GNU gettext in libintl... no checking whether to use NLS... no checking for arm-linux-gcc... (cached) arm-linux-gcc checking whether we are using the GNU C compiler... (cached) yes checking whether arm-linux-gcc accepts -g... (cached) yes checking for arm-linux-gcc option to accept ISO C89... (cached) none needed checking dependency style of arm-linux-gcc... (cached) gcc3 checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for ALSA CFLAGS... checking for ALSA LDFLAGS... -lasound -lm -ldl -lpthread checking for libasound headers version >= 1.0.12... not present. configure: error: Sufficiently new version of libasound not found. Not sure what is the problem here. I have file:///home/grhuser/buildroot/build_arm/root/usr/lib/libasound.so.2.0.0 in my rfs. Any suggestions? Paul Liam > > -- *************************************** Paul David Kavan Project Engineer GRH Electronics, Inc. 402-734-4900 pkavan(a)gmail.com ***************************************

2 1

[alsa-devel] [PATCH] hda: add eapd support to additional idt codecs
by Matthew Ranostay 19 Jun '07

19 Jun '07

Added support for EAPD on the 927x, and 9227-8 IDT HDA codecs. Enabling EAPD powers the internal speaker amp otherwise there is no sound on systems with an internal amp. --- Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> diff -r 96495fe7cc13 pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Thu Jun 14 12:58:23 2007 +0200 +++ b/pci/hda/patch_sigmatel.c Mon Jun 18 17:10:38 2007 -0400 @@ -832,6 +832,18 @@ static void stac92xx_set_config_regs(str } } +static void stac92xx_enable_eapd(struct hda_codec *codec) +{ + /* Configure GPIO0 as output */ + snd_hda_codec_write(codec, codec->afg, 0, AC_VERB_SET_GPIO_DIRECTION, 0x00000001); + /* Configure GPIO0 as CMOS */ + snd_hda_codec_write(codec, codec->afg, 0, 0x7e7, 0x00000000); + /* Assert GPIO0 high */ + snd_hda_codec_write(codec, codec->afg, 0, AC_VERB_SET_GPIO_DATA, 0x00000001); + /* Enable GPIO0 */ + snd_hda_codec_write(codec, codec->afg, 0, AC_VERB_SET_GPIO_MASK, 0x00000001); +} + /* * Analog playback callbacks */ @@ -2193,7 +2205,8 @@ static int patch_stac927x(struct hda_cod } spec->multiout.dac_nids = spec->dac_nids; - + stac92xx_enable_eapd(codec); + err = stac92xx_parse_auto_config(codec, 0x1e, 0x20); if (!err) { if (spec->board_config < 0) { @@ -2254,18 +2267,7 @@ static int patch_stac9205(struct hda_cod spec->mixer = stac9205_mixer; spec->multiout.dac_nids = spec->dac_nids; - - /* Configure GPIO0 as EAPD output */ - snd_hda_codec_write(codec, codec->afg, 0, - AC_VERB_SET_GPIO_DIRECTION, 0x00000001); - /* Configure GPIO0 as CMOS */ - snd_hda_codec_write(codec, codec->afg, 0, 0x7e7, 0x00000000); - /* Assert GPIO0 high */ - snd_hda_codec_write(codec, codec->afg, 0, - AC_VERB_SET_GPIO_DATA, 0x00000001); - /* Enable GPIO0 */ - snd_hda_codec_write(codec, codec->afg, 0, - AC_VERB_SET_GPIO_MASK, 0x00000001); + stac92xx_enable_eapd(codec); err = stac92xx_parse_auto_config(codec, 0x1f, 0x20); if (!err) {

2 1

[alsa-devel] Is snd_magic_kcalloc() deprecated?
by Pharaoh . 19 Jun '07

19 Jun '07

2 1

[alsa-devel] Fwd: Problems with hda_intel, Santa Rosa, and suspend
by Matt Mullins 19 Jun '07

19 Jun '07

I posted this to the LKML, I thought it should be reproduced on this list. > > On Sunday, 17 June 2007 03:36, Matt Mullins wrote: > > > I just received a Dell Latitude D630, with the new Intel Santa Rosa > > > platform. Currently, the only major driver issue I have is sound. It > > > worked fine in Ubuntu Feisty's 2.6.20 kernel, but now I am using Gutsy > > > so I can have graphics drivers. Gutsy's 2.6.22-rc3-based kernel no > > > longer recognized my soundcard, a Sigmatel STAC9205, which uses the > > > hda_intel driver. I have since fixed that problem by compiling the > > > hda_intel driver into the kernel (I used 2.6.22-rc4 vanilla sources), > > > instead of a module, but it is still a bug that it does not work as a > > > module. > > > > > > All the following debug information was obtained from kernel 2.6.22-rc4. > > > > > > However, the bug that is currently affecting me is that sound no > > > longer works after using ACPI suspend-to-RAM or swsusp. I compiled > > > ALSA debugging in, and as soon as I resume, I get tons of messages > > > like: > > > [ 8.474830] hda-intel: send_cmd timeout: IRS=0x1, val=0xd0970500 > > > [ 8.474954] hda-intel: send_cmd timeout: IRS=0x1, val=0xd0af0009 > > > [ 8.475078] hda-intel: send_cmd timeout: IRS=0x1, val=0xd0a70500 > > > [ 8.475207] hda-intel: send_cmd timeout: IRS=0x1, val=0xd0bf0009 > > > (etc) > > > > > > There may be more before that, but that is more than the kernel > > > message buffer can hold, so I can't ever see it. I get similar > > > timeout messages each time a PCM gets set up: > > > [ 8.972859] hda_codec_setup_stream: NID=0x10, stream=0x5, channel=0, format=0 > > > x11 > > > [ 8.972987] hda-intel: send_cmd timeout: IRS=0x1, val=0x1070650 > > > [ 9.006071] hda-intel: send_cmd timeout: IRS=0x1, val=0x1020011 > > > [ 9.006081] hda_codec_setup_stream: NID=0x11, stream=0x5, channel=0, format=0 > > > x11 > > > [ 9.006207] hda-intel: send_cmd timeout: IRS=0x1, val=0x1170650 > > > [ 9.016117] hda-intel: send_cmd timeout: IRS=0x1, val=0x1120011 > > > > > > I read some of sound/pci/hda/hda_intel.c, specifically the code that > > > output those messages. After octupling my kernel log buffer (to 1MB), > > > I noticed that for the first set of timeouts (immediately upon > > > resume), all the "codec" nibbles are odd, the last word of the val > > > ("verb" and "para") are all either 0x0500 or 0x0009. For the second > > > set (when something tries to use the card) that last word is 0x0650 or > > > 0x0011. > > > > > > I have yet to go back and re-test compiling snd-hda-intel as a module. On 6/17/07, Matt Mullins <mokomull(a)gmail.com> wrote: > I've been reading up on the Intel HD Audio specifications, and I found > that the problem is most likely that the driver has to resort to PI/O > (single_cmd) mode. I really haven't had enough time or experience to > figure out what is actually causing this. This is the first time I've > done any kernel development; thankfully, Intel has good documentation. > I'm going to keep hacking to see what information I can figure out. > > I just tried 2.6.22-rc5, and no behavior has changed.

3 3

[alsa-devel] Bad digital out of ASUS M2V
by Mike Crash 19 Jun '07

19 Jun '07

In ALSA 1.0.14 HDA Intel with ASUS M2V motherboard - detected the chip ALC660VD, but digital out is missing. I added workaround - added new model name 3stack-660-digout with digital output, diff file follows: ---------------------------------------------- 117a118 > ALC660VD_3ST_DIG, 9466a9468 > [ALC660VD_3ST_DIG]= "3stack-660-digout", 9478c9480 < SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS", ALC660VD_3ST), --- > SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS", ALC660VD_3ST_DIG), 9501a9504,9516 > [ALC660VD_3ST_DIG] = { > .mixers = { alc861vd_3st_mixer }, > .init_verbs = { alc861vd_volume_init_verbs, > alc861vd_3stack_init_verbs }, > .num_dacs = ARRAY_SIZE(alc660vd_dac_nids), > .dac_nids = alc660vd_dac_nids, > .dig_out_nid = ALC861VD_DIGOUT_NID, > .num_adc_nids = ARRAY_SIZE(alc861vd_adc_nids), > .adc_nids = alc861vd_adc_nids, > .num_channel_mode = ARRAY_SIZE(alc861vd_3stack_2ch_modes), > .channel_mode = alc861vd_3stack_2ch_modes, > .input_mux = &alc861vd_capture_source, > },

2 1

[alsa-devel] question about bluez using alsa and patches
by Walt Shekrota 19 Jun '07

19 Jun '07

I was told that when using the btsco(bluez) and/or plugs bluetooth headset software a patch is always required. In the Gentoo community and perhaps everywhere it is suggested to use alsa compiled into your kernel. As I go to new kernels frequently these folks (sco headset) seem to have no such forward support ie they have not worked on the patches yet for the newer kernels. Am I wrong or at some point in time should this app not be weaned from using patches? Is it the fact they use sco that they have to patch? Is there not an alsa library they can program to instead. I guess I don't understand the overall design so I can't see why this goes on forever. I'm somewhat apprehensive about trusting others to continually modify my kernel. Am I out in left field here? Can anyone explain why they must choose this path? Thanks very much. -Walt

3 3

[alsa-devel] Difference between substream->dma_buffer and substream->runtime->dma_buffer_p?
by Timur Tabi 19 Jun '07

19 Jun '07

The snd_pcm_substream structure has a snd_dma_buffer structure. snd_dma_buffer looks like this: struct snd_dma_buffer { struct snd_dma_device dev; /* device type */ unsigned char *area; /* virtual pointer */ dma_addr_t addr; /* physical address */ size_t bytes; /* buffer size in bytes */ void *private_data; /* private for allocator; don't touch */ }; snd_pcm_substream also has a snd_pcm_runtime structure, which looks like this: struct snd_pcm_runtime { ... /* -- DMA -- */ unsigned char *dma_area; /* DMA area */ dma_addr_t dma_addr; /* physical bus address (not accessible from main CPU) */ size_t dma_bytes; /* size of DMA area */ struct snd_dma_buffer *dma_buffer_p; /* allocated buffer */ Why the redundancy? Not only does snd_pcm_runtime have dma_area, dma_addr, and dma_bytes, but it also has a pointer to a dns_dma_buffer structure, which also has this information! So given a snd_pcm_substream structure, you can obtain the physical address of the DMA buffer three ways: substream->dma_buffer.addr substream->runtime->dma_addr substream->runtime->dma_buffer_p->addr When will these three variable contain different values? If the answer is never, then why do they all exist? -- Timur Tabi Linux Kernel Developer @ Freescale

3 2

[alsa-devel] [PATCH] ASoC S3C24xx machine drivers - lm4857-h missing patch
by Graeme Gregory 19 Jun '07

19 Jun '07

Somewhere when dealing with the s3c24xx patches and requested changes I managed to miss this file on re-submission. Its a header file required for compilation of neo1973-wm8573.c and should be a no brainer. Signed-off-by: Graeme Gregory <gg(a)opensource.wolfsonmicro.com> Graeme Privacy & Confidentiality Notice ------------------------------------------------- This message and any attachments contain privileged and confidential information that is intended solely for the person(s) to whom it is addressed. If you are not an intended recipient you must not: read; copy; distribute; discuss; take any action in or make any reliance upon the contents of this message; nor open or read any attachment. If you have received this message in error, please notify us as soon as possible on the following telephone number and destroy this message including any attachments. Thank you. ------------------------------------------------- Wolfson Microelectronics plc Tel: +44 (0)131 272 7000 Fax: +44 (0)131 272 7001 Web: www.wolfsonmicro.com Registered in Scotland Company number SC089839 Registered office: Westfield House, 26 Westfield Road, Edinburgh, EH11 2QB, UK

2 1