-----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@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. 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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
