[pulseaudio-discuss] pulseaudio error message

[Lennart Poettering]

On Fri, 07.08.09 23:16, Patrick Shirkey (pshirkey at boosthardware.com) wrote:

>
>
> On 08/07/2009 11:01 PM, Colin Guthrie wrote:
>> 'Twas brillig, and Patrick Shirkey at 07/08/09 11:41 did gyre and gimble:
>>> I was having this same issue when running the default install from  
>>> Fedora 0.9.15 before I upgraded to 0.9.16.
>>>
>>> Can you recommend which steps I should take to ensure that the 32 bit 
>>> lib and 64 bit lib will work together?
>>>
>>> It seems that even the Fedora packagers are having trouble with this  
>>> step.
>>
>> I'm afraid I'm not a fedora guy. On Mandriva we just install both  
>> lib64pulse0 and libpulse0 (they are installed to different paths)
>>
>> There should be nothing tricky about this, but if you are building  
>> from source rather than using packages, you'll need to either have  32  
>> bit chroot to build the 32 bit version or use some "linux32" style  
>> wrapper to the configure/make commands (and have the relevant 32-bit  
>> build deps installed).
>>
>> Col
>
> That doesn't sound too difficult or frustrating at all ;-)
>
> 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.

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.

> 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?

Yes, that's the idea.

> Will the 0.9.15 32 bit packages above be compatible with 0.9.16 64
> bit?

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.

> Is there another way to enable this to work similar to the ndiswrapper  
> approach for the older flashplugins?

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?

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.

> 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.

"Normal" users should use distributions, not roll everything
themselves...

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4