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

[alsa-devel] Underrun problem and some basic queries
by ANISH KUMAR 04 Jan '10

04 Jan '10

1 0

[alsa-devel] [PATCH 0/5] ASoC: tlv320dac33: Adding new FIFO mode
by Peter Ujfalusi 04 Jan '10

04 Jan '10

Hello, the following series adds new FIFO operating mode to the tlv320dac33 codec driver. To be able to add new FIFO mode the code has to be restructured in order to keep it readable after the new mode is added. Since both of the support FIFO mode in the driver needs the codec to be the master, an additional check is added to avoid misconfiguration. --- Peter Ujfalusi (5): ASoC: tlv320dac33: Change nsample switch to FIFO mode enum ASoC: tlv320dac33: Introduce prefill and playback state handlers ASoC: tlv320dac33: Clean up the hardware configuration code ASoC: tlv320dac33: Add new FIFO mode: mode 7 ASoC: tlv320dac33: Safety check for codec slave mode sound/soc/codecs/tlv320dac33.c | 190 ++++++++++++++++++++++++++++++++-------- 1 files changed, 153 insertions(+), 37 deletions(-)

2 8

[alsa-devel] Underrun problem and some basic queries
by ANISH KUMAR 04 Jan '10

04 Jan '10

1 0

[alsa-devel] Echoaudio, suspend/resume question on rawmidi device
by Giuliano Pochini 03 Jan '10

03 Jan '10

I have some patches that add PM support to all echoaudio drivers. It seems to work fine, but it has been tested on two cards only and the rawmidi device hasn't been tested at all. I can't test it because suspend-to-anything does not work on my pmac. I want to be sure at least it cannot deadlock. * On suspend: Rawmidi input is interrupt-driven. The driver tells the card to stop accepting data. Rawmidi output is timer-driven. The driver uses a timer to check if the card's output buffer has room for more data to send. Do del_timer_sync() and wait until all buffered data is sent, which may take 20ms (64 bytes at 31250bps). * On resume: Input: Re-enable midi in. Output: Restart the timer. Do you see any race condition or weak points in this scheme, especially in the midi-out part ? Is del_timer_sync() safe ? -- Giuliano.

1 0

[alsa-devel] Cross-compile problem with alsa-driver version 1.0.22
by Jie Jiang 03 Jan '10

03 Jan '10

Hi all, Recently I downloaded alsa-driver 1.0.22 and tried to build for i.MX27 platform. The "INSTALL" file enclosed in this release requires "--with-cross=arm-linux-" configuration option to cross-compile alsa driver for this ARM platform. Here is my build process #./configure --with-cross=arm-linux- --with-kernel=/home/working/bsp/Kernel/linux-2.6.19.2 --with-build=/home/working/bsp/ Kernel/linux-2.6.19.2 --with-moddir=/home/working/bsp/tmp --with-debug=full --enable-dynamic-minors --with-cards=all checking for gcc... arm-linux-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. It seems that "--host=arm-linux" should be provided to configure script. However, when given the --host option, in the generated "Makefile.conf", I saw the following outputs, which are very confusing: NEW_KBUILD = mainsrcdir = . MAINSRCDIR = /work/63/alsa/alsa-driver-1.0.22 CROSS_COMPILE ?= arm-linux- ARCH ?= ifdef NEW_KBUILD CC = $(CROSS_COMPILE)arm-linux-gcc CPP = $(CROSS_COMPILE)arm-linux-gcc -E export CROSS_COMPILE ARCH else AS = $(CROSS_COMPILE)as LD = $(CROSS_COMPILE)ld CC = $(CROSS_COMPILE)arm-linux-gcc CPP = $(CROSS_COMPILE)arm-linux-gcc -E AR = $(CROSS_COMPILE)ar MODFLAGS = -DMODULE=1 CFLAGS_KERNEL = GENKSYMS = /sbin/genksyms -k 0.0.0 endif Obviously, the CC and CPP variables are not expected as "arm-linux-gcc". (There is one more $(CROSS_COMPILE)!) I overcome this problem by providing CC and CROSS_COMPILE variables with configure script: CC=gcc CROSS_COMPILE=arm-linux-gcc ./configure --with-cross=arm-linux- --with-kernel=/home/working/bsp/Kernel/linux-2.6.19.2 --with-build=/home/working/bsp/Kernel/linux-2.6.19.2 --with-moddir=/home/working/bsp/tmp --with-debug=full --enable-dynamic-minors --with-cards=all Then things become OK. What's wrong with the "INSTALL" file? Another problem. Even if "--with-cards=all" is given, codes in soc/codecs, soc/imx, and many other subdirs are not built. It seems that the configure script sets some variables according to the kernel version and target platform and outputs into "toplevel.config". Is it possible to manually edit "toplevel.config" file (after configure process) to get soc/codecs, soc/imx codes compiled? Regards, Jie

2 1

[alsa-devel] Trouble with sound over HDMI with Nvidia MCP7A HDMI
by Austin Robertson 03 Jan '10

03 Jan '10

