On Mon, 5 Apr 2004 14:36:52 +0200 (CEST) Jaroslav Kysela <[EMAIL PROTECTED]> wrote:
> On Mon, 5 Apr 2004, Florian Schmidt wrote: > > > I have one little question to the alsa devs though: > > > > The kernel level OSS emu already does stuff like samplerate > > conversion, etc.. why can't it be extened to do channel mixing like > > the commercial oss drivers? I suppose it is unclean design, but a > > very unclean design that works is better than a clean design that > > doesn't > > > > I therefore ask you: How difficult would it be to implement that? I > > would give it a try myself. Do you have pointers where to start? > > Where do i find relevant docs? > > I think that it would be much better and easier to recode the > teamspeak to not use the 'FILE *' handles for audio i/o but raw file > descriptors. Yes.. but it is a closed source app and it seems that the authors have no plans on changing the 2.x version of teamspeak to do that.. I don't know when teamspeak 3.x comes out [and i'm not sure that the teamspeak authors themself know]. Also changing the closed source games is not a solution. Some old ones will never be adopted. We don't live in an ideal world where every app can be changed to suit the ALSA system. Rather the ALSA system IMHO should adopt to provide the best possible experience for the user. But this argument aside: What if i still would like to burn my hands on adopting the kernel level oss emu? Where do i find docs and how much difficulty would be involved? Any Pointers? Hmm.. I am also aware that this will not solve the problem that even when multiple OSS apps can use the non hw mixing capable device, other native ALSA apps will not be able to output sound at the same time.. In this case the only thing that helps really is aoss. But rather than fixing closed source apps, aoss should be fixed in a way to provide interception of all access to the device files. Because right now it clearly does not do what it is intended to do: provide a working(!) redirection for OSS apps to ALSA's pcm plugin layer. Hmm, actually fixing aoss would definetly be the better way compared to fixing kernel level oss emu.. Wouldn't it be suitable [even with performance penalties] to catch the open/write/read/close system calls at the lowest level [the kernel] and redirect them to userspace so alsa-lib can come into play? I remember reading here about such an approach, but it had other difficulties. Right now there's two solutions which each work in certain configurations/scenarios [kernel level oss emu and aoss]. The kernel level oss emu has the advantage of working for almost all ways of accessing the oss device files.. The aoss has the advantage of providing extended functionality like dmix, etc.. The advantages of both methods really must be merged to provide a good user experience on non hw mixing capable soundcards [which will be the standard in years to come i suppose].. Ok, now rip my arguments apart :) [putting flamesuit on] Florian Schmidt -- kT ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Alsa-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-user
