[LAD] linux audio standards base?

[Patrick Shirkey]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20090808/4241d13d/attachment.html>