I do know that ALSA is going to be replacing OSS in the kernel although from a system standpoint it makes more sense to be a little general with thing.
It seems like high end applications require low latency. Would it be possible to create a sound server(arts) that fulfilled latency and other high end sound application requirements? As far as Jack is concerned, it appears that if Jack can do the same thing that arts can do, and it sounds that way for at least the small amount of information I've read, then maybe the solution is to open discussion with arts people and jack people about merging the two? How does ALSA provide shared device access? Via a software mixer and multiple /dev/dsp's? I've also mailed csl people with some questions. It really seems to me that if we can possible pull it off we want to use the three tiered design that I proposed earlier. It lets embedded devices talk directly to hardware without a sound server, keeps alsa focused on device level things and lets the sound server take care of more advanced things like software mixers, filters and shared device access. Either way, I think its about time people that knew what they wanted from high end sound apps, people writing games and people working on embedded applications started laying down a foundation for a unified sound architecture for linux with at least a basic standardized API. Chris On Fri, 11 Jan 2002, Paul Davis wrote: > >I'm interested in whether there has been any large scale discussion > >about a unified approach to sound support. Right now supporting > >oss/alsa/arts/esd see ms a bit much and I'm curious as to whether > >there has been any talk of establishi ng something like sound > >server(arts)->sound driver(alsa)->hardware, with common interfaces > >established for the sound server level and sound driver level. The > >only thing I've found so far are discussions of csl and I'm curious > >as to whether csl is adding one to many layers to the whole scheme. > > there has been some discussion about this. you sound as if you do not > know that it is believed that ALSA will soon replace OSS in the kernel > sources, removing OSS from its position as the default audio API for linux. > > audio servers: the problem is that different people need different > things. most desktop users would be quite content with the type of > service that artsd provides, which is why both KDE and GNOME appear to > have adopted it for their desktop environments. but neither artsd nor > esd are suitable for "semi-pro" or "pro" audio applications because of > their latency characteristics. ALSA has its own method of providing > shared access to devices, which has the benefit of being usable > without any run-time hacks and with the exact same API as any other > ALSA PCM device. However, it too is not suitable for high end > applications. Neither the ALSA shared access system nor esd provide > inter-application audio routing either, something most of us consider > very important as we move forwards. a recent move toward fixing the > high-end (read "real time, low latency, high bandwidth") situation can > be found at http://jackit.sf.net/. this aims to provide functionality > similar to that offered by CoreAudio on OS X, or viewed differently, > similar to the role played by VST with Cubase, Nuendo, Logic and > others. However, all these systems (CoreAudio, VST, JACK) require very > different program designs from those typically used by people who > write audio applications for Linux. There is a little bit of momentum > toward adopting JACK, but so far only alsaplayer, ecasound and very > soon, ardour and rythmnlab, are using it. > > so, its a bit of a mess. IMHO, it would be idea if ALSA provided or even > enforced an API like the one imposed by CoreAudio. but it doesn't, and > so for the time being, its quite possible to continue writing > applications using a variety of APIs that all allow the old habits of > "block on write/read" and/or "single threaded design" to continue. > > i wrote to the authors of CSL to ask them to reconsider what they were > doing, but got no reply. there is nobody within ALSA working on moving > ALSA in the direction of a CoreAudio-like API. > > in short, there is no relief in sight. > > --p > > > _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
