Having a port of ALSA would sure round out 5.2 nicely, and would get you MIDI support: http://www.alsa-project.org/
I think you wouldn't really do anyone a favour, including the ALSA folks, if you went and made a port right now. The ALSA project is still not at 1.00 status and still quite in-flux.
One could go either way with this. Leave it for after 1.0, or grab it now and help build it up for a better 2.0. Or I guess we could initiate the ABSDSA and have support for both ALSA and OSS. Wouldn't this be even more work though?
porting alsa would gain very little and be a huge regression.
This can easily happen if we get behind a developer. ALSA has been sponsored by SuSE for the benefit of Linux, and there's no reason we can't pull together our resources to do the same for our OS. I'm sure someone will step forward to do the port if we have the cash for them to comfortably sit in front of their computer until the port is complete.
I'd appreciate sponsoring somebody to work on our existing newpcm stuff and add the missing bits and pieces much more. Donating hardware (soundcards and MIDI-devices) would probably help very much already.
OSS is on the outs. New applications that are ALSA only will soon be common, won't they? Newpcm is what, five years old? Whatever it is, it ain't new anymore. Of course, maybe I'm completely mistaken about the whole situation and all newpcm needs is a boost.
you are completely mistaken.
first, let me correct some of the factual inaccuracies that you are propounding:
* newpcm is not even 4 years old yet.
* alsa is in no way desireable- it is not a device abstraction system. every app must do userland resampling to play, say 44.1khz sound on a 48khz only chipset. given that it does not provide hardware abstraction, alsa's kernel components are far too complex.
* alsa drivers are difficult to write- compare one to its corresponding newpcm driver.
* newpcm has a much more advanced architecture than alsa, and is entirely different than oss. the fact that newpcm's dsp and mixer layers implement the oss api is incidental.
newpcm v2, which may gain a better name, is under development. i originally hoped to have it ready for 5.0, but very poor health over the last year prevented this. instead, it will be targetted at 6.0 and probably backported to ~5.3+ once feature complete and demonstrably stable.
i will not elaborate here on the features planned for v2, but replacing the api is one of them, although oss compatibility will be provided. there are a few people out there who know the plans, but they all know that i want them kept under wraps for now.
with only two main developers, you should not expect v2 to be committed much before the end of this year. additional manpower would help, but don't volunteer if i'm going to have to spend time teaching you c, the kernel, kobj or the current design of newpcm. someone well versed in dsp techniques and acquainted with the mathematics of accoustics would be very helpful. money and/or hardware would be nice, but i at least am limited in speed by my body and nothing short of a few million dollars is likely to change that.
the single greatest incentive to continue that the community could provide is to refrain from suggesting that newpcm be scrapped or replaced, especially by proponents who are not willing to do the code themselves, do not have a replacement working prior to their proposal, and/or have little to zero knowledge of sound hardware and the requirements of a top-flight audio infrastructure.
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
