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

[alsa-devel] Using speaker-test for sound cards which dont support mmap
by Pharaoh . 12 Jul '07

12 Jul '07

Is it possible to use speaker-test for sound cards which do not support mmap? I straced speaker-test and it uses mmap call, can we bypass this?

3 2

[alsa-devel] Help with ALSA application development
by Paul Kavan 12 Jul '07

12 Jul '07

Hello: I am still trying to write my own basic application that captures and plays audio. I am working in an embedded linux environment and have the drivers working well. I can use arecord/aplay without any problem. However, I have been trying to follow some web examples for simple capture and playback without any success. Does anyone know of some sample code for S8 formatted, 8k rate capture and playback. I think my problem is two-fold. First is getting the hw-params set correctly. I have a function call that sets the interface up. I am trying to use the same params that aplay -v returns to me, but perhaps I have them wrong somehow. Secondly is buffering the samples. I am not sure I have that correct. Does anyone have some pointers on that? I have attached my code. If anyone has some time and insight into this, I would greatly appreciate it. Thanks. Paul

2 1

[alsa-devel] non-interleaved mode
by Steve Longerbeam 11 Jul '07

11 Jul '07

Hi, The driver for the sound engine I'm working on requires NONINTERLEAVED. Will ALSA core give my driver a full period of left-only samples, followed by a full period of right-only samples? Or are left/right samples split within a single period (ie. first half of period is left samples, second half is right samples)? Thanks, Steve

4 6

Re: [alsa-devel] Errors in application building
by Paul Kavan 11 Jul '07

11 Jul '07

