[ ah, here's that message i missed ... ] >So what is preventing us from taking CoreAudio-like path and reworking >the way audio is handled OS-wide?
CoreAudio has explicit kernel-side support in MacOSX. I find it unlikely that this would ever be accepted by Linus. We have plenty of mechanisms to make this fast. khttpd was a tiny piece of code that did something that a huge %-age of all linux machines do, and Linus was still very opposed to it to start with. I can't imagine how he'd react to what is clearly a user-space framework being moved into the kernel. There's nothing that CoreAudio does that needs any new Linux kernel support. I can't see anything gained by moving it into the kernel other than "forcing" it as the standard, and for that, I'll just be glad when ALSA becomes the "forced standard" (though of course, it won't be because the OSS API will still be supported. sigh). There's another example - look at how difficult its been just to get ALSA to replace OSS in the kernel. > Is this just a gargantuan task or is >it just lack of interest? No one said that we need to stick to the OSS >standard established way before anyone even considered Linux as a >multimedia workstation. As I said, CoreAudio requires a different application design unless you only use the CoreAudio HAL, which plays a role analogous to the one ALSA plays for us. If everyone was willing to port their code to this application design, either by moving to JACK or PortAudio, we could move forward. Otherwise, its an impossible task. >On the other hand, you have mentioned alsa-server. I must admit I do not >have much knowledge regarding this one. Is this server capable of >providing daemon-like audio resource sharing and keeping latency low? If >so, maybe this should be the core framework for the new daemon? it provides daemon-like audio resource sharing. as i mentioned previously, low latency is generally not much use without sample synchronous execution of all participants in the shared tree. alsa-server does not do this. >If there is a better solution to this problem than what was originally >established by OSS, shouldn't we learn from our own mistakes and other's >successes (i.e. core audio and BeOs) and rework the way audio is handled >in Linux? JACK is an attempt to do just that. If more people would contribute to it, which at this point means being willing to understand how it works and write code to fix problems and implement features, we would have a working framework. Abramo has told us that ALSA can do this. He's mostly right. ALSA does offer a totally unified approach to audio and MIDI. Its missing one important feature right now, however, and thats sample-synced execution of a processing "graph" (consisting of several applications). Actually, make that 2, since its also missing inter-app audio routing, but this can be solved much more easily than the sample-synced issue. Any framework that does not ensure sample-sync execution is ultimately useless for anything "studio-like". It means that you will get strange comb-filter-like effects as two different audio streams move in and out of phase with each other by a few samples. >Could you please tell me how hard would it be to rework the way audio is >handled, while preserving existing compatibility with esd and >artsd-based apps, and on top of that providing JACK-like efficiency >(with priority managing capability)? JACK is 60% about sample-sync, 35% about inter-app audio data routing and 5% about low latency (you can happily run a JACK server with massive latency if you choose). As I've tried to explain several times, callback-driven sample-sync operation is a different design than "block on read/write". You can make apps that use the latter design work with a sample-sync network, but they don't participate in it as equals (i.e. they are not sample-synced to the rest of the network). Thats why getting alsa-server to participate in JACK would be great: this would allow all regular ALSA apps to use JACK without its sample-sync features. The other way around doesn't work: all the sample-sync-needing apps would fail to get what they wanted/expected/needed if they just use alsa-server. --p