Since jack-audio-connection-kit 0.116.0 it is now possible to load 32bit libjack clients into a 64bit jackd server. This requires that the 32bit libjack also has at least version 0.116.0 (libjack.so.0.0.28) The current version in the soundlibs package is quite useless without having a 32bit jackd, and the best would be to update the jack libs in the emul package. Previously compiled jack clients do not have to rebuild, so it should be quite safe to update. Reproducible: Always Steps to Reproduce: 1. start 64bit jackd 2. try to load a 32bit jack client app Actual Results: doesn't work Expected Results: could work if 32bit libjack is recent enough
Maybe 0.116.0 should be stabilized first :-/
Hi, I'm sorry, but I'm going to have to be an asshole there :) Emul-linux-x86-soundlibs is a horrible hack that misleads people and breaks audio systems for - at first sight - obscure reasons. The only fix I see here is to remove jack from this "sort-of-metapackage" that groups things that have nothing in common. And for a real life example, see this thread on the jack list : http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2009-July/003252.html The last email here details what happened : http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2009-July/003257.html Packaging libjack without the associated server is pure heresy. It causes unnecessary headaches for jack devs. Please, let the people who know jack handle the 32bit matter. This should be handled inside media-sound/jack-audio-connection-kit.
Here is the message I posted on jak-devel. I hadn't noticed the list archives were private :p _____________________________________________________________________________ Ok, I just got to the bottom of the story. Hang on there, it'll get very dirty. petern_ on IRC gave me an interesting hint. "invalid command line switch (-l) generally means you have both jack1 and jack2 libs around". Of course my first reaction was to explain that, hehehe, I'm not so stupid as to install both on the same machine... But then I checked what I had on my system. ldconfig -p | grep jack... Just out of curiosity. And here it was. A 32 bit jack library from a package named "app-emulation/emul-linux-x86-soundlibs". In other words, the packages you use on a multilib system for 32bit compatibility . what happens is that on gentoo64, wine is compiled as a 32bit applications and thus makes use of the compatibility libs. emul-linux-x86-soundlibs obviously contains a 32 bit jack1 lib incompatible with my 64 bit jack2 server. I'll go report this to the gentoo portage maintainers. That's a very nasty bug... _______________________________________________________________________
We won't include it in emul packages until a newer media-sound/jack-audio-connection-kit is marked stable If you think it's ready to go stable, please open a new bug report requesting that and leave that bug number here for depending on it Thanks
Request for marking media-sound/jack-audio-connection-kit-0.118.0 as stable recorded in Bug 307559.
I need to use wine with jack, but is does not work... ~ $ winecfg err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element cannot read response from jack server (No child processes) cannot read response from jack server (No child processes) err:wave:JACK_OpenWaveOutDevice jack server not running? err:wave:wodOpen JACK_OpenWaveOutDevice(0) failed I run jack 0.118 (I tried with jack2 too).
I "solved" modifying the proaudio's jack-1.9.5 ebuild to configure with --mixed parameter, which builds also 32bit winelib.
JACK 0.118.0 is marked stable. How 'bout a new emul package? :D
It will be then included in the next round, that would be released when other apps included in different emul packages also need updating (and when I have enough time ;-))
