Re: [Alsa-devel] alsa configure/install bug

2002-06-26 Thread Takashi Iwai

At Tue, 25 Jun 2002 14:02:06 -0400,
Derek D. Martin [EMAIL PROTECTED] wrote:
 
  please elaborate your prolbem.  what says modprobe?
 
 The problem is that if the alsa modules are not installed in
 /lib/modules/KVER/misc, modprobe can't find them to load them.  Once
 they are installed there, everything works fine.  This is as it was
 with the 0.9.something beta something that I was using before this,
 also...  meaning that when I installed the beta drivers previously,
 they installed in the misc directory (with out me telling them to do
 so specifically, as far as I can remember), and everything worked
 fine.
 
can you check where the files are copied to?
just look at what make install-modules shows.

if it were /lib/modules/preferred, then this is a special handling in
alsa-driver's configure script for rh-5.1.  if this directory exists,
configure will use this location in prior to others.

perhaps this doesn't match any longer with the recent redhat
releases.  if so, we should remove this workaround.


 Is it possible that this is due to the version of modutils that I
 have, and not related to the kernel at all?  This is with Red Hat's
 modutils-2.4.13-0.7.1 rpm...
 
this looks fine.

  what happens if you run depmod -ae?
 
 Well, I set the command line for configure to place them in the misc
 directory, so everything is working now.  There is no output from
 depmod -ae, but presumably there would be had I allowed the drivers to
 be installed in the kernel/sound directories?
 
kernel/sound directory must be checked by modprobe.
all normal kernel modules are installed under kernel directory.


ciao,

Takashi


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel



[Alsa-devel] Turtle Beach Pinnacle/Fiji alsa driver 0.1.2

2002-06-26 Thread karsten wiese

hi,

new in this is pcm record and midiin.
latency (latency -m32 -M32 -b -r 48000, patched to
allow 3 periods) runs with down to 32 frames.
amSynth runs well with it on an 400PII. 
mmap driver for amSynth available from me. 
not needed, but gives you more voics with the
fiji/pinnacle.


works:
PCM: Stereo record / playback mmaped fullduplex
with the alsa-tools aplay, pcm, aplay -M, latency with
3 periods patch, alsaplayer, amSynth
MIXER:   Master, Pcm, Line In, Monitor
MIDI:in
VERSION: 0.9rc2CVS, patch attached
OS:  tested on Slackware 8.1rc1

not...yet:
PCM: periods / buffer != 3
MIDI:out
SPDIF:
KURZWEIL: start a mpu401 device

the patch archive consists off a diff, which is to be
applied to the raw cvs-sources and two directories.
after copying the also contained directories into the
cvs tree do 

cvscompile 
make
make install
in alsa-driver as usual.

note: this has only been tested to build modules for a
2.4.18 kernel on an 400MHz PII with a pinnacle in
non-pnp mode.



For additional infos concerning the fiji/pinnacle
cards search for the pinnacle oss-free driver docus on
the web.
there is a how-to install the needed firmware-files
also.

cheers, karsten

__

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Yahoo! präsentiert als offizieller Sponsor das Fußball-Highlight des
Jahres: - http://www.FIFAworldcup.com


0.9rc2-0.1.2.tar.gz
Description: 0.9rc2-0.1.2.tar.gz


Re: pcm_drain() behavior (Re: [Alsa-devel] snd_pcm_close hangs)

2002-06-26 Thread Jaroslav Kysela

On Mon, 24 Jun 2002, Takashi Iwai wrote:

 At Tue, 18 Jun 2002 20:23:50 +0200 (CEST),
 Tim Goetze wrote:
  
  Takashi Iwai wrote:
  
  well, draing samples at close corresponds to flushing the buffered
  data to disk at fclose.  then it sounds normal, doesn't it?
  
  i'm still not convinced -- if the stream is running when you close it,
  you're right, obviously. 
  
  but when it's not running, starting and stopping it usually produces a
  click that will ruin the audible effect of the few msec worth of sound
  'drained' (that nobody cares about anyway since the stream is about to
  be closed).
  
  right?
 
 this is a question of behavior.
 i don't think it's absolutely wrong that the driver processes the
 rest of samples at stop status if drain() is called.
 
 but..  from my feeling, i agree with you.  it doesn't matter if the
 samples are simply dropped at close() when its stream was already
 stopped.  so i myself would like to change this behavior.
 the fix must be quite easy.
 
 however, we need a consensus about this.
 
 any comments (or objections)?

