Hi all: On Fri, 2002-10-11 at 11:53, torben hohn wrote: > > > > > Does emu10k1 work at a user settable sample rate? 44100 Hz? 32000Hz?
I answer to the original poster first. The Emu10k1 is *locked* at a 48Khz rate. All sources and outputs will be converted to and from this rate for processing. This was a very discussed and criticized design decision, but the EMU/Creative people argue it makes thinks easier (and certainly cheaper as well). > > > MS Windows driver has a good sounding reverb. Could this reverb dsp > > > code be extracted from the MS Windows driver and used "as is" in Alsa? > > > > It's not so easy and I'm sure that we'll violate some patent doing things > > in this way. A doubt it'd violate a patent, but it will violate the copyright of the code, for sure. > There is a reverb in the oss driver from http://opensource.creative.com > it comes as source (i gues it is the same as the windows reverb) It could be the same microcode. Is it GPL'd? > so if we provide a method for the user to load patches into the dsp we > are fine. > i will query Martin Soto on his status. Now, regarding my status: I have a little example C program, that installs a new microcode (not really a patch but the whole microcode program) to the card. It is not able to load standard patches, so you have to put the microcode directly inside the program. I shamelessly stole some of the macros in emufx.c to be able to do that, but it works well ;-) The program deletes all of the mixer controls associated to the standard Alsa microcode, and puts in new controls if that's necessary. It'd be really nice to have a decent interactive front end to this feature, because it would allow to reconfigure the mixer to offer just those controls that the user needs. That would make SBLive! cards much more usable under Linux. > (hi martin can you send me your patchloader code ?) Unfortunately, I have the code at home, so I'll only be able to post to the list today evening (GMT+2). I wanted to improve it a bit, but have been really busy at work lately, and haven't found any time to do it. I'll post what I already have, and keep working on it as time permits. I'm however attaching a small patch to emufx.c that fixes a bug in the implementation of the CODE_PEEK ioctl. It must be applied to alsa in order for my userland program to work. Cheers, M. S. ----------------------------------------------------------------- Martin Soto AG Software Engineering Universitaet Kaiserslautern Tel: +49 (631) 205-3449 Kaiserslautern, Germany E-mail: [EMAIL PROTECTED] -----------------------------------------------------------------
Index: emufx.c =================================================================== RCS file: /cvsroot/alsa/alsa-kernel/pci/emu10k1/emufx.c,v retrieving revision 1.20 diff -u -r1.20 emufx.c --- emufx.c 17 Sep 2002 13:44:38 -0000 1.20 +++ emufx.c 17 Sep 2002 23:43:26 -0000 @@ -2174,6 +2174,10 @@ icode = (emu10k1_fx8010_code_t *)snd_kcalloc(sizeof(*icode), GFP_KERNEL); if (icode == NULL) return -ENOMEM; + if (copy_from_user(icode, (void *)arg, sizeof(*icode))) { + kfree(icode); + return -EFAULT; + } res = snd_emu10k1_icode_peek(emu, icode); if (res == 0 && copy_to_user((void *)arg, icode, sizeof(*icode))) { kfree(icode);