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