On 08/08/2009 10:32 AM, Jens M Andreasen wrote:
On Fri, 2009-08-07 at 10:50 -0400, Sean Corbett
wrote:
Of course it would be a voluntary
standards base, and every developer / distro team can still do
whatever they like, so that innovation can continue... but as
protocols/interfaces/frameworks/whatever are developed and show their
merit, they can be included in the standards base, and
old/deprecated/redundant things removed, ...
You are on your way to define a moving target rather than a standard
here. A standard is more like the "qwerty" layout which you can love or
hate, the point being that the keys ain't moving around from one season
to another.
[Mmm ... TCP/IP networking might have been a better example.]
That being said, what are the points that a distro must consider to be
truely catering for sound. What are the targets for starters?
* Entertainment: Everybody will vote for this, piratebayed or not. This
is what Pulse is doing well if I have understood previous discussions.
Not as well as you might expect.
Here's what I have found after extensive testing with the latest dev
version of pulseaudio-v0.9.16-4 and jack-0.116.1 on a 2 core amd, 4GB
notebook running Fedora 11.
1. 32 bit apps will not play on a 64 bit pulseaudio easily or at all.
2. Skype, Realplayer/Helix and Flash are a pain to get working with
pulseaudio if they work at all.
3. Pulse is unstable when connected to jack.
4. If Firefox (3.5.2) is used to play an audio stream over alsa with
flash or realplayer (because they cannot get access to PA 32 bit libs)
it doesn't release the device when the stream is finished making it very
confusing/frustrating when other apps don't work even though no sound is
running on the system and forcing the user to close.kill firefox in
order to get access to the device.
5. Gnome-volume-control is unstable, buggy and misleading at times
although it mostly works well.
6. Disconnecting jack apps and playing audio through PA while connected
to jack can bring down the whole system including the jack and the alsa
drivers but usually just PA gets fried which is mostly acceptable while
testing but useless for real world cases.
7. If alsa goes down or is restarted audio settings on my hda-intel
onboard device are often either not saved correctly or not reinstated
correctly.
8. SELinux can get in the way and users may need to be manually assigned
to PA groups.
Kjetil has reported better performance with a more powerful machine but
my machine is certainly not a pig so things are pretty bad for most
"normal" users.
* Entertainment production: Perhaps only 10% of the
population will find
this important, though 10% is still a million Linux users or so. This is
what Jack is aimed at and works as advocated IFF you have an RT-kernel,
else you are pretty much fried ...
--> Should an RT-kernel be marked as a dependency for Jack? I would say
so.
Basically in this case we have jack and it works very well for audio but
if combined with video there are several usability issues that crop up
as many of the video apps want to use jack but if PA is running that is
not possible on all current distros except maybe 64Studio which ships
with jack2.
* Serious Gaming: I have no idea what the status of
this point might be
these days.
I guess a lot of games currently fall under the wine banner in which
case they will may have the same problems as skype, etc... I'm not sure
how well integrated the wine pulse plugin is as I have never used it.
However we also have jackbridge and that works very well for
transmission with energyXT and VSTHost.
Patrick Shirkey
Boost Hardware Ltd