<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> On 08/07/2009 11:26 PM, Lennart Poettering wrote: <blockquote cite="mid:20090807132634.GC8013@tango.0pointer.de" type="cite"> <blockquote type="cite"> <pre wrap=""> These are the packages that are available on Fedora 11 ------------------------- pulseaudio.x86_64 : Improved Linux sound server pulseaudio-esound-compat.x86_64 : PulseAudio EsounD daemon compatibility script pulseaudio-libs.i586 : Libraries for PulseAudio clients pulseaudio-libs.x86_64 : Libraries for PulseAudio clients pulseaudio-libs-devel.i586 : Headers and libraries for PulseAudio client development pulseaudio-libs-devel.x86_64 : Headers and libraries for PulseAudio client development pulseaudio-libs-glib2.i586 : GLIB 2.x bindings for PulseAudio clients pulseaudio-libs-glib2.x86_64 : GLIB 2.x bindings for PulseAudio clients pulseaudio-libs-zeroconf.i586 : Zeroconf support for PulseAudio clients pulseaudio-libs-zeroconf.x86_64 : Zeroconf support for PulseAudio clients pulseaudio-module-bluetooth.x86_64 : Bluetooth proximity support for the PulseAudio sound server pulseaudio-module-gconf.x86_64 : GConf support for the PulseAudio sound server pulseaudio-module-jack.x86_64 : JACK support for the PulseAudio sound server pulseaudio-module-lirc.x86_64 : LIRC support for the PulseAudio sound server pulseaudio-module-x11.x86_64 : X11 support for the PulseAudio sound server pulseaudio-module-zeroconf.x86_64 : Zeroconf support for the PulseAudio sound server pulseaudio-utils.i586 : PulseAudio sound server utilities pulseaudio-utils.x86_64 : PulseAudio sound server utilities ------------------------ Strange that there are no 32 bit modules. </pre> </blockquote> <pre wrap=""> Why did you expect them? We only ship 32bit versions of libraries 32bit apps might link to. However The PA server itself (and hence its modules) is only available in the native word with of your CPU, i.e. 64bit. </pre> </blockquote> Cool. Thanks for clarifying. <blockquote cite="mid:20090807132634.GC8013@tango.0pointer.de" type="cite"> <pre wrap=""></pre> <blockquote type="cite"> <pre wrap="">If I am running the 64 bit version of the Daemon and it is connected to jack will the 32 bit libs allow me to run a 32 bit app and connect to the 64 bit Daemon? </pre> </blockquote> <pre wrap=""> Yes, that's the idea. </pre> <blockquote type="cite"> <pre wrap="">Will the 0.9.15 32 bit packages above be compatible with 0.9.16 64 bit? </pre> </blockquote> <pre wrap=""> I try to keep compatibility in the protocol between versions. However there is not test suite to verify this. Also, while I am quite sure compat of the protocol for pure socket clients should work well, this might not be the case for local clients. It is expected that for local clients you update all or nothing. </pre> </blockquote> So, it's worth a shot to install them and test. Will do that now. <blockquote cite="mid:20090807132634.GC8013@tango.0pointer.de" type="cite"> <pre wrap=""></pre> <blockquote type="cite"> <pre wrap="">Is there another way to enable this to work similar to the ndiswrapper approach for the older flashplugins? </pre> </blockquote> <pre wrap=""> Not sure what you mean. ndiswrapper is a win32 compt layer for windows network drivers and flash is flash, so I don't see how this fits together? </pre> </blockquote> I meant that previous to the libflashplayer being released for 64 bit there was an option to run the 32 bit version of flash on the 64 bit platform by using the wrapper. I don't know the exact details of how ndiswrapper works. Only that it enabled the 32 bit binary to work in my 64 bit system. <blockquote cite="mid:20090807132634.GC8013@tango.0pointer.de" type="cite"> <pre wrap=""> I personally believe that multilib is a desaster and big failure. It's hard enough to keep that working in the upstream distro -- but doing that in manual builds is even worse. </pre> <blockquote type="cite"> <pre wrap="">I'm looking at this from the point of view of a "normal" user who doesn't know anything about the system other than how to find and run the application they would like to play with. My goal is to understand what exactly we are missing to make it possible for this "normal" user to have firefox running with some flash or realplayer streams, skype ticking over in the background play a few songs in totem and occasionally without having to think about it do some video editing or make some music without bringing down the audio system. </pre> </blockquote> <pre wrap=""> "Normal" users should use distributions, not roll everything themselves... </pre> </blockquote> I'm not suggesting they do but I am trying to understand what is missing from the system compared to what is actually possible. that way I have a better overview of the realities of what a normal user is up against. <pre class="moz-signature" cols="72">Patrick Shirkey Boost Hardware Ltd </pre> <blockquote cite="mid:20090807132634.GC8013@tango.0pointer.de" type="cite"> <pre wrap="">Lennart </pre> </blockquote> </body> </html>