<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
On 08/10/2009 12:56 AM, Robin Gareus wrote:
<blockquote cite="mid:4A7EE3A8.30804@gareus.org" type="cite">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Patrick Shirkey wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 08/09/2009 10:35 PM, Kjetil S. Matheussen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Sun, 9 Aug 2009, Patrick Shirkey wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 08/09/2009 10:12 PM, Kjetil S. Matheussen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Sun, 9 Aug 2009, Patrick Shirkey wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 08/09/2009 08:12 PM, Kjetil S. Matheussen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Patrick Shirkey:
</pre>
<blockquote type="cite">
<pre wrap="">On 08/08/2009 09:57 PM, Jens M Andreasen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Sat, 2009-08-08 at 16:44 +1000, Patrick Shirkey wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">These two items are related, right? Does it go away with a
32bit/extended kernel?
</pre>
</blockquote>
<pre wrap="">I haven't tested with a 32 bit system. I'm not sure if I will get
the
time for that. I don't think in this case it has much to do with the
kernel. I think it is because pulse is compiled for 64 bit and
the apps
are looking for 32 bit libs.
</pre>
</blockquote>
<pre wrap="">Well, there's your problem. It's great that you try out new
software though, but of course then you'll get more stability
issues as well.
</pre>
</blockquote>
<pre wrap="">To clarify, I have found that is difficult to get 32 bit apps to
connect to a 64 bit build of pulseaudio but these apps don't cause
stability issues with pulse. The problem is they just don't
connect. I can still run them directly over the alsa layer but that
locks the device in a standard Fedora 11 setup. I believe this
would affect alot of "normal" users so I would like to find a
workable solution that can be recommended to all packagers as a LAD
standard.
</pre>
</blockquote>
<pre wrap="">No, as I said, the solution is very simple: Don't install a 64 bit
OS. That's what's causing your problems, apparently.
</pre>
</blockquote>
<pre wrap="">Oh, I get you now.
So are you advocating that the official recommendation of LAD is not
to use a 64 bit system?
</pre>
</blockquote>
<pre wrap="">I'm not sure what you mean by official recommendation, but from what
you describe, 64 bit systems can cause problems when using flash and
pulseaudio.
</pre>
</blockquote>
<pre wrap="">
64 bit libflashplayer is hard coded to use /usr/lib/ and on Fedora 11
the 64 bit alsa-libs live in /usr/lib64/. I'm not sure that is a problem
with a 64 bit system, libflashplayer or just Fedora's packaging policy.
I am guessing that it affects a lot of people.
The stability issues I have seen are not related to libflashplayer. That
issue is more of a usability issue in that firefox/libflashplayer
doesn't release the alsa device which makes it hard to use jack or other
apps that require access to the alsa device.
</pre>
</blockquote>
<pre wrap=""><!---->I used to be annoyed of this very much and learned to love firefox'
flashblock plugin for that matter. However using jackplug in .asoundrc
resolved this issue quite nicely for me and I don't use pulesaudio on
any system here.
Anyways, we're getting way off-topic from discussing a
linux-audio-standards-base; although discussion and diversity here shows
that it may be impossible to do so.</pre>
</blockquote>
<br>
<br>
I think it is a part of a wider issue that a standard could be used to
correct. I have a feeling that if we approached Adobe with an open
letter saying that we as the flag bearers for Linux Audio highly
recommend they provide a flexible path for the 64 bit lib then it would
probably get to the right people.<br>
<br>
A secondary issue that you have brought up here is that jack is very
capable of handling many things for the desktop that pulseaudio is
currently failing at on a 64 bit system and many people prefer to use
jack instead of pulseaudio for that reason.<br>
<br>
However pulse is being shipped as the default sound server for all
major distros. There is a major disconnect here in that jack is not
designed to be the default server for a desktop audio system but it
does fufil the purpose quite well in many ways whereas pulse is
designed to be a desktop audio server but it doesn't allow for
professional apps to connect to jack easily at the moment.<br>
<br>
Should we not be recommending a set of guidelines for the distro
packagers to attempt to follow and not let them dictate to us how the
sound system should be organised?<br>
<br>
After all we (LAD) are the ones who designed it so we are best placed
to recommend how it should be best configured.<br>
<br>
<br>
For example:<br>
<br>
- A distribution should attempt to run jack as the default audio server.<br>
- Pulseaudio should connect to jack by default and fall back to the
alsa layer if jack is not running. <br>
- Closed source binaries should provide flexibility for changing the
audio library path and not be hardcoded to /usr/lib/<br>
<br>
<br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">Patrick Shirkey
Boost Hardware Ltd</pre>
<br>
</body>
</html>