abel, at some current opportunity on a system which actually could be not named *reference* it indicated to be about 30%. on a straight forward configured system it should be even less.
to have a sample library at 48 kHz would in turn bring up the question why not 44.1 ...
christian

sure, I understand your point, but even less then 30% is still a lot (lower buffer sizes, lower latency) and thinking about which customer group can actually afford the whole SC, I would bet on film composers.

Why don't you just release a raw 48k version to the main suppliers in LA (West LA Music, Guitar Center) and they would take care of the distribution. No dvds to release, no reprogramming, just a simple conversion of the sample pool.

@Abel said:

Why don't you just release a raw 48k version to the main suppliers in LA (West LA Music, Guitar Center) and they would take care of the distribution. No dvds to release, no reprogramming, just a simple conversion of the sample pool.

this statement gave me a good laugh ... let me dig out my remaining diplomacy to say: i think they are already buisy enough selling and delivering the items, occasionally installing and supporting a library, i can't imagine anyone would find the time to configure, compile and test the instruments ...

the rough figure of 30% has been noticed by sheer chance on a certain configuration, as mentioned it should usually be less.
basically the CPU load for ViennaInstruments is very low - as example 40 instances on a quad core XEON (2 x dual core) on XP hosted in cubase did use not even 10% of total CPU, so actually 30% more would be tolerable ...
christian

wrong choice of words...
by "raw" I meant vsl .dat format recompiled by the Vienna team, but released the OEM style, without a box. And I'm not saying it should be free.

and what buffer sizes were used for the configuration you've mentioned?
I'm on an 8-core Mac Pro and for 30 instances I cannot go below 512-sample buffer (RME Fireface800).

regarding the *raw* version: you have to know the samples are stored in 96 kHz 32bit, so every other format would need a resampling cycle (for which VSL is using a proprietary tool to keep the high quality) and i guess nobody here would voluntarily process the almost 1.5 mio samples and the following steps ...

buffer size ... hmm, this has been an ASIO 2 driver and i can't find a note now about the used buffer size, sorry. there are also other factors to consider and i should have mentioned the harddisks were striped sATA II (~ 4,5 ms average seektime) on an intel raidcontroller.
on an 8-core mac you should have pretty much CPU left, no?
christian

I don't understand this technical things,
but the Activity Monitor shows 35-40% of cpu use (6% User + 30%System), regardless the buffer size of 256 or 512 samples.

The only thing that really counts is the ASIO monitor (Cubase4) which overloads at 256 samples and 30 VI instances.

with 9GB of RAM and I didn't reach the ceiling yet.

ASIO overload means basically that audio data cannot be delivered *in time* to the device, which can have several reasons.
whereas formerly in most cases the PCI-bus was the bottleneck it can be any bus between your drive having stored the sample data and the audio output - a few things to consider:
- you should not record to the same drive you are reading sample data from
- make sure your drive is able to deliver the requested amount of data
- make sure you don't have any other firewire device on the same FW-bus
- latest drivers, audio settings properly configured (eg. not 2 applications share ASIO)

though you might not like another technical hint: one stereo voice needs 176 kB/s, in certain cases (eg. crossfades) even more and you should not expect signifcantly more than 25 MB/s throughput from a single harddisk at average access for sample streaming. do not rely on marketing-speech like *up to 100 MB/s* or similar, such figures are meant as boosts from the cache.
christian

the numbers I've quoted were in "stop" mode (not playing),
so there's nothing to read yet...

when I hit play the ASIO meter jumps up only a little.

anyway I have 4 SATA2 drives - system, projects/audio, vsl1, vsl2
+ video on ext. FW800

the Fireface runs on FW400

@Abel said:

48k is the film industry standard

Not too sure about that...

J.

@Abel said:

48k is the film industry standard

Not too sure about that...

J.

please elaborate.

jerome, i remember at least earlier media compser and symphony have been always kind of troublesome (in detail the meridien board) with 44,1, especially if somewhen (eg. for rushes) DV or digiBETA was in the game - but i'm not at all up to date here ...
christian

abel, unfortunately we continue to be technical ...
it is said that the firewire controller has only different ports and does internally not seperate the FW 800 and the FW400 bus (relying on the built-in downword capability instead of having different controllers) - it would be at least worth a try to reverse connections, i.e. fireface 800 on the FW800 and the harddisk on FW400. for video streaming the FW400 is still faster than data could be delivered from a single harddisk.
in no case i would chain the devices.
usually the RME fireface is not very sensitive having also a harddisk on the same controller, but who knows ....
christian

http://techreport.com/reviews/2006q1/gigabyte-iram/index.x?pg=1">http://techreport.com/reviews/2006q1/gigabyte-iram/index.x?pg=1

To add to the discussion....

yep, great concept - we already have some here (though it has not been easy to find a vendor) ... but my approach was more to use this device for the pagefile and i don't get it now how it might be related to this thread?
christian

@Abel said:

please elaborate.

You didn't elaborate yourself... [:)]

But I work in the film industry as a film composer / orchestrator / technician and out of all the people I know or worked for, I can say 48k is far from being the "industry standard" you're refering to.

Some people work solely in 44.1k, some in 48k, and some switch between various sample rates.

It's just not like *everybody* is working at 48Khz... it's as much a standard as 44.1Khz.

Hardware-wise, 48 kHz is defacto the accepted standard for audio in the video-world. This is not due to the higher audio-standards in this part of the business, as one might assume (quite the contrary!), but due to the fact that 48 kHz encodes much easier in a video-stream.

Of course, people working _for_ video in the audio-world often use 44.1, which has to get converted to 48 at some point, though.

(Edited for typos [:P])

@Dietz said:

..., which has to get coverted to 48 at some point, though.

Yes.

If you don't have to run against a 48k digital clock, refrain from realtime upsampling.

You will get far better results converting the finished mix with a high order interpolation tool.

In realtime operation there are quality vs speed tradeoffs.

/c

@Dietz said:

Of course, people working _for_ video in the audio-world

who cares about anyone else? [:P]

J.