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

[alsa-devel] $1000 bounty for getting audio working under linux on a Osprey 440
by Nathan Allen Stratton 25 Jun '07

25 Jun '07

Need to get audio working on Osprey 440 card. http://www.viewcast.com/pages.asp?page=osprey-440 The card is bt878 based, and ViewCast says it is supported on linux however not something they support. Audio is not detected by default, but does how up when you do a modprobe snd-bt87x load-all(see below). However I have not been able to pull audio from the card (only get high pitched noise). Bid may require patching bt878.c if modprobe options don't work. Only mono support is required. [root@video share]# amixer Simple mixer control 'Bass',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 48 Mono: 30 [62%] Simple mixer control 'Bass Boost',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'Treble',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 48 Mono: 24 [50%] Simple mixer control 'PCM',0 Capabilities: pvolume cvolume pswitch pswitch-joined cswitch cswitch-joined Playback channels: Front Left - Front Right Capture channels: Mono Limits: Playback 0 - 44 Capture 0 - 15 Mono: Capture 15 [100%] [15.00dB] [on] Front Left: Playback 44 [100%] [3.00dB] [on] Front Right: Playback 44 [100%] [3.00dB] [on] Simple mixer control 'PCM Capture Source',0 Capabilities: enum Items: 'PCM' 'Mic' 'Input 2' Item0: 'Input 2' Simple mixer control 'PCM',1 Capabilities: cvolume Capture channels: Mono Limits: Capture 0 - 656 Mono: Capture 0 [0%] [-41.00dB] Simple mixer control 'Mic',0 Capabilities: cvolume Capture channels: Mono Limits: Capture 0 - 15 Mono: Capture 0 [0%] [16.00dB] Simple mixer control 'Auto Gain Control',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] [root@video share]# amixer -c 1 Simple mixer control 'FM',0 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [off] Simple mixer control 'Mic/Line',0 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [on] Simple mixer control 'Capture',0 Capabilities: cvolume Capture channels: Mono Limits: Capture 0 - 15 Mono: Capture 15 [100%] Simple mixer control 'Capture Boost',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off] Simple mixer control 'TV Tuner',0 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [off] :::::::::::::: cards :::::::::::::: 0 [INport ]: USB-Audio - INport Xitel INport at usb-0000:00:1d.0-1, full speed 1 [Bt878 ]: Bt87x - Brooktree Bt878 Brooktree Bt878 at 0xd8001000, irq 16 2 [Bt878_1 ]: Bt87x - Brooktree Bt878 Brooktree Bt878 at 0xd8003000, irq 17 3 [Bt878_2 ]: Bt87x - Brooktree Bt878 Brooktree Bt878 at 0xd8005000, irq 18 4 [Bt878_3 ]: Bt87x - Brooktree Bt878 Brooktree Bt878 at 0xd8007000, irq 19 :::::::::::::: devices :::::::::::::: 2: : timer 3: : sequencer 4: [ 0- 0]: digital audio playback 5: [ 0- 0]: digital audio capture 6: [ 0] : control 7: [ 1- 1]: digital audio capture 8: [ 1- 0]: digital audio capture 9: [ 1] : control 10: [ 2- 1]: digital audio capture 11: [ 2- 0]: digital audio capture 12: [ 2] : control 13: [ 3- 1]: digital audio capture 14: [ 3- 0]: digital audio capture 15: [ 3] : control 16: [ 4- 1]: digital audio capture 17: [ 4- 0]: digital audio capture 18: [ 4] : control :::::::::::::: hwdep :::::::::::::: *** INport: directory *** :::::::::::::: modules :::::::::::::: 0 snd_usb_audio 1 snd_bt87x 2 snd_bt87x 3 snd_bt87x 4 snd_bt87x *** oss: directory *** :::::::::::::: pcm :::::::::::::: 00-00: USB Audio : USB Audio : playback 1 : capture 1 01-01: Bt87x Analog : Bt87x Analog : capture 1 01-00: Bt87x Digital : Bt87x Digital : capture 1 02-01: Bt87x Analog : Bt87x Analog : capture 1 02-00: Bt87x Digital : Bt87x Digital : capture 1 03-01: Bt87x Analog : Bt87x Analog : capture 1 03-00: Bt87x Digital : Bt87x Digital : capture 1 04-01: Bt87x Analog : Bt87x Analog : capture 1 04-00: Bt87x Digital : Bt87x Digital : capture 1 *** seq: directory *** :::::::::::::: timers :::::::::::::: G0: system timer : 1000.000us (10000000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE P1-0-1: PCM capture 1-0-1 : SLAVE P1-1-1: PCM capture 1-1-1 : SLAVE P2-0-1: PCM capture 2-0-1 : SLAVE P2-1-1: PCM capture 2-1-1 : SLAVE P3-0-1: PCM capture 3-0-1 : SLAVE P3-1-1: PCM capture 3-1-1 : SLAVE P4-0-1: PCM capture 4-0-1 : SLAVE P4-1-1: PCM capture 4-1-1 : SLAVE :::::::::::::: version :::::::::::::: Advanced Linux Sound Architecture Driver Version 1.0.14rc3 (Wed Mar 14 07:25:50 2007 UTC). unknown card 0x878-0x70:0xff07, using default rate 32000 please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)lists.sf.net> ACPI: PCI Interrupt 0000:06:04.1[A] -> GSI 16 (level, low) -> IRQ 16 unknown card 0x878-0x70:0xff07, using default rate 32000 please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)lists.sf.net> ACPI: PCI Interrupt 0000:06:05.1[A] -> GSI 17 (level, low) -> IRQ 17 unknown card 0x878-0x70:0xff07, using default rate 32000 please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)lists.sf.net> ACPI: PCI Interrupt 0000:06:06.1[A] -> GSI 18 (level, low) -> IRQ 18 unknown card 0x878-0x70:0xff07, using default rate 32000 please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)lists.sf.net> ACPI: PCI Interrupt 0000:06:07.1[A] -> GSI 19 (level, low) -> IRQ 19 ><> Nathan Stratton CTO, Voila IP Communications nathan at robotics.net nathan at voilaip.com http://www.robotics.net http://www.voilaip.com

2 3

[alsa-devel] pcm->private_data is NULL in alsa core!!
by Pharaoh . 22 Jun '07

22 Jun '07

Hi I am writing an alsa driver for my omap based board. I am testing it using cat /dev/audio currently, i.e. I have OSS emulation turned on. This is an initial round of testing and I will use alsa-libs and utils later. My problem is: I have set the pcm->private_data = my_chip after registering the pcm ops, after referring various standard drivers in alsa tree. My module is insmoded properly but after I do snd_card_register(card) the pcm->private_data is corrupted !! Before this step, the pcm->private_data is intact. But after looking at the snd_card_register(), I realized that it doesn't even touch the pcm pointer. So, when I cat the device I get huge segfault in snd_pcm_attach_substream(), since pcm->private_data is NULL but surprisingly all the other fields are intact in pcm pointer. Even the OSS code doesn't touch the pcm pointer, what must be wrong? I have checked my source atleast 5 times and couldn't find anything in it. -pharaoh.

2 14

[alsa-devel] AT91 SoC PCM Capture
by Paul Kavan 22 Jun '07

