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.

It would be fairly simple if there was a pulseaudio solution similar to nsplugin wrapper for all 32 bit binary apps to be plugged into. The other option I have is to build a 32 bit version of the pulse libs for my machine. I haven't had time to work out exactly how to do this yet. Colin Guthrie has provided some tips on the pulse list which I may get time to look into further in the next few weeks. Technically this is already handled by the Fedora packaging team but the versions of pulse in the Fedora packages is 0.9.15 and the dev version is 0.9.16 and there is a known incompatibility to be worked around as well as unknown bugs which mean I need to build the 32 bit libs myself.



  

    
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.
    

  

  

Here is one thing I don't like either. The layout and ordering  of the
volume controls are unrelated to the routing and how the controls are to
be used.

Like this would make some sense:

[Front][Center][LFE][Side][Surround] [Master] ¦ [Mic 1][Mic 2][Line] ...

But like this isn't really helpful:

[Front][Front Mic][Front Mic Boost] ... ... ... [Microphone] ...


Where one 'Front' is the placement of the input jack (on the box) and
the other 'Front' is where you would place your speakers (if that is
what the port is used for.)

The layout and order is inherited from the ALSA driver who does not know
shit about the meaning of the labels, at least not much :)

  

  

    
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.
    

  

  

That sounds really serious. You mean like a frozen machine or just
inexplicable silence?

  







This machine stays up but the audio drivers did fall over a couple of
times. In this case the silence wasn't inexplicable as I was carefully
monitoring the whole system but I imagine it would be very frustrating
for a non technical user if they were using pulse->jack in it's
current state.







Cheers.






Patrick Shirkey
Boost Hardware Ltd