We can see both behaviour for the device access. The current
implementation was taken from OSS. Actually, I don't mind to change it,
because programmers should call drop() or drain() before close depending
on their choice. It's also true, when the process is canceled for some 
signal, it would be better to drop the contents of ring buffer by default. 
It means that even the stream is running, it should be stoped and droped 
in native API.

Jaroslav

-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linuxhttp://www.suse.com



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel



Re: [Alsa-devel] alsa-conf will not compile.

2002-06-26 Thread Takashi Iwai

At Tue, 25 Jun 2002 01:27:53 +0100,
James Courtier-Dutton wrote:
 
 Has anyone managed to get alsa-conf to compile ?
 
 I use the current CVS, but it will not compile.
 Is alsa-conf of any use any more ?

no, it's not maintained atm.
it was designed for the old system.  since then, some things have been
changed.

iirc the following problems have to be solved:

- rewrite the parser for outputs of new modprobe/modinfo
- rewrite the code to use snd-xxx instead of snd-card-xxx
- the module syntax description was moved from the built-in module
  description to /lib/modules/XXX/modules.generic_string.
  the parser must look at the latter file.


Takashi


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel



Re: [Alsa-devel] The exact message you would expect from a first post.

2002-06-26 Thread Takashi Iwai

At 25 Jun 2002 21:33:07 +1000,
Danni Coy wrote:
 
 I have an AudiowerksII from Emagic. I was wondering what steps I could
 take to get this supported by Alsa. I have some programming experience
 but have never worked on device drivers before. I have contacted Emagic.
 What Next?

if you got a hardware spec, then take a look at the sources already
existing.  there are likely drivers with the similar chip design.
then copy it, and modify it.

also, it would be better to ask Emagic whether the spec can be put on
a public place, so that other developers can be involved with the
development.

unfortunately, there is no documentation about alsa kernel api.
the source is only exact information.
my old post on alsa-devel ML might help you to write a driver.
please check the ml archive (or google).

if you have no experience about writing device drivers, i recommend to
read a book before actually coding.  a book from o'reily linux device
driver is the best one.  it's even available on the web as a pdf
file.


ciao,

Takashi


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel



Re: pcm_drain() behavior (Re: [Alsa-devel] snd_pcm_close hangs)

2002-06-26 Thread Jaroslav Kysela

On Wed, 26 Jun 2002, Takashi Iwai wrote:

 At Wed, 26 Jun 2002 17:55:49 +0200 (CEST),
 Jaroslav wrote:
  
  On Mon, 24 Jun 2002, Takashi Iwai wrote:
  
   At Tue, 18 Jun 2002 20:23:50 +0200 (CEST),
   Tim Goetze wrote:

Takashi Iwai wrote:

well, draing samples at close corresponds to flushing the buffered
data to disk at fclose.  then it sounds normal, doesn't it?

i'm still not convinced -- if the stream is running when you close it,
you're right, obviously. 

but when it's not running, starting and stopping it usually produces a
click that will ruin the audible effect of the few msec worth of sound
'drained' (that nobody cares about anyway since the stream is about to
be closed).