I am having trouble getting sound over hdmi with my Nvidia MCP7A HDMI. The strange thing is that everything works fine in a Live disc, but once I do a fresh install of that Live disc I get no sound, even though my configuration is exactly the same (as far as I can tell). I've checked the little things like alsamixer volumes, aplay -l, etc etc. Everything looks good to me. I can reproduce on multiple TVs so its not the receiver. Video drivers are the same in both live version and installed. aplay -l detects my device. sound/pci/hda/patch_nvhdmi.c already has my correct vendor id in it. Perhaps the following info can help figure out what my installed environment is lacking. I've been at it for days now and I'm stumped! Any ideas? *Live Disc Info* XMBC Live 9.11 (basically a optimized version of Karmic configured to start XBMC, or Xbox Media Center, see http://www.xbmc.org for more info) NOTE: My problem is not specific to the XBMC program. Things like aplay and speaker-test don't work either. *Hardware* Acer Aspire Revo R1600 http://www.newegg.com/Product/Product.aspx?Item=N82E16883103228&Tpk=AR1600 *XBMC Live installed to hard disk via Ubuntu installer* (This setup gives me no sound over HDMI) (This is a fresh install. No additional changes were made) alsa-info.sh http://www.alsa-project.org/db/?f=ab7cef7c7233f8c42756d36e362df684b9147d38 xbmc@XBMCLive:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 3: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 xbmc@XBMCLive:~$ aplay -L default:CARD=NVidia HDA NVidia, ALC662 rev1 Analog Default Audio Device front:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog Front speakers surround40:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers hdmi:CARD=NVidia,DEV=0 HDA NVidia, NVIDIA HDMI HDMI Audio Output null Discard all samples (playback) or generate zero samples (capture) * ### speaker-test executes but NO SOUND over hdmi*. *I've also tried other devices like -D hdmi:0 -D hw:0,3 -D hdmi -D plug:hdmi, etc, etc* xbmc@XBMCLive:~$ speaker-test -D plughw:0,3 -c2 speaker-test 1.0.20 Playback device is plughw:0,3 Stream parameters are 48000Hz, S16_LE, 2 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 16384 Period size range from 32 to 8192 Using max buffer size 16384 Periods = 4 was set period_size = 4096 was set buffer_size = 16384 0 - Front Left 1 - Front Right Time per period = 5.637709 0 - Front Left xbmc@XBMCLive:~$ cat /proc/driver/nvidia/version NVRM version: NVIDIA UNIX x86 Kernel Module 190.53 Tue Dec 8 18:51:41 PST 2009 GCC version: gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) * XMBC Live Disc * ** (This setup gives me audio over hdmi perfectly) (This is running as a Live disc, ie not installed) ** alsa-info.sh http://www.alsa-project.org/db/?f=c95bebdc433f15147fb0be415be4e61e4d0b72ad [ ^<http://www.alsa-project.org/db/?f=c95bebdc433f15147fb0be415be4e61e4d0b72ad> ] xbmc@XBMCLive:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 3: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 xbmc@XBMCLive:~$ aplay -L default:CARD=NVidia HDA NVidia, ALC662 rev1 Analog Default Audio Device front:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog Front speakers surround40:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers hdmi:CARD=NVidia,DEV=0 HDA NVidia, NVIDIA HDMI HDMI Audio Output null Discard all samples (playback) or generate zero samples (capture) ###* speaker-test plays audio over hdmi perfectly. other programs play audio over hdmi.* xbmc@XBMCLive:~$ speaker-test -D plughw:0,3 -c2 speaker-test 1.0.20 Playback device is plughw:0,3 Stream parameters are 48000Hz, S16_LE, 2 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 16384 Period size range from 32 to 8192 Using max buffer size 16384 Periods = 4 was set period_size = 4096 was set buffer_size = 16384 0 - Front Left 1 - Front Right Time per period = 5.638693 xbmc@XBMCLive:~$ cat /proc/driver/nvidia/version NVRM version: NVIDIA UNIX x86 Kernel Module 190.53 Tue Dec 8 18:51:41 PST 2009 GCC version: gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) *Additional Information * I had an idea to run a diff on the two alsa-info.sh outputs of my installed and live version. (non-working and working, see above) I figured that might give me a clue on what I was missing. Most things should be identical with a few exceptions like timestamps, etc. MacBook-Austin:Desktop Austin$ diff -crB alsa-info_installed.txt alsa-info_live.txt > alsa-infodiff.diff alsa-info_installed.txt: http://pastebin.com/f63afa045 (non-working, same as above) alsa-info_live.txt: http://pastebin.com/f7b47d46d (working, same as above) alsa-infodiff.diff: http://pastebin.com/f79cf9c15 Only a few things caught my attention. At first I thought I had my playback volumes muted (line 525,532) according to the diff. But then I realized that was just for the mic, so that shouldn't matter. The only other thing that I saw was that my Amp-Out vals differed (line 123, 129). Perhaps, a more trained eye will have better luck. Bug has also been reported here: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4865

1 0

[alsa-devel] Cross-compile problem with alsa-driver version 1.0.22
by Jie Jiang 03 Jan '10

03 Jan '10

