On 6/17/07, Ken Restivo <ken@xxxxxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, Jun 17, 2007 at 07:12:54AM -0500, Jack O'Quin wrote:
> On 6/17/07, Tim Blechmann <tim@xxxxxxxxxx> wrote:
> >On Sat, 2007-06-16 at 22:41 -0400, carmen wrote:
> >> On Sat Jun 16, 2007 at 10:30:48PM -0400, Brett W. McCoy wrote:
> >> > I am getting a 64-bit system later this week and will be installing
> >> > Fedora Core 6 x64 and it will be replacing my current studio DAW,
> >> and
> >> > I will be mocing my Delta1010 audio interface over to this new
> >> machine
> >> > also. Are there any general 'gotchas' with regard to Linux audio
> >> and
> >> > 64-bit hardware?
> >>
> >> not with the hardware. with the software, the VM based scientific
> >> audio stuff tends to be broken - at least SCLang, PD, and Chuck. not
> >> sure about CSound. so if youre into that stuff, youll need a 32bit
> >> chroot. or you could control scserver from haskell or scheme...
> >
> >is it possible to connect to a 64-bit jack from within a 32-bit chroot?
>
> No.
>
> Maybe someday, but it's hard and has not been high-priority.
Something that is on my TO-DO list but is likely never to get done, is to create a bi-arch Debian package of jackd and a couple of its dependencies. Then, one may build and run ChucK or SClang using 32-bit libjack, without a chroot.
This is how many non-64-bit-safe programs run today.
$ find /usr/lib32/ -type f | wc -l
714
So, on my Intel Core 2 Duo Debian Sid system, roughly 714 libraries have 32-bit alternate versions, for use by apps that are not 64-bit safe. This is a tiny percentage compared to the 64-bit libraries, by the way:
$ find /usr/lib64/ -type f | wc -l
13443
But, I'd propose that a simultaneous installation of 64-bit and 32-bit versions of libjack, each in their appropriate location in /usr/lib32 and /usr/lib64, would be cleaner and more transparent for the user than creating chroots and such.
There is no point in doing all that until we release a version
of jackd that can handle both 32-bit and 64-bit clients accessing
the same shared memory segments. Right now that is not
possible. There are some pointers, for example, in shared
memory. That will not work and must be changed. The jackd
modifications required are doable (IMHO), but definitely not
easy.
To date, there have been no large number of requests on
jackit-devel or on LAU for this feature. So, people tend
to classify it as a post-1.0 work item.
--
joq
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
