Re: [LAD] linux audio standards base?

Well spoken Arnold.

The bigger picture here is the conditioning computer users have been
subjected to from the first moment Blinky Bill attached a mouse to a
box.
As one who spent most of his working life struggling with
"professional" audio and midi apps in a win and mac environment,
before i got to the present day, it was apparent ten years ago that
switching to 64bit as viable evolution from 32bit wasn't going to
happen because it would have required 1) a lot of rewritten software
for little apparent profit, and 2) windows changing their tune, which
wasn't going to happen, because of little apparent profit. So users
all over the planet got suckered into thinking 32bit
was....sufficient.

It still goes on, and in our little slice of the planet, it's a
tragedy, because the majority of users are still stuck in that "32bit"
paradigm. I think we all know that if everything switched to 32 bit
all of a sudden, it would take about a week for most to get
acclimatised, and we'd be off again. For too long we were stuck with
messy workarounds to try and extract more memory use from 32bit
setups, including the infamous /3gb switch in win that either worked
or toasted your setup, often in the same week.

As a living example of the difference between 32bit and 64bit in my
particular working environment, i only have to cast my mind back to my
gigastudio time, in multiple boxes, to the present day, where more
gets done in one box. 64bit.

Again, this seems to be a discussion of serious use versus domestic
use, and our old friend PA has raised his head again.

I'll ask the obvious question here.
Jackd is often hammered as a RT only option, yet there are users who
have it in non RT environments. PA is used in a non RT environment.
The figures for performance, in this particular case seem in favour of
Jackd for stability, ease of use, and ability to take pretty well
everything thrown at it.

Why then did the fairly rapid decision get made to adopt PA, and not
the more obvious and united potential solution to port apps to jack,
and incorporate a "safer" setting in jack for those whose appetites
are for desktop fare?

It is, as Arnold rightly said, the 21st century, and why, after the
plethora of posts over the last 12 months bemoaning the sound
challenges and lack of cohesion in the linux world, did yet another
fracture appear, as one gang sought to impose "their" particular
solution? Had all those devs jumped in and worked at a total solution,
we'd all be swimming in cream now, and the rest of the computer world
would be sick with envy, given the far greater potential for a great
time in linux.

32bit versus 64bit isn't about memory, or processor, or anything else
but continuing the urban myth that it's "better to use 32bit for
desktops." It's nonsense. It's about the stranglehold on the market by
one company who won't take the jump, because they won't make enough
cash out of it. Following this trend only further perpetuates the
myth, and breathes continuing life into a format that reeks of
rightfully aromatic extinction...

2 roubles worth, as always,

Alex.

On Sun, Aug 9, 2009 at 10:56 PM, Arnold Krille<arnold@email-addr-hidden> wrote:
> On Sunday 09 August 2009 19:06:15 Jens M Andreasen wrote:
>> On Sun, 2009-08-09 at 16:31 +0200, Arnold Krille wrote:
>> > Helloo! Please leave the 20th century where it belongs. Nowadays 64bit
>> > are normal with new computers and its a terrible waste not to use them
>> > (reminds me of "640kB should be enough for everybody").
>>
>> I have 2GB here which is twice as much as I really wanted, but the
>> smaller sticks were out of stock. The only reason I can come to think of
>> to use even more memory, is by replacing the applets from WindowMaker
>> with their Gnome counterparts, which will then run ten times slower and
>> have twenty times the memory footprint.
>>
>> What single application - apart from Mozilla - really needs more than
>> 4GB?
>
> Ardour (by the way of the os) for the cache of the soundfiles.
> Linuxsampler (by the way of the os) to hold more of the samples data in
> memory.
> Aeolus (by the way of the os) to cache the generated samples.
>
> The only thing to make disk-access faster apart from faster disks and
> controllers is to have more memory for caching. And the more, the better.
>
> And please don't start arguing why you should use 64bits if all is well with
> 32bits. That is exactly the kind of argumentation the citation above came
> from. And here is another one: "I think 5 computers is enough for the while
> world". (Luckily the world didn't listen to neither of these two guys.)
>
> Have fun,
>
> Arnold
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>

-- 
www.openoctave.org
midi-subscribe@email-addr-hidden
development-subscribe@email-addr-hidden
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev