Sponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Still waiting for Flash
Still waiting for Flash
Posted Mar 21, 2008 19:17 UTC (Fri) by wertigon (guest, #42963)In reply to: Still waiting for Flash by nix
Parent article: Still waiting for Flash
So you have listed one benefit which cannot be achieved by OSS4. Should you by some reason run a thin-client based solution ala LTSP and you need sound, OSS4 is not quite up to the task. Fair enough. As for extensibility; Why would you ever want that for sound? What exactly is it that you need scripting for? If you need to redirect the streams like PulseAudio does, then yes, PulseAudio *IS* the way to go. But most *doesn't* need this, most need/wants what we have today+reliable software mixing+per-app volume controls. That's it, and OSS4 provides for that. I don't see any advantage at all to go with PulseAudio over OSS4 as default, given the increase in latency. Again, prove me wrong and I'm happy to admit to my ignorance. But right now PulseAudio sounds like yet another soundserver hack, which doesn't help the situation at all... Finally, read this page, it explains my feelings on why OSS4 is the way to go: http://insanecoding.blogspot.com/2007/05/sorry-state-of-s...
(Log in to post comments)
Still waiting for Flash
Posted Mar 21, 2008 19:51 UTC (Fri) by nix (subscriber, #2304) [Link]
If you can't figure out why people might want runtime modification of behaviour in ways unanticipated at kernel-build time (!) then there's not much I can do to convince you, although it might help to point out that there are an *awful* lot of people with e.g. service contracts that *forbid* recompiling kernels. (Also, hacking the kernel to add some new feature is a hell of a lot more risky than adding a new plugin, an unprivileged userspace shared library.)
Still waiting for Flash
Posted Mar 23, 2008 12:39 UTC (Sun) by wertigon (guest, #42963) [Link]
I'm questioning why it has to be default. PulseAudio seems to have it's uses, yes, but the way I see it; "Oh crap! We have twenty different incompatible APIs in the Linux sound arena! It's a friggen mess!" "... Darnit! Wait, let's create a twentyfirst incompatible API which can wrap around all other APIs! That'll solve everything!" "... BRILLIANT!!!" ... Isn't that the kind of think that got us into this mess in the first place? Isn't it better to deprecate *ALL* other APIs but three (OSS4, OpenAL and PulseAudio), and take it from there? OSS4 because it's the best API available today for most apps, and is portable to most other UNIXes (sans OSX). OpenAL because it works on Win+MacOSX+Linux, making it the best cross-platform API today. And finally, PulseAudio for those who would need it. It'd solve quite a few headaches on that arena. 'Nuff said.
Still waiting for Flash
Posted Mar 23, 2008 13:21 UTC (Sun) by nix (subscriber, #2304) [Link]
Actually the PulseAudio API is going to be superseded, by, wait for it, a twenty-second incompatible API, in the form of the libsydney library, which can talk to all the others! (Note the inspired naming after the city where the design was done: that'll make it easy for people to remember what it is!) The nicest thing about PA for me is that (with the aid of, wait for it, *loadable modules*) it can emulate almost every other sound server and talk to almost every lowlevel API out there. I didn't need to recompile any of my programs when I started using PA: they still think they're talking to esd for the most part, or arts.