22 Jun '07

I am wondering what piece of code contains the capture functionality for the at91 soc. I am hoping to see how and when the pcm activates the ssc at read time. I just cannot figure out why TD0 would behave at such with this set of code and yet behave correctly with my polling code. Not a criticism....just wanting to figure this out. Paul -- *************************************** Paul David Kavan Project Engineer GRH Electronics, Inc. 402-734-4900 pkavan(a)gmail.com ***************************************

2 1

[alsa-devel] Osprey 440 almost supported!!! Need X9221 i2c support!
by Nathan Allen Stratton 22 Jun '07

22 Jun '07

This card does not use analog bt878a inputs, but rather the digital input. To get audio working I set the mask to 000303, first two bits are for the audio rate, 00 is 32000, 01 is 41000, 10 is 4800. The first two bits in the next byte are for balanced or unbalanced audio input. 0x00 for unbalanced and 0x100 for balanced. So I am using: modprobe bttv card=140 bttv_gpio=1 bttv_verbose=2 bttv_debug=1 gpiomask=0x020303 audioall=0xFFFDFC bttv: Bt8xx card found (0). bttv0: Bt878 (rev 17) at 0000:08:04.0, irq: 24, latency: 132, mmio: 0xc8600000 bttv0: detected: Osprey-440 [card=140], PCI subsystem ID is 0070:ff07 bttv0: using: Osprey 440 [card=140,insmod option] bttv0: gpio config override: mask=0x20303, mux=0xfffdfc,0xfffdfc,0xfffdfc,0xfffdfc bttv0: gpio: en=00000000, out=00000000 in=00feffff [pre-init] bttv0: risc main @ 37f25000 bttv0: gpio: en=00000000, out=00000000 in=00feffff [init] bttv0: BT878A ARESET bttv0: tveeprom i2c attach [addr=0x50,client=tveeprom] bttv0: using tuner=-1 bttv0: i2c: checking for TDA9887 @ 0x86... not found bttv0: registered device video0 bttv0: registered device vbi0 bttv0: gpio: en=00020303, out=00000000 in=00fcfcfc [audio: mute] bttv0: video mux: input=0 mux=2 bttv0: gpio: en=00020303, out=00000000 in=00fcfcfc [audio: mute] bttv0: PLL: 28636363 => 35468950 .<7>bttv0: gpio: en=00020303, out=00000000 in=00fcfcfc [audio: mute] ok So the issue now is that the audio is WAY to high so it is very distorted. The audio is controlled via X9221A chips on the i2c bus at 0x50, there are not drivers for X9221 so I can't lower the audio levels. Anyone able to help me with this last part??? ><> Nathan Stratton CTO, Voila IP Communications nathan at robotics.net nathan at voilaip.com http://www.robotics.net http://www.voilaip.com

2 2

[alsa-devel] Driver for Creamware / SonicCore Pulsar, which information needed?
by Kaspar Schleiser 22 Jun '07

22 Jun '07

Hey, I've got a Creamware Pulsar DSP card. As it actually has NO support for linux, I asked the vendor whether support was planned or if I could get necessary technical information. they answered they'd not have concrete plans on supporting linux and what information I'd need for the development of a driver. As I never wrote a driver, I don't know that, so maybe you could help me giving a useful answer ... What do we need to write a driver? Would anyone be interested in writing a driver? I could lend my card. It's a high quality multichannel card with 3 DSP chips on it. Cheers Kaspar

1 0

[alsa-devel] Steps get aplay and arecord working on an embedded board
by Pharaoh . 22 Jun '07

22 Jun '07

Hi I have to test my audio driver on an omap based board. I have got the lib and utils on my board but dont know the exact steps to follow for using aplay etc. Can anyone point me to relevant documentation? Couldn't find any. Or just brief outline about the steops to follow would be great help. -pharaoh

2 2

[alsa-devel] What is CONFIG_I2C_MODULE?
by Timur Tabi 21 Jun '07

21 Jun '07

In a lot of ALSA drivers, I see this: #if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE) What is CONFIG_I2C_MODULE? I've searched all the Kconfigs, and I cannot see this configuration option. -- Timur Tabi Linux Kernel Developer @ Freescale

1 0

[alsa-devel] HDA - Change default configuration for Fujitsu Si3515.
by Tobin Davis 21 Jun '07

21 Jun '07

This patch changes the default configuration for the Fujitsu Siemens Si3515 Laptop. Signed off by Tobin Davis <tdavis(a)dsl-only.net>

1 0

[alsa-devel] Help with SoC alsa.conf
by Paul Kavan 21 Jun '07

21 Jun '07

I am trying to determine an appropriate conf file for my AT91SAM9260ek running linux-2.6.22-rc1 and the following alsa drivers: <6>Advanced Linux Sound Architecture Driver Version 1.0.14rc4 (Wed May 09 09:51:39 2007 UTC). <6>ASoC version 0.13.0 <4>AT91SAM9260EK W6811 Driver <1> <6>w6811: W6811 PCM SoC Audio 0.1 <6>asoc: W6811 <-> at91-ssc0 mapping ok <6>grh_ek_w6811: W6811 PCM in Slave Mode <6>ALSA device list: <6> #0: GRH_EK_W6811 (W6811) I have installed alsa-lib-1.0.14a and alsa-utils-1.0.14 on the at91sam9260. The default conf file produces sound using speaker-test and aplay, but will not record using arecord. Frank Mandarino has been kind enough to lend me a barebones conf that worked for him: pcm.!default { type hw card 0 } pcm.hw { type hw card 0 device 0 subdevice 0 } ctl.!default { type hw card 0 } ctl.hw { type hw card 0 } but produces the following for me: /usr/share/alsa $ aplay -l **** List of PLAYBACK Hardware Devices **** ALSA lib conf.c:3949:(snd_config_expand) Unknown parameters 0 ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL hw:0 aplay: device_list:213: control open (0): Invalid argument ALSA is *very* new to me and I am unsure how to interpret any of this. I am using a dumb W6811 pcm codec. I am fairly confident the machine/codec driver is working as expected, so I need to determine what I can do to get alsa to play nice with it as well. When I use the default alsa.conf produced from making alsa-libs, I get the following: /usr/share/alsa $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: GRHEKW6811 [GRH_EK_W6811], device 0: W6811 W6811-PCM-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 record and playing do not seem to work. When I try: /usr/share/alsa $ arecord -d5 test.wav Recording WAVE 'test.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono Aborted by signal Interrupt... It does not stop at 5 seconds....I have to interrupt it manually. Furthermore, it does not appear to record anything as when I: /usr/share/alsa $ aplay test.wav Playing WAVE ' test.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono The speaker pops once, but no audio. Finally, when I use speaker-test, I get some weird results. Doing: /usr/share/alsa $ speaker-test -r8000 -c1 -f1000 -tsine -l1 speaker-test 1.0.14 Playback device is default Stream parameters are 8000Hz, S16_LE, 1 channels Sine wave rate is 1000.0000Hz Rate set to 8000Hz (requested 8000Hz) Buffer size range from 64 to 32768 Period size range from 32 to 8192 Using max buffer size 32768 Periods = 4 was set period_size = 8192 was set buffer_size = 32768 0 - Front Left Time per period = 5.086305 Gives me a wave composed of both the 1k sine and likely a 2k sine. If I go much below 1k, I get a periodic wave, but it looks more like a heart beat. My codec expects u-law, so that may be the problem with speaker-test. However, the fact the aplay and arecord are not working give me pause. I would be greatly appreciative of any insights, pointers, etc. If there is more information that would be helpful, please ask. Thanks. Paul -- *************************************** Paul David Kavan Project Engineer GRH Electronics, Inc. 402-734-4900 pkavan(a)gmail.com ***************************************

1 3

Re: [alsa-devel] OSS/4Front
by Ash Willis 21 Jun '07

21 Jun '07

Hi Clemens, > You could compare <http://manuals.opensound.com/devlists/Linux.html> > with ALSA's sound card matrix, but the latter tends to be out of date. > Yeah, that thing is oooooold. Hopefully the new wiki on't be too bad. > > With the recent open sourcing of OSS, it would be nice to port code > > to ALSA for devices that are only currently covered by OSS. > > AFAICS all devices supported by the open-source OSS are also supported > by ALSA. > Ah, looks can be deceiving. Although both systems have 'geode' support, it seems that the OSS driver supports the CS5530 VSA2 and the SC1200. Also, there's an open bug for the Neomagic 256 driver, which may have a solution hiding away in OSS somewhere (someone with the hardware is hopefully going to help me look into that). There's a couple of things right off the bat and I don't know ALSA very well at all compared to most of you. And yeah, I know this stuff isn't in great demand, but it'd be nice if people weren't able to say that OSS can do XYZ and ALSA can't. Ash -- Get a Free E-mail Account at Mail.com! Choose From 100+ Personalized Domains Visit http://www.mail.com today

1 0

[alsa-devel] OSS/4Front
by Ash Willis 21 Jun '07

21 Jun '07

Hi, Does anyone know if there's any kind of list showing a comparison of hardware support between ALSA and OSS/4Front? With the recent open sourcing of OSS, it would be nice to port code to ALSA for devices that are only currently covered by OSS. There has to be at least a few devices that we can grab support for, right? It may at least provide us with insight into a few bugfixes. Ash -- Get a Free E-mail Account at Mail.com! Choose From 100+ Personalized Domains Visit http://www.mail.com today

4 3

[alsa-devel] Yamaha Cards
by derek＠darlingsong.net 21 Jun '07

21 Jun '07

Hi all, first post for me. I have a Yamaha DS2416 mixer card and Yamaha SW1000XG sound card that I would like to use onLinux (Fedora 6). I have used them on the "other" OS, along with ProTools, etc. Does anyone know if Linux drivers are available? I have looked around, and it seems not to be the case. any help would bve appreciated. Derekd Vancouver, BC

2 1

[alsa-devel] No time for cs4624
by chris＠idlelion.net 21 Jun '07

21 Jun '07

I really wanted to work on the cs4624 suspend resume bug (#305), but there is no time, especially given the lack of technical information. I'm wondering if I were to lend or give a laptop that exhibits the problem to one of you alsa developers, if that would be useful and provide some impetus to fix the bug, or if it would just be a big pain? Opinions? Chris

1 0

[alsa-devel] [1/2] 2.6.22-rc5: known regressions
by Michal Piotrowski 21 Jun '07

21 Jun '07

Hi all, Here is a list of some known regressions in 2.6.22-rc5. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Unclassified Subject : Kernel hang on CMOS_READ References : http://lkml.org/lkml/2007/6/3/138 Submitter : Rodrigo Luiz <troops.of.doom(a)gmail.com> Status : Unknown Subject : Device hang when offlining a CPU due to IRQ misrouting References : http://lkml.org/lkml/2007/5/31/419 Submitter : Darrick J. Wong <djwong(a)us.ibm.com> Handled-By : Siddha, Suresh B <suresh.b.siddha(a)intel.com> Status : problem is being debugged ALSA Subject : snd-aoa causes badness in lib/kref.c:33 References : http://bugzilla.kernel.org/show_bug.cgi?id=8513 Submitter : Ben Collins <bcollins(a)ubuntu.com> Handled-By : Takashi Iwai <tiwai(a)suse.de> Status : Unknown FS Subject : 2.6.22-rc4-git5 reiserfs: null ptr deref. References : http://lkml.org/lkml/2007/6/13/322 Submitter : Randy Dunlap <randy.dunlap(a)oracle.com> Handled-By : Vladimir V. Saveliev <vs(a)namesys.com> Status : problem is being debugged PCI Subject : PCI setup hangs on Asus Notebook (nolapic helps) References : http://lkml.org/lkml/2007/6/14/161 Submitter : Malte Cornils <malte(a)cornils.net> Status : unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/

3 5

Re: [alsa-devel] Using aplay and arecord on an ARM
by Paul Kavan 20 Jun '07

20 Jun '07

On 6/20/07, Paul Kavan <pkavan(a)gmail.com> wrote: > > Okay: > > Here is where I ran into troubles yesterday. I am working on configuring > alsa-utils. When I do: > > CC=arm-linux-gcc ./configure --target=arm-linux --with-versioned=no > --prefix=/usr --host=i686-pc-linux-gnu > > I get the error: > > grhuser@pcL7:$ CC=arm-linux-gcc ./configure --target=arm-linux > --with-versioned=no --prefix=/usr --host=i686-pc-linux-gnu > 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 i686-pc-linux-gnu-strip... no > checking for strip... 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 i686-pc-linux-gnu-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... i686-pc-linux-gnu > checking for ld used by GCC... > /home/grhuser/Linux_Builds/buildroot/build_arm/staging_dir/arm-linux-uclibc/bin/ld > checking if the linker > (/home/grhuser/Linux_Builds/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 i686-pc-linux-gnu-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. > > I know there has to be a flag or something here I need to set. Does anyone > know what that might be? > > Paul > I think what occurs here is that the configure script is using my cross-compilers and associated libs in $HOME/Linux_Builds/buildroot/build_arm/staging_dir/ while the libs are actually given in $HOME/Linux_Builds/buildroot/build_arm/root/usr/lib/ I am looking at the README and INSTALL and do not see a solution to this. Does anyone have a solution to this? Thanks. Paul

4 11

[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

2 1

[alsa-devel] Output levels on SBLive! 5.1 on ALSA vs WIndows
by ChernYue Kwok 20 Jun '07

20 Jun '07

Hello, I am using an SBLive! 5.1 sound card (emu10k1 chipset) with 6 channel output. Due to the nature of my work, I need to be able to play sound through all 6 channels at the same output level to an amplifier. Using Linux and the emu10k1 ALSA driver, I measured output voltage levels on an oscilloscope while playing a sine wave on all 6 channels, and I got three different output voltage amplitudes for the front, rear and center/subwoofer channels. Repeating the same test with the same card on WIndows using the Creative SBLive drivers from their website, I am able to get the same output voltage amplitude on all 6 channels. For both tests, all output levels in the relevant mixers were set to their maximum levels. I would like to know if this output normalizing 'feature' of the SBLive Windows driver can be found in the emu10k1 ALSA driver, or in any other ALSA driver. Failing that, is there any other solution to set output levels in the driver, or am I doomed to twiddle in alsamixer to get the output levels that I want? Thanks in advance.

2 3

[alsa-devel] Using aplay and arecord on an ARM
by Paul Kavan 20 Jun '07

20 Jun '07

Liam: I have managed to get the alsa-libs and aplay, arecord, and speaker-test on my board, but I am unsure how to get them to play. I have tried making the device nodes and am using a simple alsa.conf, but still no joy. I am sure there is something simple I am missing. Trying to find some documentation on this. I am assuming there is some disconnect between the interface and my conf file. I have my alsa.conf file in /usr/share/alsa/ and it is: pcm.!default { type hw card 0 } pcm.hw { type hw card 0 device 0 subdevice 0 } ctl.!default { type hw card 0 } ctl.hw { type hw card 0 } ctl.w6811 { type hw card 0 } pcm.w6811 { type hw card 0 device 0 subdevice 0 } ctl.!default = ctl.w6811 pcm.!default = pcm.w6811 ctl.hw { @args[ CARD ] @args.CARD { type string default "0" } type hw card $CARD } pcm.hw { @args[ CARD DEV SUBDEV ] @args.CARD { type string default "0" } @args.DEV { type integer default 0 } @args.SUBDEV { type integer default 0 } type hw card $CARD device $DEV subdevice $SUBDEV } I have some /proc/ entries: /proc/asound $ ls GRHEKW6811 cards pcm version card0 devices timers /proc/asound $ cat cards 0 [GRHEKW6811 ]: W6811 - GRH_EK_W6811 GRH_EK_W6811 (W6811) /proc/asound $ cat devices 0: [ 0] : control 16: [ 0- 0]: digital audio playback 24: [ 0- 0]: digital audio capture 33: : timer /proc/asound $ cat pcm 00-00: W6811 W6811-PCM-0 : : playback 1 : capture 1 /proc/asound $ cat timers G0: system timer : 10000.000us (10000000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE /proc/asound $ cat version Advanced Linux Sound Architecture Driver Version 1.0.14rc4 (Wed May 09 09:51:39. Now, into GRHEKW6811 (which takes me to card0) I get a pcm0c and pcm0p directory. Using cat info, I get: /proc/asound/card0/pcm0c $ cat info card: 0 device: 0 subdevice: 0 stream: CAPTURE id: W6811 W6811-PCM-0 name: subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 1 /proc/asound/card0/pcm0c $ cd ../pcm0p/ /proc/asound/card0/pcm0p $ cat info card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: W6811 W6811-PCM-0 name: subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 1 I then did: mknod -m 666 /dev/snd/pcm0p c 116 0 mknod -m 666 /dev/snd/pcm0c c 116 0 However, when I try speaker-test, I get: /usr/lib/bin $ ./speaker-test -D pcm0p speaker-test 1.0.14 Playback device is pcm0p Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise ALSA lib pcm.c:2144:(snd_pcm_open_noupdate) Unknown PCM pcm0p Playback open error: -2,No such file or directory Same for default: /usr/lib/bin $ ./speaker-test -D default speaker-test 1.0.14 Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise ALSA lib pcm.c:2144:(snd_pcm_open_noupdate) Unknown PCM default Playback open error: -2,No such file or directory When I try aplay -l and arecord -l, I get: /usr/lib/bin $ ./aplay -l aplay: device_list:204: no soundcards found... /usr/lib/bin $ ./arecord -l arecord: device_list:204: no soundcards found... I am at a loss here. Anyone have any advice, pointers, tips, etc...... Thanks. Paul -- *************************************** Paul David Kavan Project Engineer GRH Electronics, Inc. 402-734-4900 pkavan(a)gmail.com ***************************************

4 9

[alsa-devel] ALSA always writes _whole_ periods, right?
by Joachim Förster 20 Jun '07

20 Jun '07

Hi ALSA devs, I have a quick question regarding the filling of the usual ring buffer in RAM (used by sound controllers via DMA), just to be really sure: Is it true, that ALSA always writes (via mmap'ing) _whole_ periods? I took snd-dummy and modified it to use "ack()" method and tried to confirm, if the above is true _without_ memory mapping (classical read/write). It seem's to be true, ALSA is "filling up" the last (not always complete) period - e.g. if the played wav file is not a multiple of periodsize in length. But well, with mmap, I cannot see the copying action (done by ALSA library, right?) ... so, thus my question ;-) . Thanks, Joachim

2 3

[alsa-devel] Surround problems with cs46xx
by Vasilis Manwlopoulos 20 Jun '07

20 Jun '07

Hi, Sorry for bothering the list again, but I have major problems with the surround 5.1 sound. I have manually compiled/installed th latest alsa-1.0.14 drivers but nothing improved. I am using Ubuntu 7.04 and my soundcard is the Hercules Fortissimo III. This is, as far as I know by reading on Internet, supported by the module snd-cs46xx in ALSA. I have enabled the surround sound by creating the following .asoundrc file. pcm.!default { type plug slave.pcm "surround51" slave.channels 6 route_policy duplicate } The problem is that sound pauses whenever I try to do something "heavy" such as opening a new firefox window or generally another app. Also, there are delays and echo between the front and the rear speakers from time to time. I think that the problem is that, this alsa setup(meaning surround5.1 and the specific soundcard) places a heavy load on the cpu. There are 99% cpu usage times when the only thing active is a player playing a "normal bitrate" mp3. When I delete the .asoundrc file and I switch to default stereo sound using only the 2 front speakers the problems disappear. Can anyone suggest anything about this? Thanks in Advance V.Manolopoulos

3 3

[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

[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

[alsa-devel] Alsa mixer interface limitations?
by Ctirad Fertr 17 Jun '07

17 Jun '07

Hello! I'm currently in phase of adding support for higher sample rates into e-mu 1212m/1820m driver. These cards have a lot of physical inputs and outputs and also a bunch of internal buses used for capture, playback and internal routing between physical inputs and outputs. Both physical I/O and internal buses are shown in alsamixer, so one can set routing easily. It's a lot of switches, anyway. The card has three modes. The standard (or "single speed") mode is the only mode currently supported in emu10k driver. It is capable of 44.1/48kHz sample rate only. If we need higher sample rates, we have to switch the card into either "double speed" (for 88.2/96kHz) or "quadruple speed" (for 176.4/192kHz) mode. The problem is that the number of inputs, outputs and especially internal buses significantly changes at higher speed modes. The reason is that internal buses are 44.1/48kHz only and thus we must use two (or four) of them per channel. Also some physical I/O ports disappear at double and quadruple speeds (e.g. ADAT has 4 channles at 96k and 2 at 192k, S/PDIF is completely disabled at 192k). The question is how to deal with that in alsamixer? IMHO the best way would be to change the number of switches in alsamixer on the fly. Unfortunatelly, I'm afraid it's impossible. Another way would be to make a particular swiches inactive, though I don't know if it is a good idea and it wold require a lot of code anyway. Any ideas? Please help! Ctirad

1 0

[alsa-devel] Got microphone working with SigmaTel STAC 9221 A1 on a Dell XPS M1210
by Eran Guendelman 17 Jun '07

17 Jun '07

I installed SuSE 10.2 on my new XPS M1210 laptop and found that the microphone was not working (headphones and internal speakers worked fine). I eventually got it working, and wanted to write an email describing how I did this. The two main important steps (which I will describe in more detail below) were: - Changing the default pin configurations ref922x_pin_configs in patch_sigmatel.c to values that were based on the windows driver's INI file but with one important tweak. - Running the driver using the "model=ref" parameter so that the above modified pin configurations are used. Note that it could be that my solution is overkill and there's actually a way to get this working with the unmodified alsa drivers... But I did not find any such solutions (e.g. I've tried setting "model=ref", "model=3stack", "model=5stack", but none of those fixed the microphone). In general, it seems that the solutions proposed on the internet to getting the SigmaTel codec working are very dependent on the exact type of system you've got... So this will likely only work for a Dell XPS M1210. Here is some more system info: "lspci -v" gives this as my audio card: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Subsystem: Dell Unknown device 01d7 Flags: bus master, fast devsel, latency 0, IRQ 233 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) My card uses the snd_hda_intel module, and the codec type (given by "cat /proc/asound/card0/codec#0") gives this information at the top: Codec: SigmaTel STAC9221 A1 Address: 0 Vendor Id: 0x83847680 Subsystem Id: 0x102801d7 Revision Id: 0x103601 So here's what I did (taking many days and many wrong steps before arriving at this solution): - I have a dual-boot system and installed the official DELL drivers for the sound card in Windows XP. My goal was to find which INI file corresponded to my installed sound card, so I did the following: - Using Windows device manager, I looked at the properties for the SigmaTel codec driver and found that one of the property items had a string that included the substring VEN_8384&DEV_7680&SUBSYS_102801D7 - The self-extracting DELL driver extracted files into c:\dell\drivers\r122161, and in the wdm subdirectory I searched for the above string and found that the files 92xxM.INI, Sthda.ini, and sthda64.ini all contained the above string and also had the suffix =92xxM8-2.ini appended to it. This led me to deduce that the relevant file was 92xxm8-2.ini - This is an excerpt from 92xxm8-2.ini: [HKR\Settings\pin\0A] CfgDflt = dword: 0x0221121E AltCfg = hex: 20,12,11,02 Action = hex: 80,00,87,00,81,0D [HKR\Settings\pin\0B] CfgDflt = dword: 0x408103FF [HKR\Settings\pin\0C] CfgDflt = dword: 0x0281123E AltCfg = hex: 22,12,11,02,30,12,A1,02 Bias = hex: FF,04,02 Action: hex: 0A, 0C [HKR\Settings\pin\0D] CfgDflt = dword: 0x90100310 [HKR\Settings\pin\0E] CfgDflt = dword: 0x408003F1 [HKR\Settings\pin\0F] CfgDflt = dword: 0x0221122F AltCfg = hex: 21,12,11,02 Action = hex: 80,00,87,00,81,0D [HKR\Settings\pin\10] CfgDflt = dword: 0x03451340 [HKR\Settings\pin\11] CfgDflt = dword: 0x40C003F2 [HKR\Settings\pin\15] CfgDflt = dword: 0x50A003F3 [HKR\Settings\pin\1B] CfgDflt = dword: 0x405003F4 - This will be useful later... Now back to linux. - I downloaded latest alsa-driver package (version 1.0.14). - I edited alsa-kernel/pci/hda/patch_sigmatel.c, and replaced the contents of the ref922x_pin_configs array with the default pin configurations found in the INI file above WITH ONE IMPORTANT TWEAK. Specifically, this is my new array: static unsigned int ref922x_pin_configs[10] = { 0x0221121E, 0x408103FF, 0x02A1123E, 0x90100310, 0x408003F1, 0x0221122F, 0x03451340, 0x40C003F2, 0x50A003F3, 0x405003F4 }; - If you compare these numbers to the CfgDflt values from the Windows INI file above, you'll see that they match except that for the third value, instead of 0x281123E I use 0x2A1123E Here's why: I figured out that pin complex 0x0c was my microphone jack (the right-most of the three jacks in the front of my laptop). The 0x281123E configuration indicates a "Line In at Ext Front" jack... Indeed, this jack can serve as a line in or mic in or even I believe as output to rear speakers. But designating it as Line In by default seems to confuse the patch_sigmatel.c routines that set up the codec... They assume it's just a line in jack and do not mark it as potential microphone input. Changing the 8 to an A in the value designates it as "Mic at Ext Front", so the codec recognizes it as the microphone input for the card. What ends up happening is that as a microphone input, the Pin-ctls for the pin gets assigned to 0x24, whereas when it just thinks it's a Line In the Pin-ctls gets set to 0x20. Both designate an input, but the 4 in 0x24 seems to also give it a Voltage Reference Signal which I guess is important for microphone inputs. (I don't fully understand most of this stuff... I've just been reading up about the HD Audio specs over the last few days). - Build and install drivers using "./configure --with-cards=hda-intel --with-sequencer=yes; make; make install" - Make sure the snd_hda_intel gets loaded with model=ref option. You need to specify the ref model so that the pin configurations set up above are used. Of course, the right way to do this would be to make a whole new model, but I didn't bother doing that in my quick hack. Anyway, in SuSE 10.2 you can set the model through YaST, or you can manually edit /etc/modprobe.d/sound and make sure model=ref is listed as one of the options in the "options snd-hda-intel . . ." line - Reset sound drivers. (Best to just reset computer, but on SuSE 10.2 it usually works if I do "/etc/init.d/alsasound reset") - And that's basically it... In the mixer (e.g. alsamixer) it's important to make sure the Capture channel has "CAPTUR" on and that it's at a high value, and that the Mux is at its max too. It does not allow me to change "Input Source", but that's fine because the above essentially hard codes it to be Front Mic which is what I wanted. I've attached the contents of /proc/asound/card0/codec#0 in its good (mic working) state. The final path is 0x0c (mic) -> 0x12 (audio selector, stereo amp-out; Mux in the mixer) -> 0x17 (audio selector, stereo amp-in; Capture in the mixer) -> 0x06 (audio input) After searching on the internet, reading about HD Audio, and poking around the driver code, I do have a number of lingering questions I would be happy to have answered: - Why does patch_sigmatel.c "fix" mux capture levels to 2? The Mux (0x12) ends up in the path from the mic in jack to the audio in, so is it supposed to act as a Mic Boost or something? - I noticed my headphone jacks (0x0a, 0x0f) have Pin-ctls set at 0xc0 which is OUT HP (i.e. uses a low impedance amplifier for headphone output). Would it damage my sound card or speakers if I connected these jacks to powered speakers or to an audio receiver (i.e. more traditionally connected to a Line Out)? - Does the snd_hda_intel driver currently (or will it eventually) support dynamic switching so I can switch from the Mic In to Line In or to Rear Speakers Out, etc, just like in the Windows driver? - Some solutions on the internet talked about creating an .asoundrc file to get the codec working... I don't understand what that file is for and whether I need to tweak it at all... But since I have a working solution without the file I guess I'm fine? Thanks, Eran. P.S. Not subscribed, so please respond by email... Codec: SigmaTel STAC9221 A1 Address: 0 Vendor Id: 0x83847680 Subsystem Id: 0x102801d7 Revision Id: 0x103601 Default PCM: rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: ofs=0x00, nsteps=0x0e, stepsize=0x05, mute=1 Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1 Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0x6b 0x6b] Power: 0x0 Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0x66 0x6d] Power: 0x0 Node 0x06 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x17 Node 0x07 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x18 Node 0x08 [Audio Output] wcaps 0x40211: Stereo Digital PCM: rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Node 0x09 [Audio Input] wcaps 0x140311: Stereo Digital PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Connection: 1 0x11 Node 0x0a [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x0221121e: [Jack] HP Out at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0xc0: OUT HP Connection: 1 0x02 Node 0x0b [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x408103ff: [N/A] Line In at Ext N/A Conn = 1/8, Color = Unknown Pin-ctls: 0x20: IN Connection: 1 0x04 Node 0x0c [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x02a1123e: [Jack] Mic at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0x24: IN Connection: 1 0x03 Node 0x0d [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x90100310: [Fixed] Speaker at Int N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x40: OUT Connection: 1 0x02 Node 0x0e [Pin Complex] wcaps 0x400081: Stereo Pincap 0x0824: IN Detect Pin Default 0x408003f1: [N/A] Line In at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x20: IN Node 0x0f [Pin Complex] wcaps 0x400181: Stereo Pincap 0x0837: IN OUT Detect Pin Default 0x0221122f: [Jack] HP Out at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0xc0: OUT HP Connection: 1 0x05 Node 0x10 [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x0810: OUT Pin Default 0x03451340: [Jack] SPDIF Out at Ext Left Conn = Optical, Color = Black Pin-ctls: 0x40: OUT Connection: 3 0x08* 0x17 0x19 Node 0x11 [Pin Complex] wcaps 0x430681: Stereo Digital Pincap 0x0810024: IN EAPD Detect Pin Default 0x40c003f2: [N/A] SPDIF In at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Power: 0x0 Node 0x12 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x02 0x02] Connection: 7 0x0e 0x15 0x0f 0x0b 0x0c* 0x0d 0x0a Node 0x13 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00] Connection: 7 0x0e 0x15 0x0f 0x0b 0x0c* 0x0d 0x0a Node 0x14 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0 Amp-Out vals: [0x00] Node 0x15 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: IN Pin Default 0x50a003f3: [N/A] Mic at Int N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Node 0x16 [Volume Knob Widget] wcaps 0x600000: Mono Node 0x17 [Audio Selector] wcaps 0x300903: Stereo Amp-In Amp-In caps: N/A Amp-In vals: [0x0e 0x0e] Connection: 1 0x12 Node 0x18 [Audio Selector] wcaps 0x300903: Stereo Amp-In Amp-In caps: N/A Amp-In vals: [0x80 0x80] Connection: 1 0x13 Node 0x19 [Vendor Defined Widget] wcaps 0xf30201: Stereo Digital Node 0x1a [Audio Output] wcaps 0x30201: Stereo Digital Node 0x1b [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x0810: OUT Pin Default 0x405003f4: [N/A] Digital Out at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Connection: 1 0x1a

2 5

[alsa-devel] Sound problem in Toshiba
by Furkan Cayci 16 Jun '07

16 Jun '07

Hi, I am using Ubuntu 7.04. After installing Ubuntu, I could't hear any sound from my Toshiba Satellite A205-S4577, so I did the things related with this article; http://pastebin.ca/522731 After restarting laptop, I didn't take any errors, but there was no sound again. Then I realized the output of the dmesg. $ dmesg|grep alsa [ 18.948000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2339: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 18.948000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2343: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 18.948000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2347: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 18.948000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2355: inputs: mic=0x19, fmic=0x18, line=0x0, fline=0x0, cd=0x0, aux=0x0 [ 19.672000] ALSA /home/leonetix/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:244: si3054: cannot initialize. EXT MID = 0000 [ 19.680000] ALSA /home/leonetix/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:256: Link Frame Detect(FDT) is not ready (line status: 0000) [ 33.572000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:1810: hda_codec: model 'auto' is selected [ 33.620000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2339: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 33.620000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2343: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 33.620000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2347: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 33.620000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2355: inputs: mic=0x19, fmic=0x18, line=0x0, fline=0x0, cd=0x0, aux=0x0 [ 34.360000] ALSA /home/leonetix/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:244: si3054: cannot initialize. EXT MID = 0000 [ 34.368000] ALSA /home/leonetix/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:256: Link Frame Detect(FDT) is not ready (line status: 0000) ------------------------- So, there is something wrong, but I didn't understand and I was wondering if you could solve or show a way to do it. Also, here is the output of lcpci -v "00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) Subsystem: Toshiba America Info Systems Unknown device ff10 Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at f0b40000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0" Thanks for your help, Furkan

1 0

[alsa-devel] Software mixing according to priority of streams
by Nobin Mathew 15 Jun '07

15 Jun '07

Hi, Is there any sound mixer which does mixing according to priority of streams, i.e. i will have streams with different priority like audio stream , bluettoth sco stream, gps navigation sound stream etc. Since my hardware will not support hardware mixing i will have to do this mixing in software. If bluetooth sco stream is opened while audio stream is playing then the application (sound server) should stop the playback of audio stream and should start playback of bletooth sco stream. priority order is bluettoth sco > gps navigation sound > audio Can dmix and Jack server the purpose. Nobin Mathew

3 8

[alsa-devel] [RFC][ASoC] New device/driver arch
by Liam Girdwood 15 Jun '07

15 Jun '07

I'd like to gather some feedback on some changes I've been making to ASoC recently. The changes were made to fit in better with the PPC device tree and to help with easier porting to new platforms. They were also introduced to make dealing with device probe errors (e.g. I2C probe failure) a little easier. The largest change is the introduction of an ASoC bus device. All component drivers (that is, codec, codec DAI, CPU DAI, and DMA PCM drivers) register with this bus. This should simplify device registration and hopefully better fit in with the PPC model. A component driver now typically consists of the standard driver ops and a set of ASoC/ALSA ops to configure audio. The new soc.h shows this here :- http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-as… Example component drivers are here :- I2S http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-as… DMA http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-as… WM8753 Codec http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-as… Another major change is that there is no more snd_dai_link (structure that connected codec <--> CPU). This has been replaced by an ASoC PCM device that describes each PCM device in the machine. This new ASoC PCM device has it's own driver and registers with the bus (like the others). This allows an ASoC PCM driver to be defined like :- static struct snd_soc_device_driver hifi_pcm_drv = { .type = SND_SOC_BUS_TYPE_PCM, .driver = { .name = "mainstone-hifi-pcm", .owner = THIS_MODULE, .probe = hifi_pcm_probe, .remove = hifi_pcm_remove, }, .components = { .cpu_dai = pxa2xx_i2s, .codec = wm8753_codec, .codec_dai = wm8753_hifi_dai, .platform = pxa2xx_pcm, }, }; This now shows each component within the driver structure. The snd_soc_machine driver has changed and can now contain numerous ASoC PCM devices. It is now a platform driver. Example machine driver for Mainstone with WM8753 is here :- http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-as… The machine driver now also does the I2C/SPI probing (instead of the codec) and also does any codec IO (to better support multiple controllers). Fwiw, I've not tested any of this code atm. I plan to start this tomorrow on pxa2xx and i.MX31 and would like to get some feedback before porting remaining platforms and codecs over. Liam

4 6

[alsa-devel] Documentation for params_xxx() macros?
by Timur Tabi 14 Jun '07

14 Jun '07

Is there documentation that describes each of the params_xxx() macros? If not, then which macro tells me how many periods there are? Is it params_periods()? -- Timur Tabi Linux Kernel Developer @ Freescale

1 0

[alsa-devel] aplay hangs with execve("/build/bin/aplay", ["aplay"], [/* 8 vars */
by Pharaoh . 14 Jun '07

14 Jun '07

Hi I am using alsa lib and alsa utils 1.0.14 on my omap based board. When I try to test my my alsa driver using aplay it just hangs at the very first step. The strace output shows nothing else except the following line, execve("/build/bin/aplay", ["aplay"], [/* 8 vars */ What I am missing?

1 0

[alsa-devel] Drivers for M-Audio Firewire 410
by Cédric 14 Jun '07

14 Jun '07

Hello, Im a french user of Linux (Ubuntu Studio 7.04) and cant install my new hardware (M-Audio Firewire 410). Ive send a mail to the M-Audios technical support, but they have no solution. They recommended me to contact yourself. Could you help me for this problem. Do you need more informations about my computer hardware ? Syncerly. Cédric

2 1

[alsa-devel] [PATCH]is_power_of_2-sound/pcm_params.h
by vignesh babu 14 Jun '07

14 Jun '07

Replacing (n & (n-1)) in the context of power of 2 checks with is_power_of_2 Signed-off-by: vignesh babu <vignesh.babu(a)wipro.com> --- diff --git a/include/sound/pcm_params.h b/include/sound/pcm_params.h index 85cf1cf..dee298e 100644 --- a/include/sound/pcm_params.h +++ b/include/sound/pcm_params.h @@ -21,6 +21,7 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * */ +#include <linux/log2.h> int snd_pcm_hw_param_first(struct snd_pcm_substream *pcm, struct snd_pcm_hw_params *params, @@ -170,7 +171,7 @@ static inline int snd_mask_single(const struct snd_mask *mask) for (i = 0; i < SNDRV_MASK_SIZE; i++) { if (! mask->bits[i]) continue; - if (mask->bits[i] & (mask->bits[i] - 1)) + if (!is_power_of_2(mask->bits[i])) return 0; if (c) return 0; -- Vignesh Babu BM _____________________________________________________________ "Why is it that every time I'm with you, makes me believe in magic?" The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

1 0

[alsa-devel] [PATCH] Fix build error with strict mm checking
by Martin Habets 13 Jun '07

13 Jun '07

Turning on STRICT_MM_TYPECHECKS in include/asm/page.h causes a build error for sparc32. This patch against 2.6.21 fixes this. Martin Signed-off-by: Martin Habets <errandir_news(a)mph.eclipse.co.uk> --- --- linux/sound/core/sgbuf.c.orig 2007-06-06 23:53:34.000000000 +0100 +++ linux/sound/core/sgbuf.c 2007-06-06 23:54:45.000000000 +0100 @@ -96,7 +96,7 @@ void *snd_malloc_sgbuf_pages(struct devi } sgbuf->size = size; - dmab->area = vmap(sgbuf->page_table, sgbuf->pages, VM_MAP, PAGE_KERNEL); + dmab->area = vmap(sgbuf->page_table, sgbuf->pages, VM_MAP, __pgprot(PAGE_KERNEL)); if (! dmab->area) goto _failed; return dmab->area;

2 1

[alsa-devel] Trouble understanding ALSA's DMA buffers
by Timur Tabi 12 Jun '07

12 Jun '07

I'm writing an ALSA SOC driver for an I2S-based device, and I'm having a really hard time understanding how ALSA uses the DMA buffers. And yes, I've read the documentation and studied some sample source code. I used to write audio drivers for a living, but that was many years ago, and it wasn't for Linux. Perhaps the concepts in my head are outdated, but I just don't see enough explanation as to how DMA buffers are supposed to work. Back then, audio drivers used "ping pong" DMA buffers. A single DMA buffer is allocated, and the audio hardware is programmed to read from that buffer in a loop. That is, it would automatically restart reading from the beginning of the buffer without any reprogramming. The hardware would also be programmed to issue an interrupt when it got to the end of the buffer, and when it got to the half-way point. To start playback, you first filled the whole buffer with audio data, and then told the hardware to start playing. After the hardware got to the half-way point, it would issue an interrupt. You would then tell the OS you need more data, and you'd get it. You then copy that data into the first half of the buffer *while* the hardware was playing the second half. Later, the hardware would interrupt you when it got to the end of the buffer. You'd then copy more data to the 2nd half while the hardware is playing the first half. And so - hardware plays one half while you copy data to the other half. Hence, "ping pong". So how do I implement this in ALSA? The "Writing an ALSA Driver" document doesn't even contain the words "ping" or "pong". -- Timur Tabi Linux Kernel Developer @ Freescale

4 6

[alsa-devel] [ASoC] bug in soc_pcm_open
by Matthieu CASTET 12 Jun '07

12 Jun '07

Hi, it seems there is a bug in soc_pcm_open. In some case [1] we are in a error path, but we don't set the ret return value. This cause bug/crash from alsa core. Thanks Matthieu [1]http://hg-mirror.alsa-project.org/alsa-kernel/file/38926de0e79c/soc/soc-c… if (!runtime->hw.rates) { 218 printk(KERN_ERR "asoc: %s <-> %s No matching rates\n", 219 codec_dai->name, cpu_dai->name); 220 goto machine_err; 221 } 222 if (!runtime->hw.formats) { 223 printk(KERN_ERR "asoc: %s <-> %s No matching formats\n", 224 codec_dai->name, cpu_dai->name); 225 goto machine_err; 226 } 227 if (!runtime->hw.channels_min || !runtime->hw.channels_max) { 228 printk(KERN_ERR "asoc: %s <-> %s No matching channels\n", 229 codec_dai->name, cpu_dai->name); 230 goto machine_err; 231 }

4 4

[alsa-devel] Realtek 268
by Steven Zakulec 12 Jun '07

12 Jun '07

I have tried the current (from about 6 hours ago) drivers+lib from the HG repository. My card is now labelled as an ALC 268, and shows me what appears to be a correct number of options in the mixer. Unfortunately, I still get no sound. I've compiled the driver with --debug=full, and the lib with the debug. The following is from dmesg when I removed the old snd-hda-intel module, did a make install, then did modprobe snd-hda-intel: (I cleared out dmesg before I did the modprobe) [ 1473.892000] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 21 [ 1473.892000] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 1474.092000] hda_codec: Unknown model for ALC268, trying auto-probe from BIOS... [ 1474.140000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/hda_codec.c:2339: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 1474.140000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/hda_codec.c:2343: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 1474.140000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/hda_codec.c:2347: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 1474.140000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/hda_codec.c:2355: inputs: mic=0x19, fmic=0x18, line=0x0, fline=0x0, cd=0x0, aux=0x0 [ 1474.864000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:244: si3054: cannot initialize. EXT MID = 0000 [ 1474.872000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:256: Link Frame Detect(FDT) is not ready (line status: 0000) My /proc/asound/card0/codeco#0 is as follows: cat /proc/asound/card0/codec#0 Codec: Realtek ALC268 Address: 0 Vendor Id: 0x10ec0268 Subsystem Id: 0x1179ff10 Revision Id: 0x100003 Default PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A Node 0x02 [Audio Output] wcaps 0x1d: Stereo Amp-Out Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x00 0x00] PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x03 [Audio Output] wcaps 0x1d: Stereo Amp-Out Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x40 0x40] PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x04 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x05 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x06 [Audio Output] wcaps 0x211: Stereo Digital PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0x1e]: 16 20 24 32 formats [0x1]: PCM Node 0x07 [Audio Input] wcaps 0x100111: Stereo PCM: rates [0x160]: 44100 48000 96000 bits [0x6]: 16 20 formats [0x1]: PCM Connection: 1 0x24 Node 0x08 [Audio Input] wcaps 0x100111: Stereo PCM: rates [0x160]: 44100 48000 96000 bits [0x6]: 16 20 formats [0x1]: PCM Connection: 1 0x23 Node 0x09 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0a [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0b [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0c [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0d [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0e [Audio Mixer] wcaps 0x20010a: Mono Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00] Connection: 1 0x02 Node 0x0f [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x80 0x80] Connection: 2 0x02 0x1d Node 0x10 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x80 0x80] [0x80 0x80] Connection: 3 0x03 0x1d 0x02 Node 0x11 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x12 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x00: Node 0x13 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x00: Node 0x14 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x081003c: IN OUT HP EAPD Detect Pin Default 0x99130110: [Fixed] Speaker at Int ATAPI Conn = ATAPI, Color = Unknown Pin-ctls: 0x40: OUT Connection: 1 0x0f Node 0x15 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x081003c: IN OUT HP EAPD Detect Pin Default 0x02211020: [Jack] HP Out at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0xc0: OUT HP Connection: 1 0x10 Node 0x16 [Pin Complex] wcaps 0x40010c: Mono Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80] Pincap 0x0810: OUT Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x00: Connection: 1 0x0e Node 0x17 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x083734: IN OUT Detect Pin Default 0x02a11830: [Jack] Mic at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0x24: IN Connection: 1 0x02 Node 0x19 [Pin Complex] wcaps 0x40008b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0 Amp-In vals: Pincap 0x083724: IN Detect Pin Default 0x99a30940: [Fixed] Mic at Int ATAPI Conn = ATAPI, Color = Unknown Pin-ctls: 0x24: IN Node 0x1a [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x083734: IN OUT Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x20: IN Connection: 1 0x02 Node 0x1b [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x1c [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x20: IN Node 0x1d [Pin Complex] wcaps 0x400000: Mono Pincap 0x0820: IN Pin Default 0x4015812d: [N/A] Speaker at Ext N/A Conn = Optical, Color = Purple Pin-ctls: 0x20: IN Node 0x1e [Pin Complex] wcaps 0x400380: Mono Digital Pincap 0x0810: OUT Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x40: OUT Connection: 1 0x06 Node 0x1f [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono Node 0x21 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x22 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x23 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x81 0x81] Connection: 7 0x18 0x19 0x1a 0x1c 0x14 0x15* 0x12 Node 0x24 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x81 0x81] Connection: 7 0x18 0x19 0x1a 0x1c 0x14* 0x15 0x13 Output for the audio device (lspci -vvv) below: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) Subsystem: Toshiba America Info Systems Unknown device ff10 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 21 Region 0: Memory at f0b40000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [70] Express Unknown type IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled CommClk- ExtSynch- Link: Speed unknown, Width x0

2 1

[alsa-devel] alsa on Atmel at91
by Michel Benoit 12 Jun '07

12 Jun '07

Hello I am trying to run alsa on an ARM based target AT91SAM9260 based board. The cpu is connected over i2s (atmel's ssc) to a PCM1725 chip. I modifed the AT73C213 driver available in the latest experimental patches from www.at91.com to behave correctly for the PCM1725 chip. Basically all I have done is remove the spi communication with the AT73C213 that regulates the sound output volume. The PCM chip has no such volume control and I use the i2s interface setup as is to send sample data. I cross compile alsa lib and run the program test/pcm_min which generates as expected random noise on the speaker output. However when I try to run test/pcm I get a divide by zero floating point exception because the library returns a period_size of 0. This despite the fact that the period time is set to 100000 and buffer time is set to 500000. I enabled some debug info in the library and I see the following data dumped to the console. ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 48000 PERIOD_TIME: (20354 20355) PERIOD_SIZE: 977 PERIOD_BYTES: 3908 PERIODS: (4 5) BUFFER_TIME: (81479 81480) BUFFER_SIZE: 3911 BUFFER_BYTES: 15644 TICK_TIME: 10000 How is it possible that the following code from test/pcm.c err = snd_pcm_hw_params_set_period_time_near(handle, params, &period_time, &dir); if (err < 0) { printf("Unable to set period time %i for playback: %s\n", period_time, snd_strerror(err)); return err; } err = snd_pcm_hw_params_get_period_size(params, &size, &dir); if (err < 0) { printf("Unable to get period size for playback: %s\n", snd_strerror(err)); return err; } returns a period_size of 0 when the debug output shows that the period_size has been calculated to be 977? Can it be that the driver has not initialised the alsa structures properly (the driver file is attached to this email)? Have I mucked something up by removing the spi comm. with the at73c213? Could this be due to a problem in the cross compilation of alsa-lib? I use the following configure command line: CC=arm-linux-gcc ./configure \ --host=arm-linux\ --prefix=$HOME/bsp/rootfs/buildroot/build_arm/root/usr\ --with-softfloat (note: I have also tried it without --with-softfloat) I have tried digging through the alsa lib code but it is not very clear to me where the returned value for period_size comes from. I appreciate any pointers, hints or tips that can help me to solve and/or understand this problem. Thanks in advance! Michel

5 20

[alsa-devel] Source of timing for MIDI and/or audio synchronization
by Mark Rivera 12 Jun '07

12 Jun '07

Hello (new to list), and thank you for the work you have been doing. As an end-user of the ALSA project's development, I am very grateful for being able to use softwares which provide audio functionality to Linux. I have been reading up on the docs and list archives, but I still have an open question for which I hope you can lead me to an answer. I designed and built a MIDI sequencer based around a Microchip PIC18 MCU, and used the built-in hardware timers and interrupt levels to drive the 'scheduler' for initiating MIDI output (EUSART) routines. In this same vein, I would like to write a software sequencer with as 'tight' timing as possible. So, in a similar concept for Linux - from where does the timing of audio and MIDI events come from? It occurred to me that it would be nice to have a loadable kernel module (LKM) to which userland programs could subscribe for receiving 'soft interrupts' based on some timer (cpu ticks?) so that various software could all reference the same notion of the "current time" - a sort of "master clock" with start/stop/continue as well. Does ALSA provide this functionality? Can someone point me in the right direction for learning more about this? Many thanks. Mark

3 2