On 7/3/07, Lee Revell <rlrevell(a)joe-job.com> wrote: > > Use gdb, strace is not useful for this > > On 7/3/07, Paul Kavan <pkavan(a)gmail.com> wrote: > > Hello all: > > > > Just tried to run with the warnings: > > > > > > > > > > > > > grhuser@pcL7:$ arm-linux-gcc -lasound -Wall -o grh_audio grh_audio.c > > > grh_audio.c: In function 'grh_capture': > > > grh_audio.c:112: warning: pointer targets in passing argument 3 of > > 'snd_pcm_hw_params_set_rate_near' differ in signedness > > > grh_audio.c: In function 'grh_playback': > > > grh_audio.c:207: warning: pointer targets in passing argument 3 of > > 'snd_pcm_hw_params_set_rate_near' differ in signedness > > > > > > Which comes from the code: > > > > > > 112: if ((err = snd_pcm_hw_params_set_rate_near (capture_handle, > > hw_params, &sample_rate, 0)) < 0) > > > > > > > > > 207: if ((err = snd_pcm_hw_params_set_rate_near (playback_handle, > > hw_params, &sample_rate, 0)) < 0) > > > > However, I get a seg fault when I ran it. The strace of this is: > > > > /usr/sbin $ strace grh_audio > > execve("/usr/sbin/grh_audio", ["grh_audio"], [/* 7 vars */]) = 0 > > mmap2(NULL, 20, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) > = > > 0x40005000 > > stat("/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=1150, ...}) = 0 > > open("/etc/ld.so.cache", O_RDONLY) = 3 > > mmap2(NULL, 1150, PROT_READ, MAP_SHARED, 3, 0) = 0x40006000 > > close(3) = 0 > > open("/usr/lib/libasound.so.2", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0755, st_size=762072, ...}) = 0 > > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = > > 0x40007000 > > read(3, > > "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0x\367\1\000"..., > > 4096) = 4096 > > mmap2(NULL, 794624, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > > 0x4000e000 > > mmap2(0x4000e000, 745564, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, > 0) > > = 0x4000e000 > > mmap2(0x400cc000, 15508, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, > > 0xb6) = 0x400cc000 > > close(3) = 0 > > munmap(0x40007000, 4096) = 0 > > open("/lib/libgcc_s.so.1", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0644, st_size=44167, ...}) = 0 > > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = > > 0x40007000 > > read(3, > > "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0X\25\0\000"..., > > 4096) = 4096 > > mmap2(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x400d0000 > > mmap2(0x400d0000, 28800, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, > 0) = > > 0x400d0000 > > mmap2(0x400df000, 548, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, > 0x7) > > = 0x400df000 > > close(3) = 0 > > munmap(0x40007000, 4096) = 0 > > open("/lib/libc.so.0", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0644, st_size=309840, ...}) = 0 > > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = > > 0x40007000 > > read(3, > > "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0000\253\0"..., > > 4096) = 4096 > > mmap2(NULL, 360448, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > > 0x400e0000 > > mmap2(0x400e0000, 302380, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, > 0) > > = 0x400e0000 > > mmap2(0x40132000, 5172, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, > > 0x4a) = 0x40132000 > > mmap2(0x40134000, 16020, PROT_READ|PROT_WRITE, > > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40130 > > close(3) = 0 > > munmap(0x40007000, 4096) = 0 > > open("/lib/libm.so.0", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0644, st_size=45812, ...}) = 0 > > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = > > 0x40007000 > > read(3, > > "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0t\22\0\000"..., > > 4096) = 4096 > > mmap2(NULL, 81920, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x40138000 > > mmap2(0x40138000, 41428, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, > 0) = > > 0x40138000 > > mmap2(0x4014a000, 4100, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, > 0xa) > > = 0x4014a000 > > close(3) = 0 > > munmap(0x40007000, 4096) = 0 > > open("/lib/libdl.so.0", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0644, st_size=8900, ...}) = 0 > > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = > > 0x40007000 > > read(3, > > "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0(\10\0\000"..., > > 4096) = 4096 > > mmap2(NULL, 40960, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x4014c000 > > mmap2(0x4014c000, 5760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, > 0) = > > 0x4014c000 > > mmap2(0x40155000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, > 0x1) > > = 0x40155000 > > close(3) = 0 > > munmap(0x40007000, 4096) = 0 > > open("/lib/libpthread.so.0", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0644, st_size=63852, ...}) = 0 > > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = > > 0x40007000 > > read(3, > > "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0D<\0\0004"..., > > 4096) = 4096 > > mmap2(NULL, 106496, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > > 0x40156000 > > mmap2(0x40156000, 40952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, > 0) = > > 0x40156000 > > mmap2(0x40168000, 21732, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, > > 0xa) = 0x40168000 > > mmap2(0x4016e000, 5788, PROT_READ|PROT_WRITE, > > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4016e0 > > close(3) = 0 > > munmap(0x40007000, 4096) = 0 > > open("/lib/libgcc_s.so.1", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0644, st_size=44167, ...}) = 0 > > close(3) = 0 > > open("/lib/libc.so.0", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0644, st_size=309840, ...}) = 0 > > close(3) = 0 > > open("/lib/libc.so.0", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0644, st_size=309840, ...}) = 0 > > close(3) = 0 > > open("/lib/libc.so.0", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0644, st_size=309840, ...}) = 0 > > close(3) = 0 > > open("/lib/libc.so.0", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0644, st_size=309840, ...}) = 0 > > close(3) = 0 > > open("/lib/libc.so.0", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0644, st_size=309840, ...}) = 0 > > close(3) = 0 > > munmap(0x40006000, 1150) = 0 > > stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=21096, ...}) > = 0 > > mprotect(0x40132000, 4096, PROT_READ) = 0 > > mprotect(0x4014a000, 4096, PROT_READ) = 0 > > mprotect(0x40155000, 4096, PROT_READ) = 0 > > mprotect(0x40168000, 4096, PROT_READ) = 0 > > mprotect(0x4000c000, 4096, PROT_READ) = 0 > > ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo > > ...}) = 0 > > ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo > > ...}) = 0 > > getpid() = 756 > > getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = > 0 > > setrlimit(RLIMIT_STACK, {rlim_cur=2040*1024, rlim_max=RLIM_INFINITY}) = > 0 > > rt_sigaction(SIGRTMIN, {0x4015fd70, [], 0x4000000 /* SA_??? */}, NULL, > 8) = > > 0 > > rt_sigaction(SIGRT_1, {0x4015fc98, [RTMIN], 0x4000000 /* SA_??? */}, > NULL, > > 8) = 0 > > rt_sigaction(SIGRT_2, {0x4015f2d0, [], 0x4000000 /* SA_??? */}, NULL, 8) > = 0 > > rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0 > > rt_sigprocmask(SIG_UNBLOCK, [RT_1], NULL, 8) = 0 > > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > > +++ killed by SIGSEGV +++ > > Process 756 detached > > > > > > I am still trying to locate why those warnings are popping up, but as > that > > part of the code is not called immediately, I am wondering why the seg > fault > > is occurring. Any clues? Lee: Have attempted to run this with gdb. However, I get: /usr/sbin $ gdb grh_audio dlopen failed on 'libthread_db.so.1' - File not found GDB will not be able to debug pthreads. GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "arm-linux-uclibc"...(no debugging symbols found) (gdb) Trying to determine why...will let you know asap what I find. Paul -- *************************************** Paul David Kavan Project Engineer GRH Electronics, Inc. 402-734-4900 pkavan(a)gmail.com ***************************************

2 7

[alsa-devel] Query regarding sampling rates etc
by Pharaoh . 11 Jul '07

11 Jul '07

Hi, This is a very vague question, just thought of asking it after hours of debugging. I am testing my alsa driver, written for omap 730/850 based board. I am testing it by using aplay. Despite checking clocks, sampling rates etc many times and after doing many combinations thereof, I cant hear anything more than a noise which changes and becomes more like the original .wav file as I change various params like sampling rates/clocks etc. It becomes close to the actual thing, but not better. Any idea what are the params I should be tweaking? I know this is h/w dependent. -pharaoh

3 3

Re: [alsa-devel] RE : M-Audio Audiophile USB, native little endian (S16_LE) ?
by Hakan Lennestal 11 Jul '07

11 Jul '07

> You'll find attached an equivalent fix that checks alt-settings > instead of device_setup param: Can you try it Hakan ? Ok, patch tested now. Seem to work. /Håkan

1 0

[alsa-devel] Alsa lib configure asoundlib.h
by Fausto Carvalho Marques SIlva 11 Jul '07

11 Jul '07

In salsa library(this library really saved my life, from am alsa-lib of 600K to 45K!!!), developed by Takashi Iwai, the creation of asoundlib.h is dynamic and based on the configure options ( --disable-mixer will remove mixer.h from asoundlib.h). Can alsa-lib do the same??I think it is a good "cleanup" way of doing client header files. Example from configure.ac from salsa-0.0.6: " echo "Creating asoundlib.h..." cp "$srcdir"/src/asoundlib-head.h src/asoundlib.h test "$mixer" = "yes" && echo "#include \"mixer.h\"" >> src/asoundlib.h test "$rawmidi" = "yes" && echo "#include \"rawmidi.h\"" >> src/asoundlib.h test "$hwdep" = "yes" && echo "#include \"hwdep.h\"" >> src/asoundlib.h test "$timer" = "yes" && echo "#include \"timer.h\"" >> src/asoundlib.h test "$sndconf" = "yes" && echo "#include \"conf.h\"" >> src/asoundlib.h test "$sndseq" = "yes" && echo "#include \"seq_event.h\"" >> src/asoundlib.h test "$sndseq" = "yes" && echo "#include \"seq.h\"" >> src/asoundlib.h test "$sndseq" = "yes" && echo "#include \"seqmid.h\"" >> src/asoundlib.h cat "$srcdir"/src/asoundlib-tail.h >> src/asoundlib.h " Fausto Carvalho Marques Silva

4 11

[alsa-devel] Mercurial repos
by Adrian McMenamin 11 Jul '07

11 Jul '07

Are the browsable repos broken - they don't seem to have been updated for days, though I've been told my patch has been applied.

3 2

Re: [alsa-devel] Writing a new plugin for ALSA
by Nobin Mathew 11 Jul '07

11 Jul '07

On 7/10/07, Takashi Iwai <tiwai(a)suse.de> wrote: > At Tue, 10 Jul 2007 17:45:03 +0530, > Sudhanshu Saxena wrote: > > > > Hi Takashi, > > > > I am working on this issue along with Nobin, for multiple multiple streams (at > > different rates) playback based on a priority. > > > > I attempted suspend and resume returning -ESTRPIPE, but it has two issues > > 1) All applications may need a change in Suspend logic specific to wait for higher > > priority stream to run to completion. > > Basically every app is _required_ to handle of suspend/resume > properly. > > > 2) I have to still find out a mechanism to reset the hardware settings are reconfigure > > it for second stream. > > snd_pcm_hw_reset has an access to reset using IOCTL "SNDRV_PCM_IOCTL_RESET" , I hope > > that can help, I am not > > very sure on this. > > Well, I don't think the plugin itself requires the reset. > > > As mentioned by Nobin we want to skip any upsampling caused when we use the dmix > > (rate) plugin. > > I was trying to find the way out, with a plugin with following changes: > > 1) All streams will open pcm with a priority. (Pre decided for the system) > > 2) Plug-in will have shared memory to hold the priority list of all applications which > > are accessing sound. > > 3) At any instance only one stream will be active. > > 4) All applications will hold the context of HW params and SW params (accessible > > through apis plugin will support). > > 5) If an application with a higher priority calls snd_pcm_open shared memory with the > > priority list will be updated and > > when the currently active stream attempts to re-write the data it will check for > > priority list. This will cause saving of params, drain of stream and reset of hw as > > mentioned using above IOCTL and the active stream would be changed to > > currently highest in the priority list. > > 6) The higher priority stream can then start writing data, on completion of access > > similar sequence of drain, hw reset will be caused and the active stream will be > > changed to next in the priority list. > > 7) On resume of lower priority stream the hw params will be set again. > > The question is how the application decides which stream to use. > If it can open a PCM with a different name (to snd_pcm_open call), and > if you have three individual PCM devices, the whole switching can > be done inside the kernel driver. That is, when an SCO stream is > opened during audio stream(s) is running, the driver triggers SUSPEND > mode for the audio stream. Then the app will stop and restart the > stream by itself. This means you don't need any change in user-space > side but needs some additions in the driver side. We thought about implementing this in the kernel driver, but after some investigation, we found that we are serializing the driver so much by providing three interfaces (audio, sco and Nav). say pcmC0D0p/c, pcmC0D1p/c and pcmC0D2p/c. Consider the case of two apps audio and sco. We have two interfaces for this pcmC0D0p/c and pcmC0D1p/c priority is audio < sco so interface priority is pcmC0D0p/c < pcmC0D1p/c. Assume that audio is already opened. When we open sco interface audio interface can be in any state, it i can be in paused state or it is about to close etc. So we will have so many states of application in the kernel driver. we need to maintain all these states of application in the kernel driver. Say tomorrow one more application came in to picture, then this complexity will increase. Locking of states of streams is also required in this case. correct me if I am going wrong > > BTW, any reason to drop Cc to alsa-devel ML? Such an open discussion > is very important for opensource development. I think Sudhanshu missed it, I am copying to alsa-devel > > > Takashi > thanks Nobin mathew

2 3

[alsa-devel] [PATCH] hda-codec - Add VIA HDA to si3054
by Claudio Matsuoka 10 Jul '07

10 Jul '07

The attached patch is needed to proper recognition of the si3054 modem in the Clevo m540 laptop. Thanks, Claudio

1 0