Re: [LAD] linux audio standards base?

From: Patrick Shirkey <pshirkey@email-addr-hidden>
Date: Sat Aug 08 2009 - 09:44:24 EEST

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sat Aug 8 12:15:02 2009

This archive was generated by hypermail 2.1.8 : Sat Aug 08 2009 - 12:15:02 EEST