[OSS bashing and backwards compatibility] ok, guys, everybody hates OSS, *BUT*:
* it is a common denominator among many unices, and it works well for trivial applications. think portability. * thanks to oss, many of the excellent composer tools from the next and sgi world have percolated through to linux way back when the linux audio scene was far less evolved and far more desolate than it is now. think critical mass here. * it is apparently easier to program than alsa in its current state of documentation, although that may change in the future. but it is far more appealing to newbies than alsa. again think critcal mass here. i do agree that many closed-source OSS drivers are overpriced crap, but then you don't need to use them. it's up to the oss folks what they do with their work and how they make their living. i like linus' attitude in that respect: everybody decides about the licensing of their own code. if it's not free, stop whining and write your own. i also agree that oss fails to meet but the most basic requirements, but then again, oss does fine for 99.999% of all linux users (i.e. those that want to hear "ping" when they've got new mail). but however evil oss may be, i think hannu savolainen (sp ?) deserves at least a little credit for pioneering a common unix audio layer before we condemn him to eternal torment. don't you think ? ;) jörn Mark Constable wrote: > > On Sat, 15 Dec 2001 07:49, Ivica Bukvic wrote: > > Wow, you are a real LAD surviver, congrats :-) > > > My thought is to develop a sound daemon that would be compatible with > > older apps using esd and artsd, based on alsa-server, with the > > efficiency of jack, and ability to share audio resource(s) with the > > priority settings (so that the desktop warning bleep would have less > > audio priority than the real-time 8-channel recording/playback going on > > at the same time), as well as patchbay-like ability to route signals, > > making Alsa the backbone of the audio system on linux, while > > phasing-out/replacing the inefficient OSS aspects. > > Please, no more half-way compromises with OSS... kill it, do > not even consider "backwards compatibility" for old OSS apps! > Are there any worthwhile salavaging in light of newer developments ? > Every ounce of effort towards maintaining (crappy) backwards > compatibility for old OSS mainly/only systems takes away effort > from enhancing true ALSA apps. > > > On top of that > > documenting Alsa should be the highest priority at this point, thus > > stimulating developers to use Alsa instead of OSS. > > Absolutely, but quality programmer docs to the level of, for > example, the Trolltech QT documentation will take _years_, so > the best shorter term solution is to look at a series of SMALL > example, but useful, apps/trinkets that truly take advantage > of ALSA semantics. Concise, no bullshit HOWTOs on anything to > do with producing various types of code to take advantage of > as much of the ALSA libs and utilities as possible. > > I'm sure there a 1000s of people waiting to dive in and dabble, > but for these type of people it's just too much of a deep hack > to get anything working right now... these same people are the > birthplace for 1000s of audio app(let)s in a few years... the > sooner they can start coding with some guidance the sooner we > will all benifit from this oncoming onslaught. > > The hard core developers on this list are "already there" so > the best bang for bucks in my view is getting the next round > of newbies up and coding asap. > > > A joint effort would make this not only doable but relatively quickly > > achievable. Imagine just how much time does each programmer waste on > > implementing their own version of efficient sound signal pooling process > > within their own application. Now multiply that by the number of linux > > sound apps out there. If we used that same time invested by all > > developers on implementing their own version of the solution to this > > problem, and concentrated on developing one universal solution to this > > issue... Well, you get the idea. > > That's part of the deal with open source and personal development. > Who wants to really work on someone elses project when you can do > yer own ! > > Sure, better coordination would get us there sooner but the upside > of the way it is is exactly that there are so many different routes > being explored... and all clearly outlined in mostly GNU available > source code. This is the "metric" that is not part of the other OSs > that will get played out on the emerging linux a/v scene... and the > more complex and digital things become the more "hacking" may be > generally accepted as the prime way to achieve excellence (as opposed > to just practising those licks over and over again). > > > Now, I must admit that there are aspects of this daemon stuff that I am > > not too familiar with and am not sure whether this kind of architecture > > would be capable of producing sample-synced and at the same time > > low-latency output (as Paul has pointed out), so I am not sure whether > > this would in the end be an universal solution. But even if that > > wouldn't be the case, it could still be used to improve audio resource > > sharing issue, while making extreme low-latency stuff something that > > would have to be dealt with on individual basis (maybe the daemon could > > be circumvented through a reserved high-priority thread, while still > > offering a user-friendly way of "feeding" the /dev/dsp with audio > > buffers in a highly efficient manner). > > Anything strictly ALSA based (particularly so newbies don't get > confused by two seperate code paths) and the smaller and finishable > the better, lot's of people have big grand plans for larger projects > but getting usable (good demonstration) apps in a timely manner > would also be beneficial for a lot of LAD fringe-dwellers. > > --markc -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://spunk.dnsalias.org http://www.linuxdj.com/audio/lad/
