Re: [LAU] Migrating to 64-bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jun 17, 2007 at 10:35:51PM -0500, Jack O'Quin wrote:
> On 6/17/07, Ken Restivo <ken@email-addr-hidden> 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@email-addr-hidden> 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.

Thanks.

Hmm. If there are issues with pointer size, I'd expect that a 32-bit chroot wouldn't work either.

The correct solution would be to fix the languages to make them 64-bit safe, but as you know that is a non-trivial exercise.

I will make a note in to try these languages again sometime in 2009, and see if by then they either are 64-bit safe or JACK would be able to accomodate them with concurrent use of 32-bit/64-bit libraries at that time.

Thanks again!

- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGdhcve8HF+6xeOIcRAjjuAJ98gj7xo+hBZnXxy4pB9t6C4YJiSgCggyQP
AftRKJWGqXCNT/A8ACImbiw=
=tsXS
-----END PGP SIGNATURE-----
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
Received on Mon Jun 18 12:15:01 2007