right?
   
   this is a question of behavior.
   i don't think it's absolutely wrong that the driver processes the
   rest of samples at stop status if drain() is called.
   
   but..  from my feeling, i agree with you.  it doesn't matter if the
   samples are simply dropped at close() when its stream was already
   stopped.  so i myself would like to change this behavior.
   the fix must be quite easy.
   
   however, we need a consensus about this.
   
   any comments (or objections)?
  
  We can see both behaviour for the device access. The current
  implementation was taken from OSS. Actually, I don't mind to change it,
  because programmers should call drop() or drain() before close depending
  on their choice. It's also true, when the process is canceled for some 
  signal, it would be better to drop the contents of ring buffer by default. 
  It means that even the stream is running, it should be stoped and droped 
  in native API.
 
 yep.
 dropping in all cases will be the easiest solution.
 we can even reduce the strange conditionals in close().
 
 drain() can be called at the close() of oss emulation layer
 if it's really necessary.

It is, but the OSS emulation code already uses a different flush method, 
so we don't need to touch this code.

Jaroslav

-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linuxhttp://www.suse.com



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel



Re: [Alsa-devel] Midi reverb on Emu10k1

2002-06-26 Thread Jaroslav Kysela

On Wed, 26 Jun 2002, Takashi Iwai wrote:

 Hi,
 
 At Mon, 24 Jun 2002 20:38:00 +0200,
 Nicola Orru' wrote:
qq  
  Hello, people out there!
  
  I'm Yet-Another-Programmer-Keyboard player.
  I would like to work on MIDI chorus/reverb implementations on the emu10k1 driver 
in a way 
  I can experience as much fun as original Creative driver provide on Windogs.
  
  Where should I start from? How much work is needed to complete the sub-project?
  Where can I find documentation about that?
  
 this is one of long standing todo's.
 
 the implementation needs to steps.
 
 1. write a dsp loader program to communicate with the alsa-drivers via
emu10k1's hwdep ioctls.
 
there is already an assembler, which was ported from oss driver's
program.  but it's never tested, i think.

Well, the assembler probably needs more modifications, because my idea of 
DSP code management and linking is different from the OSS guys.

 2. adds a code to assign the dsp codes to certain midi controls in
emu10k1 driver.
 
 once the first one is ready, then it wouldn't take long time to do the
 2nd step.  i have already some idea about the latter.
 
 
  Currently, I am trying to learn more about DSP architectures and 
  digital filter programming on several online books, but, 
  as I have little patience, I would like to beat the metal as
  soon as possible.
  
  Any hints, pointers to TFM, will be sooo happily accepted.
 
 the oss emu10k1 driver has already good examples for dsp codes on sb
 live.  but the interface is different between alsa and oss drivers, so
 you cannot use them straightforwardly.
 the oss emu10k1 archive also includes some documents about dsp codes
 on emu10k1.
 
 the problem is, as written above, the implementation of loader.
 how to manage static and dynamic routings, and so on.

Exactly. OSS code does this management partly in the kernel. In my
opinion, we should leave in kernel only necessary things, so the
linker/loader/code manager should be written completely in the user space.

Jaroslav

-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linuxhttp://www.suse.com



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel



[Alsa-devel] up to date api tutorials

2002-06-26 Thread Ed Sweetman

I'm not sure if the api tutorial is slightly out of date or just
completely useless due to it's complete simplicity in that the buffer is
created after you find out the period_size so you never partially fill a
period but it is for everyone else in the world who has a buffer before
they find out the period.

I'm trying to figure out why i get little clicks and blips when i really
dont think i should since i think i'm doing everything correctly. My
theory is that the period_size available is more than the size i'm
sending it even though I set the period size.

ok, my situation is this.  I have a buffer coming it that's 2KB, 16384
bits.  Parameters are set up like normal and in the tutorial for
standard pcm playback.  I set any, access, format, channels, rate_near,
period_size.   periodsize is set to 1/4 buffersize. Then i go and have a
loop that loops my writei command in another function until the stream
ends.  my writei command has a size argument of 1/4 of the buffer i'm
sending it.  now when I do this, and use it the audio playback is slow
sounding.  So i have a function that waits some time and a conditional
wrapped around the writei command to only do the write when the
available periodsize is greater than or equal to 1/4 of the buffer
size.   This allows the audio to play at normal speed but like i started
off saying, i get clicks and blips throughout the playing.  I'm not sure
what i'm not doing here.   I've attached the main portion of the code,
you can get the entire thing from
http://sourceforge.net/cvs/?group_id=51494  pull zinf ...currently mp3s
wont work at all due to their tinier buffer that gets sent to the
alsapmo but ogg vorbis files almost work.  If someone could explain
where i'm going wrong here I might be able to finish this up.  Thanks 

