[LAU] Migrating to 64-bit
ken at restivo.org
Mon Jun 18 01:25:03 EDT 2007
-----BEGIN PGP SIGNED MESSAGE-----
On Sun, Jun 17, 2007 at 10:35:51PM -0500, Jack O'Quin wrote:
> On 6/17/07, Ken Restivo <ken at restivo.org> 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 at klingt.org> 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
> 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.
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Linux-audio-user