Hi all, Recently I downloaded alsa-driver 1.0.22 and tried to build for i.MX27 platform. The "INSTALL" file enclosed in this release requires "--with-cross=arm-linux-" configuration option to cross-compile alsa driver for this ARM platform. Here is my build process #./configure --with-cross=arm-linux- --with-kernel=/home/working/bsp/Kernel/linux-2.6.19.2 --with-build=/home/working/bsp/ Kernel/linux-2.6.19.2 --with-moddir=/home/working/bsp/tmp --with-debug=full --enable-dynamic-minors --with-cards=all checking for gcc... arm-linux-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. It seems that "--host=arm-linux" should be provided to configure script. However, when given the --host option, in the generated "Makefile.conf", I saw the following outputs, which are very confusing: NEW_KBUILD = mainsrcdir = . MAINSRCDIR = /work/63/alsa/alsa-driver-1.0.22 CROSS_COMPILE ?= arm-linux- ARCH ?= ifdef NEW_KBUILD CC = $(CROSS_COMPILE)arm-linux-gcc CPP = $(CROSS_COMPILE)arm-linux-gcc -E export CROSS_COMPILE ARCH else AS = $(CROSS_COMPILE)as LD = $(CROSS_COMPILE)ld CC = $(CROSS_COMPILE)arm-linux-gcc CPP = $(CROSS_COMPILE)arm-linux-gcc -E AR = $(CROSS_COMPILE)ar MODFLAGS = -DMODULE=1 CFLAGS_KERNEL = GENKSYMS = /sbin/genksyms -k 0.0.0 endif Obviously, the CC and CPP variables are not expected as "arm-linux-gcc". (There is one more $(CROSS_COMPILE)!) I overcome this problem by providing CC and CROSS_COMPILE variables with configure script: CC=gcc CROSS_COMPILE=arm-linux-gcc ./configure --with-cross=arm-linux- --with-kernel=/home/working/bsp/Kernel/linux-2.6.19.2 --with-build=/home/working/bsp/Kernel/linux-2.6.19.2 --with-moddir=/home/working/bsp/tmp --with-debug=full --enable-dynamic-minors --with-cards=all Then things become OK. What's wrong with the "INSTALL" file? Another problem. Even if "--with-cards=all" is given, codes in soc/codecs, soc/imx, and many other subdirs are not built. Is this because my target kernel version is too low (2.6.19.2)? It seems that the configure script sets some variables according to the kernel version and target platform and outputs into "toplevel.config". Is it possible to manually edit "toplevel.config" file (after configure process) to get soc/codecs, soc/imx codes compiled? Regards, Jie

1 0

[alsa-devel] Git repository from which Takashi's snapshot is taken.
by Wael Nasreddine (aka eMxyzptlk) 02 Jan '10

02 Jan '10

Hello, I would like to patch the alsa with the patch given in this message[0], which at the time, applies to Takashi's snapshot[1], but it doesn't apply at the moment, in an effort to help me maintain it I would like to apply it to the git repository from which the snapshot has been made. Can someone give me the url to the repository from which the snapshot is taken? Thanks P.S: Happy New Year!! Footnotes: ---------- [0]: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-November/023203.h… [1]: ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-sna… -- Wael Nasreddine Weem Chief-Development Officer - http://www.weem.com Blog : http://wael.nasreddine.com E-mail : wael.nasreddine(a)weem.com gTalk : wael.nasreddine(a)gmail.com Tel : +33.6.32.94.70.13 Skype : eMxyzptlk Twitter : @eMxyzptlk PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 DE12 5565 3945 C8DD 18A2 .: An infinite number of monkeys typing into GNU emacs, would never make a good program. (L. Torvalds 1995) :. /<o>\ If entropy is increasing, where is it coming from?

2 1

[alsa-devel] How to compile 1.0.22 drivers with 2.6.33-rc?
by Elimar Riesebieter 31 Dec '09

31 Dec '09

Hi all, to built alsa-driver 1.0.22.1 against 2.6.33-rc2 I had to copy files of kernels's include/generated to include/linux. Is there a more elegant way to improve that? I want to prepare a Debian upload. So users which are running 2.6.33 can't compile the 1.0.22 drivers without manipulating the kernel built dir. Any hints? Thanks Elimar -- On the keyboard of life you have always to keep a finger at the escape key;-)

1 0

[alsa-devel] [PATCH v2] soc-cache: cleanup training whitespace and coding style
by Barry Song 31 Dec '09

31 Dec '09

Signed-off-by: Barry Song <21cnbao(a)gmail.com> --- sound/soc/soc-cache.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-cache.c b/sound/soc/soc-cache.c index d2505e8..02c2357 100644 --- a/sound/soc/soc-cache.c +++ b/sound/soc/soc-cache.c @@ -182,7 +182,7 @@ static struct { { .addr_bits = 7, .data_bits = 9, .write = snd_soc_7_9_write, .read = snd_soc_7_9_read, - .spi_write = snd_soc_7_9_spi_write + .spi_write = snd_soc_7_9_spi_write, }, { .addr_bits = 8, .data_bits = 8, -- 1.5.6.3

2 1