I'm getting desperate as it doesn't seem the 0.5x code that this is
built off of had to do anything special timing wise to work and the
tutorial examples bypass all timing problems because they make the
buffersize to the available buffersize that alsa says it has available. 



/*

FreeAmp - The Free MP3 Player
Driver for Advanced Linux Sound Architecture 
  http://www.alsa-project.org
 
Portions Copyright (C) 1998-1999 EMusic.com

alsapmo.cpp by Fleischer Gabor [EMAIL PROTECTED]
uses code by Anders Semb Hermansen [EMAIL PROTECTED]
and Jaroslav Kysela [EMAIL PROTECTED]

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

$Id: alsapmo.cpp,v 1.4 2002/06/26 04:20:53 safemode Exp $

*/

/* system headers */
#include stdlib.h
#include iostream.h
#include alsa/asoundlib.h
#include ctype.h
#include errno.h
#include string.h

/* project headers */
#include config.h
#include alsapmo.h
#include facontext.h
#include log.h

#define DB printf(%s:%d\n, __FILE__, __LINE__);

extern C
{
   PhysicalMediaOutput *Initialize(FAContext *context) {
  return new AlsaPMO(context);
   }
}

AlsaPMO::AlsaPMO(FAContext *context) :
PhysicalMediaOutput(context)
{
   m_properlyInitialized = false;
   m_pBufferThread = NULL;

   m_iBytesPerSample = 0;
   m_iBaseTime = -1;
   m_iDataSize = 0;

   if (!m_pBufferThread)
   {
  m_pBufferThread = Thread::CreateThread();
  assert(m_pBufferThread);
  m_pBufferThread-Create(AlsaPMO::StartWorkerThread, this);
   }

   m_handle = NULL;
   m_device = NULL;
   m_channels = -1;
   m_samples = -1;
}

AlsaPMO::~AlsaPMO() 
{
m_bExit = true;
m_pSleepSem-Signal();
m_pPauseSem-Signal();

if (m_pBufferThread)
{
   m_pBufferThread-Join();
   delete m_pBufferThread;
}

snd_pcm_close(m_handle);
}

