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

[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

[alsa-devel] Changing the sample rate/channels of an already opened PCM stream
by Ed Schouten 19 Jun '07

19 Jun '07

Hello, I am the author of the command line music player Herrie (http://herrie.info/). For a long time folks have asked me to add support for OSS to Herrie, so this morning I decided to install Linux on a spare disk of mine (Ubuntu 7.04, FWIW) to hack on ALSA support for Herrie. After (a real lot of) hours of reading code, reading the Doxygen stuff, etc. I now have a functional ALSA output module for Herrie. It was quite hard to get it working, so I guess I owe myself a beer! ;-) Anyway, there still is one disadvantage to my module; each time I detect that a new track is going to be started that needs a different amount of channels or sample rate, I reopen the ALSA device, something that is just impossible. The reason why it's impossible: Herrie has a nifty chroot() functionality that allows users to trap the application in a certain directory. I have been trying to get the device to reset so I can change the sample rate, but for some reason, it just gets ignored. Can someone explain me how it's possible to reset the sample rate after preparing the handle? For your information, here's a link to the latest version of the source code of my ALSA module: http://g-rave.nl/gitweb?p=herrie;a=blob;f=herrie/src/audio_output_alsa.c Yours, -- Ed Schouten <ed(a)fxq.nl> WWW: http://g-rave.nl/

2 2

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

18 Jun '07

Hello all: I am working on a driver for a dumb codec to work with the SSC as a PCM on the AT91SAM9260. I have, with the gracious help of Frank Mandarino, have the glue code written without too many problems. However, I need some guidance on getting a few things configured correctly for my codec and then getting it to compile and load correctly. For configuration, I am using the Winbond W6811. For this, I am going to use a 256kHz BCLK and an 8kHz frame. Each sample consists of 8-bit u-law PCM, MSB first. When I execute a read from the codec to the processor, I need to make the reads on the falling edge of the BCLK at each sync pulse. When executing a write from the processor to the codec I need to write on the rising edge at each sync pulse. I think I the timing correct in my driver with: cmr_div = 187; /* PCM_CLK = ~96MHz/(2*187) = 256kHz */ period = 15; /* PCM_SYNC = PCM_CLK/(2*(15+1)) = 8000Hz */ However, I am not sure how to get the following correct for my needs: #define W6811_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE) Now to making the driver once the code is done. I am relatively new to writing linux drivers. In the 6 or so that I have written, I usually cross-compile them as modules and then insmod them. I have tried that here and am getting a strange warning that I am unsure of. I have a pretty simple Makefile and when I execute it, I get: make ARCH=arm CROSS_COMPILE=arm-linux- make -C ~/Linux_Builds/linux-2.6.21.5M=/home/grhuser/Door_Access_System/Remotes/Driver/sound modules make[1]: Entering directory `/home/grhuser/Linux_Builds/linux- 2.6.21.5' CC [M] /home/grhuser/Door_Access_System/Remotes/Driver/sound/grh_ek_w6811.o Building modules, stage 2. MODPOST 1 modules WARNING: "at91_ssc_dai" [/home/grhuser/Door_Access_System/Remotes/Driver/sound/grh_ek_w6811.ko] undefined! CC /home/grhuser/Door_Access_System/Remotes/Driver/sound/grh_ek_w6811.mod.o LD [M] /home/grhuser/Door_Access_System/Remotes/Driver/sound/grh_ek_w6811.ko make[1]: Leaving directory `/home/grhuser/Linux_Builds/linux- 2.6.21.5' As you can see, I am using linux-2.6.21.5 I have ALSA checked and AT91-SoC checked in my .config file. For this attempt to build the driver, I have a separate folder than contains: at91-ssc.h and at91-pcm.h. If there is a more correct way to do this and be able to debug it, please let me know. I have attached copies of my driver. I would appreciate any and all feedback and assistance on getting this running.

2 6

[alsa-devel] .asoundrc
by Nobin Mathew 18 Jun '07

18 Jun '07

Hi, I am trying to write one .asoundrc file What i am currently doing is rate conversion My .asounrc file contains pcm.sirf3a { type rate slave { pcm "hw:0,0" rate 8000 } } I am using following command aplay -M -D sirf3a /usr/share/sounds/alsa/Side_Right.wav But it is giving me some errors aplay: set_params:909: Channels count non available Any idea why this? where I am going wrong?

2 2

[alsa-devel] [ASoC] Missing shutdown() vectors in ASoC
by Nobin Mathew 18 Jun '07

18 Jun '07

Liam, Shutdown() vectors is missing in ASoC, we need this to ensure proper shutdown of the system. * codec device */ struct snd_soc_codec_device { int (*probe)(struct platform_device *pdev); int (*remove)(struct platform_device *pdev); int (*suspend)(struct platform_device *pdev, pm_message_t state); int (*resume)(struct platform_device *pdev); }; /* SoC CPU DAI */ struct snd_soc_cpu_dai { /* DAI description */ char *name; unsigned int id; unsigned char type; /* DAI callbacks */ int (*probe)(struct platform_device *pdev); void (*remove)(struct platform_device *pdev); int (*suspend)(struct platform_device *pdev, struct snd_soc_cpu_dai *cpu_dai); int (*resume)(struct platform_device *pdev, struct snd_soc_cpu_dai *cpu_dai); unsigned int (*config_sysclk)(struct snd_soc_cpu_dai *cpu_dai, struct snd_soc_clock_info *info, unsigned int clk); /* DAI capabilities */ struct snd_soc_pcm_stream capture; struct snd_soc_pcm_stream playback; struct snd_soc_dai_cap caps; /* SoC platform interface */ struct snd_soc_platform { char *name; int (*probe)(struct platform_device *pdev); int (*remove)(struct platform_device *pdev); int (*suspend)(struct platform_device *pdev, struct snd_soc_cpu_dai *cpu_dai); int (*resume)(struct platform_device *pdev, struct snd_soc_cpu_dai *cpu_dai); /* pcm creation and destruction */ /* SoC machine */ struct snd_soc_machine { char *name; int (*probe)(struct platform_device *pdev); int (*remove)(struct platform_device *pdev); /* the pre and post PM functions are used to do any PM work before and * after the codec and DAI's do any PM work. */ int (*suspend_pre)(struct platform_device *pdev, pm_message_t state); int (*suspend_post)(struct platform_device *pdev, pm_message_t state); int (*resume_pre)(struct platform_device *pdev); int (*resume_post)(struct platform_device *pdev); Nobin Mathew

2 4

[alsa-devel] Query regarding pcm->private_data
by Pharaoh . 18 Jun '07

18 Jun '07

Hi I am reading 'Wring an alsa driver'. It says following about the private_data: You can allocate a record for the substream and store it in runtime->private_data. Usually, this is done in the open callback. Don't mix this with pcm->private_data. The pcm->private_data usually points the chip instance assigned statically at the creation of PCM, while the runtime->private_data points a dynamic data created at the PCM open callback. What does static and dynamic mean here? Apologies for this question if it sounds very novice, since my understanding is it doesn't mean static and dynamic in the usual way like stack and heap etc. Why I am being so paranoid about this has reason: In my ALSA driver I am assigning pcm->private_data = mychip, but it is NULL in the snd_pcm_attach_substream() function. I have checked my code many times and I tried with another driver which was working when tested using ALSA utils. Currently I am testing using the OSS emulation i.e. simply cat /dev/audio.

2 1