On 08/10/2009 12:56 AM, Robin Gareus wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick Shirkey wrote:
  
On 08/09/2009 10:35 PM, Kjetil S. Matheussen wrote:
    
On Sun, 9 Aug 2009, Patrick Shirkey wrote:

      
On 08/09/2009 10:12 PM, Kjetil S. Matheussen wrote:
        
On Sun, 9 Aug 2009, Patrick Shirkey wrote:

          
On 08/09/2009 08:12 PM, Kjetil S. Matheussen wrote:
            
Patrick Shirkey:

              
On 08/08/2009 09:57 PM, Jens M Andreasen wrote:

                
On Sat, 2009-08-08 at 16:44 +1000, Patrick Shirkey wrote:



                  
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.


                    
These two items are related, right? Does it go away with a
32bit/extended kernel?



                  
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.


                
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.


              
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.
            
No, as I said, the solution is very simple: Don't install a 64 bit 
OS. That's what's causing your problems, apparently.

          
Oh, I get you now.

So are you advocating that the official recommendation of LAD is not 
to use a 64 bit system?

        
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.

      
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.

    
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.


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.

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.

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.

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?

After all we (LAD) are the ones who designed it so we are best placed to recommend how it should be best configured.


For example:

- A distribution should attempt to run jack as the default audio server.
- Pulseaudio should connect to jack by default and fall back to the alsa layer if jack is not running.
- Closed source binaries should provide flexibility for changing the audio library path and not be hardcoded to /usr/lib/





Patrick Shirkey
Boost Hardware Ltd