On Thu, 27 Jun 2002, Rui Sousa wrote:
> On Wed, 26 Jun 2002, Jaroslav Kysela wrote:
>
> > 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.
> >
>
> This is basically what we have (the "OSS guys" ;). The information that is
> kept in the kernel is not meant to do any managing but instead it
> allows the patch loader/manager (implemented in user space) to
> retrieve the current DSP code state (which patches are loaded, which
> inputs connect to which outputs, ....). This is very difficult
> (impossible, maybe) to deduce by simply retrieving the DSP code.
Right, but we have things like shared memory for the inter-application
communication. This job is not time-critical, so it would be really better
to leave it outside the kernel space. And, at last, we can have more
implementations of the linker/manager code, which is always appreciated in
the open source community.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project http://www.alsa-project.org
SuSE Linux http://www.suse.com
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
