On Thu, 9 Oct 2003, James Courtier-Dutton wrote:

> Hi,
>
> I have thought of a possible way to save DSP resources on the SB
> Live/Audigy etc.
>
> Instead of having DSP code actually in the emu10k1 source code, have it
> in small user land files on disk.
> When the snd-emu10k1 modules is first loaded, it will contain no DSP
> code. When alsa-lib detects an emu10k1 DSP, it would scan the user land
> files, and then present the mixer api/user with a list of switches, to
> enable or disable a feature, then, only the features the user actually
> wants and needs would be loaded into the DSP, and thus save on DSP
> resources.
>
> This would also allow for special extra user designed modules, in much
> the same way that emu-dspmgr works on the oss driver.
>
> Then the user could have an almost unlimited amount of DSP modules to
> choose from, and only be limited by how many modules can be loaded at
> the same time.
>
> I am sure thise sort of feature would also me useful on other sound
> cards that have DSPs on them.

You have a chance. The build-in default DSP code uses standard routines
available also over ioctls so it not a problem to remove old DSP code and
replace it with something more useful. And yes, we can easy move the
default DSP code from the kernel space to the user space.

                                                Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Reply via email to