Error AlsaPMO::Init(OutputInfo* info) 
{
int  err;
snd_pcm_hw_params_t *params;
//printf(init\n);
m_properlyInitialized = false;

m_iDataSize = info-max_buffer_size;

err=snd_pcm_open(m_handle, plughw:0,0, SND_PCM_STREAM_PLAYBACK, 0); 
//  SND_PCM_NONBLOCK);
if (err  0)
{
ReportError(Audio device is busy. Please make sure that 
another program is not using the 

[Alsa-devel] changed snd_pcm_close() behaviour

2002-06-26 Thread Jaroslav Kysela

Hi all,

after discussion with Takashi and others on this list, the 
behaviour of snd_pcm_close() function has been changed in this way:

The stream is stoped and all samples (if any) are droped. It means, that
if the user space code wants to flush samples to output, the
snd_pcm_drain() function must be called before the snd_pcm_close() call.

I hope that this change doesn't cause any problems in any 
application. Anyway, please, report all problems.

Jaroslav

-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linuxhttp://www.suse.com



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel



Re: [Alsa-devel] changed snd_pcm_close() behaviour

2002-06-26 Thread Abramo Bagnara

Jaroslav Kysela wrote:
 
 Hi all,
 
 after discussion with Takashi and others on this list, the
 behaviour of snd_pcm_close() function has been changed in this way:
 
 The stream is stoped and all samples (if any) are droped. It means, that
 if the user space code wants to flush samples to output, the
 snd_pcm_drain() function must be called before the snd_pcm_close() call.
 
 I hope that this change doesn't cause any problems in any
 application. Anyway, please, report all problems.

Please don't forget to fix alsa-oss.

-- 
Abramo Bagnara   mailto:[EMAIL PROTECTED]

Opera Unica  Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project   http://www.alsa-project.org
It sounds good!


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel



Re: [Alsa-devel] alsa configure/install bug

2002-06-26 Thread Derek D. Martin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ok, I moved my misc directory aside, and reinstalled them in the
kernel/sound directories.  Here's some more info:


At some point hitherto, Takashi Iwai hath spake thusly:
   what happens if you run depmod -ae?
  
  Well, I set the command line for configure to place them in the misc
  directory, so everything is working now.  There is no output from
  depmod -ae, but presumably there would be had I allowed the drivers to
  be installed in the kernel/sound directories?

It turns out there's still no output to this command.

 kernel/sound directory must be checked by modprobe.
 all normal kernel modules are installed under kernel directory.

It seems like it's checking, partially.  After starting my X session,
gnome complains that it's unable to open /dev/mixer.  I looked at the
output of lsmod, and the only sound-related modules that got loaded
were these:

  $ lsmod
  Module  Size  Used byTainted: P  
  snd-mixer-oss   8800   0 (autoclean) (unused)
  snd24200   0 (autoclean) [snd-mixer-oss]
  soundcore   3588   0 (autoclean) [snd]

Note the 'P' flag in the Tainted header.  I don't know what this
means, but it wasn't there when the modules were located in misc.  The
man page for lsmod is remarkably unhelpful in determining the meaning
of the 'P' that's there.  I have a vague idea that this has to do with
GPL issues, but beyond that no clue...

Also, in my logs, I see these messages:

  Jun 26 15:30:49 mercury modprobe: modprobe: Can't locate module char-major-81
  Jun 26 15:30:52 mercury modprobe: modprobe: Can't locate module sound-slot-0

Apparently, it's not loading any of the drivers in the
kernel/sound/pci directory...  Oddly, if I manually modprobe
snd-ymfpci, it loads, along with the rest of the modules.

All I can say is, WTF?

  Module  Size  Used byTainted: P  
  snd-ymfpci 41444   0  (unused)
  snd-pcm48768   0  [snd-ymfpci]
  snd-opl3-lib5312   0  [snd-ymfpci]
  snd-timer   9760   0  [snd-pcm snd-opl3-lib]
  snd-hwdep   3456   0  [snd-opl3-lib]
  snd-mpu401-uart 2800   0  [snd-ymfpci]
  snd-rawmidi12352   0  [snd-mpu401-uart]
  snd-seq-device  3840   0  [snd-opl3-lib snd-rawmidi]
  snd-ac97-codec 23620   0  [snd-ymfpci]
  snd-mixer-oss   8800   0  (autoclean) (unused)
  snd24200   0  (autoclean) [snd-ymfpci snd-pcm snd-opl3-lib s
  nd-timer snd-hwdep snd-mpu401-uart snd-rawmidi snd-seq-device snd-ac97-codec snd
  -mixer-oss]
  soundcore   3588   4  (autoclean) [snd]



- -- 
Derek Martin   [EMAIL PROTECTED]
- -
I prefer mail encrypted with PGP/GPG!
GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
Learn more about it at http://www.gnupg.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9GhoIdjdlQoHP510RAovgAJ97OLEPtEiCvABX6b3vzI2KUTbunACeLDaL
8tuWo7cttdSmb7o7bqkBD40=
=+Pp9
-END PGP SIGNATURE-


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel



Re: [Alsa-devel] alsa configure/install bug

2002-06-26 Thread Derek D. Martin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

At some point hitherto, Takashi Iwai hath spake thusly:
 kernel/sound directory must be checked by modprobe.
 all normal kernel modules are installed under kernel directory.

Hi Takashi,

It occured to me that you're probably going to ask me what my
modules.conf file looks like, so I'll save you the trouble:

  # ALSA Sound stuff
  alias char-major-116 snd
  options snd snd_major=116 snd_cards_limit=1
  alias snd-card-0 snd-card-ymfpci
  options snd-card-ymfpci snd_index=0 snd_id=YMFPCI
  
  alias char-major-14 soundcore
  alias sound-slot-0 snd-card-0
  post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L /dev/null 21 || :
  pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S /dev/null 21 || :
  alias sound-service-0-0 snd-mixer-oss
  alias sound-service-0-1 snd-seq-oss
  alias sound-service-0-3 snd-pcm-oss
  alias sound-service-0-12 snd-pcm-oss

Now, looking at this, and matching it up against the modules that
actually exist, I notice that the alias for snd-card-0 refers to a
module that doesn't appear to exist.  I suspect this is the culprate.
However, this is the exact same configuration that I'm using when the
modules are in the misc directory, and everything works fine.

Looking back at the documentation, I think I understand what happened.
The howto shows this in the modprobe section:

  # ALSA portion
  alias snd-card-0 snd-interwave
  alias snd-card-1 snd-card-es1370

I copied the form of the second entry, but that's not the name of the
module for the ymfpci chipset.  I've modified the alias, but I don't
actually have time to test it to see if that fixed the problem.  I
believe it will...

Gotta run.  Thanks for your help.

- -- 
Derek Martin   [EMAIL PROTECTED]
- -
I prefer mail encrypted with PGP/GPG!
GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
Learn more about it at http://www.gnupg.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9GhzZdjdlQoHP510RAkjlAKCrPcxJerxEHRhHZloUAse2MFI+4wCggHUs
IFXlX2+9RamhqjRwXXFUQU0=
=b9NM
-END PGP SIGNATURE-


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel



Re: [Alsa-devel] PCM API enhancement - more bitmasks to support more formats

2002-06-26 Thread Frank van de Pol


Hi Jaroslav,

you might be interested in next site:
http://www.tsp.ece.mcgill.ca/Docs/AudioFormats/WAVE/WAVE.html

it contains Microsoft's Riff Wave specs. Noticable the 'Multi-channel / high bit 
resolution formats ,
2001-06-18' might be interesting for you. It contains also some sample data in various 
formats

Enjoy,
Frank.


On Wed, Jun 26, 2002 at 04:09:11AM +0200, Jaroslav Kysela wrote:
 Hi,
 
   I've modified and clean up Takashi's patch to add support for more 
 formats. It keeps binary compatibility (important for the kernel inclusion)
 and adds some space for future expansion now. The code is in CVS.
   Does somebody have an URL to 24-bit WAV files? I'd like to add
 support for this format to aplay/arecord. Thanks.
 
   Jaroslav
 
 -
 Jaroslav Kysela [EMAIL PROTECTED]
 Linux Kernel Sound Maintainer
 ALSA Project  http://www.alsa-project.org
 SuSE Linuxhttp://www.suse.com
 
 
 
 ---
 This sf.net email is sponsored by: Jabber Inc.
 Don't miss the IM event of the season | Special offer for OSDN members! 
 JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
 ___
 Alsa-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/alsa-devel

-- 
+ --- -- -  -   -- 
| Frank van de Pol  -o)A-L-S-A
| [EMAIL PROTECTED]/\\  Sounds good!
| http://www.alsa-project.org  _\_v
| Linux - Why use Windows if we have doors available?


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel



[Alsa-devel] problems ALSA on iBook2

2002-06-26 Thread Alexander Carot

Hej to all,

we recently tried to install ALSA on an iBook2 with Nando at CCRMA in
Stanford university but we have some trouble :

The whole installation went pretty fine without any trouble, the module
is installed and loaded and we finally set up the mixer but there's no
sound (neither speakers nor headphone).

Chipset : Tumbler 
OS  : YellowDog 2.2 (Rome)
PPC : iBook2 600MHz

For us everything looks like a bug. Does anyone have any experiences
with ALSA on iBook ?

Thanks

-- A l e x






---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel