Re: [Alsa-devel] EMU10K1 and the extra voice

2004-06-07 Thread Jaroslav Kysela
On Sun, 6 Jun 2004, Glenn Maynard wrote:

 On Sun, Jun 06, 2004 at 12:40:31PM +0200, Jaroslav Kysela wrote:
   Any relationship to the fact that I can only allocate 21 subdevices with
   ALSA, but 31 with DirectSound?
  
  Yes, 64 / 3 = 21 .
 
 That stinks (but if it's necessary for decent latency, which it doesn't
 get in Windows, oh well).  Shouldn't the driver report 21 substreams
 instead of 32, though?

Nope. For mono streams - 64 / 2 = 32.

Jaroslav

-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] An driver error when I using aplay!

2004-06-07 Thread Clemens Ladisch
Roc Wu wrote:
  # ./aplay -t wav -f U8 -r 22050 alarm.wav
  Playing WAVE 'alarm.wav' : Unsigned 8 bit, Rate 22050 Hz, Mono
  ALSA lib pcm_plug.c:727:(snd_pcm_plug_hw_refine_schange)
  Unable to find an usable access for 'default'
  aplay: set_params:832: Sample format non available
 
  And the kernel driver will dump out the message as below:
  Badness in aaci_pcm_close at sound/arm/aaci.c:404

This seems to be a bug in the sound driver.

However, arm/aaci.c is not part of the official ALSA distribution.
AFAIK it's a patch written by Russell King.


HTH
Clemens




---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] limits

2004-06-07 Thread Clemens Ladisch
Florin Andrei wrote:
 What's the max number of cards in a system that can be used by ALSA
 simultaneously?

8

 What's the max number of MIDI ports that's supported by ALSA?

There can be up to 8 rawmidi devices per card, but each device can
have an unlimited number of subdevices.

OSS emulation supports 2 ports per card (/dev/midi0X, /dev/amidi0X).

There can be up to 192 sequencer clients (64 each for kernel, drivers
(8*8), and applications), and each can have up to 254 ports.

 What are other similar limits?

Up to 8 playback and 8 capture PCM devices per card, with unlimited
number of subdevices.

Up to 8 sequencer queues.

 The answers to the questions above - are they in the docs?

Use the Source, Luke!  :-)


HTH
Clemens




---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] limits

2004-06-07 Thread Jaroslav Kysela
On Mon, 7 Jun 2004, Clemens Ladisch wrote:

 Florin Andrei wrote:
  What's the max number of cards in a system that can be used by ALSA
  simultaneously?
 
  The answers to the questions above - are they in the docs?
 
 Use the Source, Luke!  :-)

Note that applications shouldn't rely on these limits, because we can 
change the driver code to support more cards/devices/sequencer queues etc. 
in future.

Jaroslav

-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] An driver error when I using aplay!

2004-06-07 Thread Roc Wu
 --- Clemens Ladisch [EMAIL PROTECTED] 
Roc Wu wrote:
   # ./aplay -t wav -f U8 -r 22050 alarm.wav
   Playing WAVE 'alarm.wav' : Unsigned 8 bit, Rate
 22050 Hz, Mono
   ALSA lib
 pcm_plug.c:727:(snd_pcm_plug_hw_refine_schange)
   Unable to find an usable access for 'default'
   aplay: set_params:832: Sample format non
 available
  
   And the kernel driver will dump out the message
 as below:
   Badness in aaci_pcm_close at
 sound/arm/aaci.c:404
 
 This seems to be a bug in the sound driver.
 
 However, arm/aaci.c is not part of the official ALSA
 distribution.
 AFAIK it's a patch written by Russell King.
 
 
 HTH
 Clemens
 
Yes. Thanks for your replay. Maybe I should send the
mail to arm-linux mailist.

PS. Could you recommend some docs about the ALSA
internals and Low level drivers? There are too many
docs in the www.alsa-project.org, I am an embedded
Linux driver developer, so which one is suit for me?

Thanks a lot
Best Regards


_
Do You Yahoo!? 

http://cn.rd.yahoo.com/mail_cn/tag/10m/*http://cn.mail.yahoo.com/event/10m.html


---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] An driver error when I using aplay!

2004-06-07 Thread Russell King
On Mon, Jun 07, 2004 at 05:25:22PM +0800, Roc Wu wrote:
  --- Clemens Ladisch [EMAIL PROTECTED] µÄÕýÎÄ£º
 Roc Wu wrote:
# ./aplay -t wav -f U8 -r 22050 alarm.wav
Playing WAVE 'alarm.wav' : Unsigned 8 bit, Rate
  22050 Hz, Mono
ALSA lib
  pcm_plug.c:727:(snd_pcm_plug_hw_refine_schange)
Unable to find an usable access for 'default'
aplay: set_params:832: Sample format non
  available
   
And the kernel driver will dump out the message
  as below:
Badness in aaci_pcm_close at
  sound/arm/aaci.c:404
  
  This seems to be a bug in the sound driver.

Actually, I disagree.  It's an ALSA bug.  The warning is created if
the AACI close method is called while the DMA or IO is still running.
If DMA is still running here, we've already freed the DMA buffer, so
we're either reading from or writing to memory we don't own - which is
a major bug.

The question is therefore: why is ALSA trying to shut down and free a
device which still has DMA running?  To be more explicit, why didn't
ALSA call the trigger callback with SNDRV_PCM_TRIGGER_STOP prior to
calling the hw_free or close methods?

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
 2.6 Serial core


---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] An driver error when I using aplay!

2004-06-07 Thread Jaroslav Kysela
On Mon, 7 Jun 2004, Russell King wrote:

 Actually, I disagree.  It's an ALSA bug.  The warning is created if
 the AACI close method is called while the DMA or IO is still running.
 If DMA is still running here, we've already freed the DMA buffer, so
 we're either reading from or writing to memory we don't own - which is
 a major bug.
 
 The question is therefore: why is ALSA trying to shut down and free a
 device which still has DMA running?  To be more explicit, why didn't
 ALSA call the trigger callback with SNDRV_PCM_TRIGGER_STOP prior to
 calling the hw_free or close methods?

The midlevel calls *drop() (which must stop the running stream) and then
-hw_free and -close callbacks. I've never seen this error, so I suspect
that something else is wrong.

Could you track why snd_pcm_playback_drop() call fails in 
snd_pcm_release() for this hardware?

Jaroslav

-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


[Alsa-devel] Developer docs missing from ALSA web server - was:Re: [Alsa-devel] An driver error when I using aplay!

2004-06-07 Thread James Courtier-Dutton
Roc Wu wrote:

Unable to find an usable access for 'default'
aplay: set_params:832: Sample format non
available
Yes. Thanks for your replay. Maybe I should send the
mail to arm-linux mailist.
PS. Could you recommend some docs about the ALSA
internals and Low level drivers? There are too many
docs in the www.alsa-project.org, I am an embedded
Linux driver developer, so which one is suit for me?
Thanks a lot
Best Regards
The useful developer docs seem to have been lost off the alsa web server.
From: http://www.alsa-project.org/documentation.php3#Driver, there are 
the following broken links:
http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html
http://www.alsa-project.org/~iwai/alsa-driver-api/index.html

When you build a new alsa driver, you generally have to also create a 
/usr/share/alsa/cards/XXX  file, where XXX is the name of your driver.

The XXX comes from either: -
 strcpy(card-driver, XXX);  in your probe routine.
I think you will find the most help if you post the unfinished source 
code for your driver, so that people can look at it, and maybe suggest 
corrections for you.

The best way to test your new driver is with a test tool like 
speaker-test or pcm.

With these you can send a tone to the speakers. You can also set the 
sample rate and number of channels, so that it can test the driver, 
without needing to use plug devices initially.
E.g. If your sound card can only do 48khz stereo. Start testing it with:
speaker-test -r48000 -Dhw:0,0 -c2

plug devices tend not to work well until you have a correctly 
functioning driver.

Cheers
James
---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] An driver error when I using aplay!

2004-06-07 Thread Takashi Iwai
At Mon, 7 Jun 2004 12:43:01 +0200 (CEST),
Jaroslav wrote:
 
 On Mon, 7 Jun 2004, Russell King wrote:
 
  Actually, I disagree.  It's an ALSA bug.  The warning is created if
  the AACI close method is called while the DMA or IO is still running.
  If DMA is still running here, we've already freed the DMA buffer, so
  we're either reading from or writing to memory we don't own - which is
  a major bug.
  
  The question is therefore: why is ALSA trying to shut down and free a
  device which still has DMA running?  To be more explicit, why didn't
  ALSA call the trigger callback with SNDRV_PCM_TRIGGER_STOP prior to
  calling the hw_free or close methods?
 
 The midlevel calls *drop() (which must stop the running stream) and then
 -hw_free and -close callbacks. I've never seen this error, so I suspect
 that something else is wrong.

i guess so, too.  as you can see in the original post, the error
returned from hw_params callback (sample not available), thus it
doesn't call trigger(START) callback yet at all.

unfurtunately i can't tell any more unless i read the driver code.
where can i find the code?


Takashi


---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] An driver error when I using aplay!

2004-06-07 Thread Takashi Iwai
At Mon, 7 Jun 2004 14:08:17 +0100,
Russell King wrote:
 
 On Mon, Jun 07, 2004 at 02:45:20PM +0200, Takashi Iwai wrote:
  i guess so, too.  as you can see in the original post, the error
  returned from hw_params callback (sample not available), thus it
  doesn't call trigger(START) callback yet at all.
 
 If we never got past hw_params() then we didn't enable the IO,
 and it must be that something else in the system fiddled with
 the chip and set it incorrectly.
 
  unfurtunately i can't tell any more unless i read the driver code.
  where can i find the code?
 
 I never officially released the driver, though it was part of the
 old -rmk patches back in the 2.6.0-test era.  Where Roc has got
 the source from, and what modifications have been made is anyones
 guess.

Roc sent me the code now :)

after a quick look, it seems that txcr isn't initialized in the open
callback but only in hw_params callback (which was never called in
this case).  if my guess is correct, adding the following to
aacpi_playback_open() should fix this problem:

chan-txcr = 0;


Takashi


---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] An driver error when I using aplay!

2004-06-07 Thread Takashi Iwai
At Mon, 7 Jun 2004 14:51:13 +0100,
Russell King wrote:
 
 On Mon, Jun 07, 2004 at 03:40:23PM +0200, Takashi Iwai wrote:
  At Mon, 7 Jun 2004 14:08:17 +0100,
  Russell King wrote:
   
   On Mon, Jun 07, 2004 at 02:45:20PM +0200, Takashi Iwai wrote:
i guess so, too.  as you can see in the original post, the error
returned from hw_params callback (sample not available), thus it
doesn't call trigger(START) callback yet at all.
   
   If we never got past hw_params() then we didn't enable the IO,
   and it must be that something else in the system fiddled with
   the chip and set it incorrectly.
   
unfurtunately i can't tell any more unless i read the driver code.
where can i find the code?
   
   I never officially released the driver, though it was part of the
   old -rmk patches back in the 2.6.0-test era.  Where Roc has got
   the source from, and what modifications have been made is anyones
   guess.
  
  Roc sent me the code now :)
  
  after a quick look, it seems that txcr isn't initialized in the open
  callback but only in hw_params callback (which was never called in
  this case).
 
 Why should it be explicitly initialised?  Take a moment to consider
 what guarantees snd_card_new() gives for the allocated memory.  Yep,
 that's right - it's initialised to zero.  So, chan-txcr is already
 initialised to zero.

You're right.  The error was not txcr, but in another WARN_ON() for
checking chan-tx_substream (line 404)!  (Russell, you mislead this,
too ;)

The reason is same -- since hw_params is not called,
chan-tx_substream is not set, too.


Takashi


---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] An driver error when I using aplay!

2004-06-07 Thread James Courtier-Dutton
Russell King wrote:
But unfortunately I don't have the driver code myself to be able to
comment, so its probably been fscked.
If the code was posted publically, the author of the code would get a 
lot more useful help from more eyes.

---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


[Alsa-devel] Problems Writing a Driver for an AMD Au1000 MIPS Processor

2004-06-07 Thread Charles Eidsness
I've been trying to write an ALSA driver for the AC97 port on an 
embedded AMD au1000 MIPS processor but am having some difficulties. The 
processor's DMA controller has two buffers which automatically toggle 
back and forth once the buffer is full. My problem is that when I 
playback a wave file (just using cat xxx  /dev/dsp) it sounds choppy if 
I run the spin_unlock_irqrestore on every interrupt, it's only playing 
back half the data. But if I run the spin_unlock_irqrestore function on 
every-other interrupt and have only two periods it sounds fine. I'm 
guessing I'm handling the streaming interface with the ALSA API incorrectly.

I've attached my code and am hoping someone may be kind enough to take a 
quick look at it and let me know if anything looks incorrect. Or 
possibly point me to some documentation or another driver that may be 
useful.

Also, currently the only two devices I have are dsp and mixer, i.e. OSS 
emulation only, and I have no configuration files. The reason being that 
I would like a minimum installation but I haven't been able to find any 
documentation on what are the minimum devices / configuration files 
required. All I want is a stereo playback and single channel capture 
using an AC97 interface. Does anyone have any insite on what a minimum 
install would look like, or is there some documentation that I've missed?

Thanks!
Charles
/*
 *  Driver for AMD Au1000 MIPS Processor, AC'97 Sound Port
 *  Copyright (C) 2004 Charles Eidsness [EMAIL PROTECTED]
 *
 *   This program is free software; you can redistribute it and/or modify
 *   it under the terms of the GNU General Public License.
 * 
 * History:
 *
 * 2004-05-04 Charles Eidsness -- Original non-working verion -- based on
 *sa11xx-uda1341.c ALSA driver and the
 *au1000.c OSS driver.
 */

#include linux/ioport.h
#include linux/interrupt.h
#include sound/driver.h
#include linux/init.h
#include linux/slab.h
#include sound/core.h
#include sound/initval.h
#include sound/pcm.h
#include sound/ac97_codec.h
#include asm/mach-au1x00/au1000.h
#include asm/mach-au1x00/au1000_dma.h

MODULE_AUTHOR(Charles Eidsness [EMAIL PROTECTED]);
MODULE_DESCRIPTION(Au1000 AC'97 ALSA Driver);
MODULE_LICENSE(GPL);
MODULE_CLASSES({sound});
MODULE_DEVICES({{AMD,Au1000 AC'97}});

#define chip_t au1000_t

#define PLAYBACK 0
#define CAPTURE 1
#define AC97_SLOT_3 0x01
#define AC97_SLOT_4 0x02
#define AC97_SLOT_6 0x08

//Au1000 AC97 Port Control Reisters
typedef struct au1000_ac97_reg au1000_ac97_reg_t;
struct au1000_ac97_reg {
u32 volatile config;
u32 volatile status;
u32 volatile data;
u32 volatile cmd;
u32 volatile cntrl;
};

typedef struct audio_stream audio_stream_t;
struct audio_stream {
int dma;
snd_pcm_substream_t * substream;
spinlock_t dma_lock;
int stopped;
int period;
struct ac97_pcm *pcm;
int pcm_open_flag;
int rate_reg;
unsigned long int dma_size;
unsigned long int dma_start;
};

typedef struct snd_card_au1000 {
snd_card_t *card;

au1000_ac97_reg_t volatile *ac97_ioport;
struct resource *ac97_res_port;
spinlock_t ac97_lock;

ac97_t *ac97;
snd_pcm_t *pcm;
audio_stream_t *stream[2];  // playback  capture
} au1000_t;

static au1000_t *au1000 = NULL;

//--- Local Functions -

static void
au1000_set_ac97_slots(int xmit_slots, int recv_slots)
{
u32 volatile ac97_config = au1000-ac97_ioport-config;

spin_lock(au1000-ac97_lock);
ac97_config = ac97_config  ~AC97C_XMIT_SLOTS_MASK;
ac97_config = ac97_config  ~AC97C_RECV_SLOTS_MASK;
ac97_config |= (xmit_slots  AC97C_XMIT_SLOTS_BIT);
ac97_config |= (recv_slots  AC97C_RECV_SLOTS_BIT);
au1000-ac97_ioport-config = ac97_config;
spin_unlock(au1000-ac97_lock);

au1000-stream[PLAYBACK]-rate_reg = AC97_PCM_FRONT_DAC_RATE;
au1000-stream[CAPTURE]-rate_reg = AC97_PCM_LR_ADC_RATE;
}

static void
au1000_dma_stop(audio_stream_t *stream)
{
unsigned long   flags;
if (stream-stopped)
return;
spin_lock_irqsave(stream-dma_lock, flags);
disable_dma(stream-dma);
stream-stopped = 1;
stream-period = 0;
spin_unlock_irqrestore(stream-dma_lock, flags);
}

static void 
au1000_dma_start(audio_stream_t *stream)
{
snd_pcm_substream_t *substream = stream-substream;
snd_pcm_runtime_t *runtime = substream-runtime;

unsigned long int bufx_adr, bufy_adr, offset;
unsigned long flags;

if (!stream-stopped)
return;

stream-dma_size = frames_to_bytes(runtime, runtime-period_size);
stream-dma_start = virt_to_phys(runtime-dma_area);

offset = stream-dma_size * stream-period;
bufx_adr = stream-dma_start + 

Re: [Alsa-devel] An driver error when I using aplay!

2004-06-07 Thread Russell King
On Mon, Jun 07, 2004 at 04:18:55PM +0200, Takashi Iwai wrote:
 You're right.  The error was not txcr, but in another WARN_ON() for
 checking chan-tx_substream (line 404)!  (Russell, you mislead this,
 too ;)

Well I don't have the exact source which this guy is using, so I can
only guess.

 The reason is same -- since hw_params is not called,
 chan-tx_substream is not set, too.

Wrong.  It's memset to zero by matter of fact of how it is allocated.
I'm surprised you don't know this.  It is afterall code which I thought
you'd be fully aware of, being core ALSA code.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
 2.6 Serial core


---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] An driver error when I using aplay!

2004-06-07 Thread Russell King
On Mon, Jun 07, 2004 at 03:24:46PM +0100, James Courtier-Dutton wrote:
 Russell King wrote:
  
  But unfortunately I don't have the driver code myself to be able to
  comment, so its probably been fscked.
  
 
 If the code was posted publically, the author of the code would get a 
 lot more useful help from more eyes.

The author of the code (me) is complaining that he can't see the
exact code in question because it appears to be either and old
version or contains additional modifications.

And the reason it isn't publically released yet is because ALSA
fails to work correctly on ARM, so the desire to release it and
end up supporting a lot of whinging people, explaining why core
ALSA on ARM is broken is _NOT_ what I want.

I'm not in the habbit of releasing known broken code.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
 2.6 Serial core


---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel