Still waiting for Flash
Still waiting for Flash
Posted Mar 20, 2008 22:50 UTC (Thu) by wertigon (guest, #42963)In reply to: Still waiting for Flash by elanthis
Parent article: Still waiting for Flash
Please, no. Not another sound daemon. They suck, introduce unneccessary latency and generally bogs down performance. OSS4 works fine, has extremely low latency, *is standard* on every other UNIX system but Linux and is released under BSD license; what more could one possibly want? Except the death of ALSA of course...
Posted Mar 21, 2008 0:37 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Mar 21, 2008 1:37 UTC (Fri)
by bronson (subscriber, #4806)
[Link] (9 responses)
Posted Mar 21, 2008 2:41 UTC (Fri)
by wertigon (guest, #42963)
[Link] (8 responses)
But, OSS4 supports all this through vmix (since you can set per-application volume through it). You don't need the PulseAudio API with OSS4. It's an extra, unneccessary layer, and it solves nothing. How exactly is it better to introduce yet another layer adding more latency than just using OSS4, which solves everything PulseAudio does at kernel level? Then again, there might be something I'm missing here. Feel free to point it out.
Posted Mar 21, 2008 13:40 UTC (Fri)
by nix (subscriber, #2304)
[Link] (7 responses)
Posted Mar 21, 2008 17:13 UTC (Fri)
by wertigon (guest, #42963)
[Link] (5 responses)
Posted Mar 21, 2008 18:40 UTC (Fri)
by nix (subscriber, #2304)
[Link] (4 responses)
Posted Mar 21, 2008 19:17 UTC (Fri)
by wertigon (guest, #42963)
[Link] (3 responses)
Posted Mar 21, 2008 19:51 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Mar 23, 2008 12:39 UTC (Sun)
by wertigon (guest, #42963)
[Link] (1 responses)
Posted Mar 23, 2008 13:21 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Dec 2, 2008 7:12 UTC (Tue)
by netghost (guest, #54048)
[Link]
Beside a network sound server is not a rocket science and does not need to be messed up with local, normal audio function.
OSS4 does everything that a normal people requires with minimal configuration, it is portable, easy to program, it is a pity that Linux community seems very good at keeping memories about the unhappy events it has many years ago and can not accept technologies that are apparent superior.
Still waiting for Flash
Your saying that PulseAudio sucks pretty much guarantees that you haven't
tried it.
Still waiting for Flash
PulseAudio is brilliant. I love being able to send music to my headphones and still have the
phone ring over my speakers. And being able to use my Bluetooth headset for Ekiga. And being
able to have my music quiet but my IM notifications at a regular volume.
OK, truth be told, I don't quite love it yet... There are still some warts to smooth out.
But I'll go out on a limb and predict that in a year you'll wonder how you ever got by without
PA. It's just that useful.
(this is coming from a guy who would immediately turn off esd and arts first thing after
installing any new system)
Come to think of it, PA's flexible support for sane APIs could help ALSA to the exit over the
next few years. That would be sweet.
Still waiting for Flash
Still waiting for Flash
Hang on, so OSS4 provides network-transparent audio, RTSP streaming,
up/downsampling and format conversion, per-application
automatically-preserved volume levels and audio source/sink bindings, and
a command-line interface and plugin infrastructure safely extensible by
arbitrary users without any special privileges?
If it does, this is an excellent example of how to do *way* too much
inside the kernel.
If it doesn't, this is not equivalent to PulseAudio.
Still waiting for Flash
>>Hang on, so OSS4 provides network-transparent audio, RTSP streaming,
Nope, these two are a special case, and are the only reason I can see a sound server for. When
you want to send out a network sound stream. Then again, mpd seems to do a perfect job of
this.
>>up/downsampling and format conversion, per-application automatically-preserved volume levels
and audio source/sink bindings
Volume levels yes (as long as the vmix API is used, like you're supposed to), and channel
levels as well. I'll have to get back to you on all the other stuff, but chances are good it's
supported.
>>Shell
No, why should it? Again, the only conceivable reason I can see for a sound server is when you
want to stream stuff over a network. Else, it just introduces more lag, which is the thing I'm
opposed to (I'm an amateur musician btw, so I need that low-latency).
Still waiting for Flash
So, er, why should it need to be extensible? I note the absence of a
replacement for the PulseAudio plugin system in that list as well.
I guess if you want an all-in-kernel unextensible replacement for part of
PulseAudio then OSS4 provides you with that.
(Oh, and mpd isn't a sufficient replacement either. Thanks to the ALSA
PulseAudio plugin, *every* app you use can get its output routed via
PulseAudio, which is very useful on remote systems. mpd, while nifty, does
nothing of the kind, nor should it.)
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...
Still waiting for Flash
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
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
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.
Still waiting for Flash