Welcome to the Piano World Piano ForumsOver 2 million posts about pianos, digital pianos, and all types of keyboard instruments
Join the World's Largest Community of Piano Lovers
(it's free)
It's Fun to Play the Piano ... Please Pass It On!

I also suspect latency settings have a major affect on how people perceive the playability of sampled pianos vs modeled pianos, which is a much bigger problem with sampled pianos (because of drive access time to the samples).

I disagree with this. The latency of disk-streaming software pianos has almost nothing to do with the latency of the disk. The reason is that the very first part of all the samples is stored in RAM, and so when you play a key, the first part of the sample is already there, ready to play. The rest of the sample, on disk, is simultaneously read in the background, so that when the first bit has finished being played, the next bit is ready, providing seamless playback.

Now, I know there can be secondary affects. I am well aware that you observed an improvement in polyphony when you increased the sample buffer size, and of course when you increase the sample buffer, latency increases. Generally, though, I assert that the latency of software pianos is by and large seperate to the latency of the storage system.

Greg.

But that's the whole point. You have to increase the buffer size to accommodate more voices because you have to read more samples off the disc. Not all of the sample is pre-read and stored in RAM. Any software piano program manual will tell you this and it is easy to show by trying it. Reduce the number of voices to a small number and you will see that you can greatly reduce the sample buffer size and hence reduce the latency. The amount of buffer needed for processing samples is small compared to the size of the buffer needed to accommodate reading the samples. Use an SSD vs a hard drive and the effects on necessary buffer size (latency) are obvious.

Setting up the velocity curve correctly for use with a given keyboard is all-important. It radically changes the timbre range and response when playing. I suspect many people's objections to the "best" sampled pianos are because the velocity curves are not optimized properly for their keyboard.

Very good point.

Jamesx

Oh boy. I always thought it was safest to leave it linear to not interfere with the velocity curves of the DP How does one even go about getting the right setting? Is it the same for all 88 keys?

Macy: I still think that you are describing a very secondary affect. The process of streaming audio to the audio interface is seperate to the process of reading the sample data.

Your original comment, I think, could easily be misconstrued by some people to mean that if they have say, a drive with a 20ms access time, and they exchange it for a drive with a better/faster access time of, say, 10ms, that their latency will be halved. IMHO, they will not necessarily notice ANY change in latency. What they will notice will probably be a reduction in polyphony, because the latency directly affects the throughput that the disk is capable of sustaining.

Just for example, I am absolutely confident that if I were to switch from my internal SATA 7200rpm drive, to an external USB drive of 5400rpm, that I could leave my ASIO buffer at the best/minimum size of 128 samples. I would certainly notice a reduction of polyphony, and perhaps if I were to really push the disk, I might be able to eek out a bit more polyphony my increasing the ASIO size, but I really think that's a secondary affect.

The reason the pre-load buffer has an effect on the polyphony is that as the pre-load size is increased, the amount of data that the sample player reads each time, from a given sample file, increases in proportion to the pre-load size. The larger this read request size, the higher the throughput of the disk, and hence the higher the polpyphony. (with the absolute maximum throughput being the sequential transfer rate, but that can never be reached) (note that I'm referring to Kontakt in particular in all this - that's the software I have looked at most carefully so far)

Macy:I've just tried my external 5400 rpm drive, using Kontakt 3.5, and the Sampletekk White Grand. OS is Windows 7, CPU is a mobile Core 2 Duo @2.4GHz. (i.e - nothing at all special) I used the maximum Kontakt preload (240k) without varying it all yet. It was just a quick test, and I did not do it as carefully as I should. However, I have not yet witnessed any improvement in polyphony when increasing the ASIO buffer size. I started out on 128 (@44.1kHz), and found that I get very roughly 60 voices. I then quadrupled the ASIO size (to 512 samples), and the polyphony stayed roughly the same. I can't be sure whether there was a slight improvement or not yet - I need to test more carefully using MIDI files.

Moreover, I have not heard any glitches either. Typically, when the ASIO buffer size is too small and causes problems, little clicks can be heard. What I do notice is voices being dropped - i.e - a note will be sounding, and then it will suddenly stop when it shouldn't, and it never comes back. I have found that this is the typical behaviour of the disk being maxed out. Naturally I watched the voice count in Kontakt, and the dropouts did correspond with a reduction in the displayed voice count.

And, of course, the perceived latency when I use an ASIO size of 128 samples, when I use the slow disk, is nice and fast - just like the internal disk.

I stress that I am already using the very best (smallest) ASIO size available on my audio interface, despite the fact that I do not have an SSD. And this is using a pretty old laptop.

Greg.p.s As I keep saying to anyone else who wants to do some testing - it is imperative to either reboot between each test, or clear the disk cache inbetween each test. Otherwise, there is a great risk of falsely high polyphony results, due to the extra caching that occurs by virtue of the operating system's disk cache. Try and play the same performance each time you do the test, and clear the disk cache inbetween each test. The easiest way to clear the disk cache on Windows is to use the Sysinternals utility called "Rammap", and use the command Empty | Empty Standby List.

p.p.s Note that the White Grand appears NOT to be using any sample compression. (I think if I were to upgrade Kontakt, I would actually be able to save the instrument with the samples being compressed). I realise that you brought to our attention that the mainstream Kontakt pianos almost certainly use compression, greatly reducing the data rate from the disk. (big selling point!)

Macy:I've now tested it more carefully, using MIDI files, and ensuring that each Note-On maps to a seperate sample file. So, the polyphony number displayed by Kontakt equates directly to the number of simultaneous disk streams.

The result for this particular 5400rpm USB disk, for this specific test and for this specific layout of the sample files on disk, is very close to 51 streams.

Increasing the ASIO buffer size still does not make any difference. (or if it does, it is a very tiny difference that I haven't bothered to test for yet)

Reducing the pre-load by half (240k down to 120k) makes it fall over immediately when I feed it the same 51-voice MIDI file. (which is exactly what I would expect) I didn't determine the new lower polyphony for this reduced pre-load.

I still did not hear any glitches that I would associate with a problem with the ASIO buffer size - only complete note dropouts, due to the disk not being able to keep up.

All I can say is that this is all behaving exactly how I would have expected. ;^)

Aeons Holle, I am badly occupied for a week or so and cannot do much experiments nor document this in detail. Some qualitative remarks: I think the beneficial effect I definitely have and enjoy can be attributed to the mere fact to have a more processed sound out of the spatialiser. This type of processing is probably adding some phase changes/enrichments to the by compressed phase image out of the mics. (Beside of using a moderate convolution reverb provided by the instrument like "Jazz Club").

Just my assumption. This very positive effect is definitely there, my son has noticed is also immediately. It is not a sudden pleasent "wow" at the first moment, by far not, but the sound gets wider, you get a background feeling for the sound source and the previously tiring intrusive presence of punctual sound source is tamed, getting a context. Is a matter of playability also.

I don't have Ivory, there is the original "narrow perspective" not a bottleneck or to a lesser degree and therefore it brings not that much improvement.

Another interesting observation I could make with Kontakt sampled instruments: to change interpolation algorithm of Kontakt (HQI) to perfect (instead of standard, high) an to chose 192 KBit Bitrate for my EMU0404 USB I could get some minor audible improvement, but this one was not thus emphasised as this effect of the spatialiser. (I am constantly retuning my instruments, so the effect of HWI with normal stretch tuning could be even lesser.)

Some other experience with Galaxy and Reaper (or perhaps other DAW with spatialiser)?

Thanks for the explanation.If I have time I will try this experiment with Vintage D instead of Ivory.

Macy: I still think that you are describing a very secondary affect. The process of streaming audio to the audio interface is seperate to the process of reading the sample data.

Your original comment, I think, could easily be misconstrued by some people to mean that if they have say, a drive with a 20ms access time, and they exchange it for a drive with a better/faster access time of, say, 10ms, that their latency will be halved. IMHO, they will not necessarily notice ANY change in latency. What they will notice will probably be a reduction in polyphony, because the latency directly affects the throughput that the disk is capable of sustaining.

Anything can be misconstrued, and that is what you are doing here. I never said what you are saying above. Latency is NOT directly proportional to disc access time. Latency depends on the audio buffer length plus any additional delays in sample processing. IF you can reduce the audio buffer length, you will reduce latency. There are many factors (including the voice limit you set, additional processing such as convolution reverb used, size of pre-load buffers, your CPU speed, the disc access time, the disc interface rate limit, etc. etc.) that affect the size of the audio buffer you need to use, and therefore the latency that you need to use.

What I said was that latency can be a much bigger problem with sampled pianos than modeled pianos because of drive access times. IF disc access time is limiting the number of voices that can be played (whether voices are cut off prematurely by the program - a less objectionable but still objectionable problem, or if slow disc access actually creates dropouts) then using a longer audio buffer will eventually fix that problem (because there is more time to read the disc). So if one uses a longer audio buffer to solve a slow disc problem they will then get longer latency - and longer latency affects the feel of playing a software piano, even before it is overtly recognizable as an audio delay.

This following is simply an undeniable fact. If you get Slow Disc warnings on your software piano (they flash the words Slow Disc on some programs) you will be able to stop them, and the objectionable audio effects caused by them, by increasing the audio buffer length to some larger length, which of course increases the latency. I wrote a lengthy post about doing this and provided information for the effective disc reading rates of both a hard drive and SSD in another thread. I also provided data on how many additional voices could be used with the SSD vs the hard drive at the same audio buffer length (same latency), or that I could reduce the buffer length (reduce latency) by using the same number of voices with the SSD vs the hard drive.

I also indicated somewhere in the same thread that Ivory II (as well as some other pianos that use large sample libraries) must stream from disc at much faster average rates than Kontakt. The Ivory II American D has 49 GB of samples compared to the 4.23 GB for the Vintage D. The Kontakt Vintage D never exceeded about 7 MB/s from the disc using 256 voices on my Mac, but Ivory II required about 60 MB/s with 80-100 voices (voices are not counted the same by Ivory II and Kontakt). So in the experiments described in your other replies in this thread, your voice limits are probably not being limited by disc access times, but by processor speed. As I noted in that thread, I've never seen a Slow Disc indication or issue with a Kontakt piano and a mechanical hard drive.

In any event, the simple fact that Slow Disc messages (if you have that problem) can be eliminated by increasing the audio buffer length makes my point that if you have slow disc access issues you may be avoiding them by using a longer audio buffer that increases latency.

But all of this is really peripheral to my original point (because you have singled out disc access as one possible cause), if the audio buffer is too long (for any reason) the increased latency will affect playability.

------

Here is an excerpt from the original comment where I posted disc access times of SSD vs hard drives with Ivory II.

Quote:

I previously ran Ivory II GP's standalone with a 128 sample buffer (44.1 kHz) and a 96 voice limit set on a 3.06 GHz Core 2 Duo iMac with the samples on a 7200 rpm Firewire 800 external disc drive. I never had "Slow Disk" messages, or the accompanying dropouts. When I added the Ivory II American Concert D, which includes a new version standalone app and AU Plug-ins, I started getting "Slow Disk" messages when the number of actual voices reached around 80 in number. It is very easy to generate 80 or more voices with this program. The samples are longer (5-8 secs in the program readout depending on the notes - the undamped top strings are the longest) on the American D than the previous Ivory II pianos, so more notes overlap even when released and there may be other differences in the newer version app as well. Bottom line, I had to increase my buffer to 256 samples (or reduce the number of voices) to eliminate the "Slow Disk" messages and accompanying audio artifacts, neither of which I wanted to do. According to my Mac disk activity monitor the Firewire 800 HD was hitting about 30 MB/s (with 80 voices) when the "Slow Disk" messages appeared, but the maximum transfer rate of the Firewire 800 HD measured well over 80 MB/s (which is expected from FW 800 transfers). So I concluded the problem was not the FW800 transfer limit, but instead the random access time of the mechanical hard drive.

So I purchased a 256 GB SSD with an external FW800 (and USB 3) interface since the random access time of the SSD is negligible, approximately 0.1 mS. Once I moved the samples to the SSD it solved the issue entirely. I was able to run up over 250 voices according to the Ivory II readout (using the sustain pedal and pressing an unrealistic number of keys) before getting the "Slow Disk" message and artifacts using a 128 sample buffer. I bought the SSD with a USB 3 interface (which is about 5 times faster than FW800) - just in case the SSD limited by FW800 didn't solve the problem.

For my normal playing with the SSD I set the audio buffer to 64 samples (below that I could generate occasional ticks and pops from maxing out the CPU) and the maximum voices at 128. At 80-100 voices, which my normal playing generated, the transfer rate measured a maximum around 60 MB/s with no "Slow Disk" messages. The SSD still measured over 80 MB/s max due to Firewire 800, but Ivory II simply didn't need to go faster with my playing.

So I want to stress the original limitation was due to the random access time of the 7200 rpm disc (5400 rpm discs have even slower access times). That had limited the number of voices I could get with a 128 sample buffer and forced me to a 256 sample buffer. With the faster random access SSD, still using the same FW800 interface, I could reduce the buffer to 64 samples and increase the voices to 128 (that was an arbitrary choice over the max voices I needed and I'm not sure of the max number of voices I could have used with the 64 sample buffer, but I got over 250 voices with a 128 sample buffer).

----

The other observation I will make is that the Galaxy Vintage D - Kontakt program streams samples at a MUCH lower rate from the disc than Ivory II. It never exceeded about 7 MB/s from the disc in my playing when using 256 voices and a 128 sample buffer. (Voices are not counted the same way by the Ivory II program and Kontakt - Kontakt counts release samples and Ivory doesn't for instance.) The Vintage D samples are shorter and I think they may also be compressed. In any event, I never had any slow disc issues with the Vintage D or Alicia's Keys (also Kontakt) using the mechanical HD.

So hopefully this information will be useful to a Mac user considering an SSD, and the big point I want to make is that the random access time of the mechanical drive was the limiting factor and not a FW800 interface (on the other hand, a USB 2 interface would have been limiting for Ivory II - probably not for the Vintage D). Finally, I again stress this information is my experience with a Mac, and may not apply at all to a PC user because the hardware, OS, and virtual piano software is different.

Anything can be misconstrued, and that is what you are doing here. I never said what you are saying above.

I agree that you didn't say it, but I think it could be misconstrued in the way I suggested. I could be wrong about that, but that was/is my opinion.

Quote:

Latency is NOT directly proportional to disc access time. Latency depends on the audio buffer length plus any additional delays in sample processing. IF you can reduce the audio buffer length, you will reduce latency. There are many factors (including the voice limit you set, additional processing such as convolution reverb used, size of pre-load buffers, your CPU speed, the disc access time, the disc interface rate limit, etc. etc.) that affect the size of the audio buffer you need to use, and therefore the latency that you need to use.

I mostly agree with all this, however my testing to date suggests that in Kontakt (in my specific config) the pre-load has no or very little affect on the required sample buffer, and hence the latency. The pre-load changes how much data is read from each sample each time a read is made, and thus it changes the number of head seeks per unit of time, which then directly affects the data rate that can be sustained from the disk. This affects polyphony, not latency. Obviously if I were to keep decreasing the sample buffer size, though, there would be a point where it would start to cause problems, because the lower the sample buffer, the higher the CPU load (more audio driver interrupts per second or whatever). I have re-tested now using an internal disk (to get data rate up, and hence the CPU usage up a bit), and even when I go down to a sample buffer of 64 samples, it still doesn't seem to affect the polyphony. (~85 voices at both 64 samples and 512 samples). I had to switch to ASIO4ALL on the internal audio interface to be able to go down to 64 - my USB audio interface has a lower limit of 128. Now, I haven't yet actually tried playing normally, for long periods of time, using a sample buffer of 64. I'm simply saying that when I was feeding Kontakt the test MIDI files (many simultaneous Note-Ons), I didn't notice any clicks/pops.

Quote:

What I said was that latency can be a much bigger problem with sampled pianos than modeled pianos because of drive access times.

I am not very comfortable with this statement at all, despite the results of your own testing. I certainly haven't experienced this yet.

Quote:

IF disc access time is limiting the number of voices that can be played (whether voices are cut off prematurely by the program - a less objectionable but still objectionable problem, or if slow disc access actually creates dropouts) then using a longer audio buffer will eventually fix that problem (because there is more time to read the disc). So if one uses a longer audio buffer to solve a slow disc problem they will then get longer latency - and longer latency affects the feel of playing a software piano, even before it is overtly recognizable as an audio delay.

The "audio buffer" is the buffer is simply a buffer that the sample player application fills with sample data, and then hands over to the audio driver. It has nothing to do with the process of reading data off the disk, except that as this buffer size is decreased, it does increase the general load on the system. If the bottleneck is primarily the disk, then by far the best way to relieve that bottleneck is to increase the disk read transfer size, which is completely seperate to the audio buffer size. In Kontakt, the pre-load size changes the disk read transfer size, and of course does not change the audio buffer size.

EDIT: Re-reading your comment here again, I think just perhaps, that you have a basic misunderstanding of the function of the "audio buffer". I completely agree that the longer the access time, the more time is needed to read the disk. However, what gives the system this time is seperate buffering to the audio buffer. Initially, it is the pre-load buffer. The audio-buffer is nowhere near large enough. When a note is first played, the first little audio-buffer-size worth of sample data is read from the pre-load buffer, immediately, without involving the disk at all. It may stream some more audio-buffer-size worth of chunks from the pre-load buffer without initiating a disk access as well. The amount of audio sent to the audio driver before a disk access is initiated would depend on the size of the pre-load buffer. At some point, a disk access would be initiated. In the mean time, audio can be continued to be streamed from the pre-load buffer. Now, when the data from disk is ready, it will be deposited into another buffer area that would behave the same as the pre-load buffer. (I think the pre-load buffer proper would always have to be maintained with the initial attack data) This data of course must be ready before the initial pre-load data (that was loaded at instrument load time) has finished being streamed to the audio driver. So, it appears to me that you may be confusing the function of the audio buffer with the pre-load buffer.

Aside from this, I re-iterate that I completely accept that there could be secondary effects. For example, the shorter the audio buffer, the shorter the time between audio driver services (e.g interrupts of some sort), and thus the more sensitive the audio streaming will be to other high priority processes & drivers. This is rather system/config dependent though. I maintain that the main reason to get a faster disk is to improve polyphony - not latency, and that's why I objected to the statement you made. (I know there are other benefits, such as faster load time & less pre-load RAM)[end edit]

Quote:

This following is simply an undeniable fact. If you get Slow Disc warnings on your software piano (they flash the words Slow Disc on some programs) you will be able to stop them, and the objectionable audio effects caused by them, by increasing the audio buffer length to some larger length, which of course increases the latency.

It is VERY deniable IMHO. ;^) You asked me to test it, and I did, and I did not find any evidence to support your assertion whatsoever! (I am not denying the results of your testing, though) When I maxed out my disk, upping the sample buffer size didn't do anything to improve it. (or should I go higher than 512 samples?) I would be keen to try Ivory on Windows. (unfortunately I don't have it)

Quote:

I wrote a lengthy post about doing this...

I've re-read the post. There is one piece of information I don't think you provided, and it might be important:Using the FW 800 disk, did you carefully determine the maximum polpyhony/disk-throughput (i.e - no dropouts and/or disk warnings) using a sample buffer of 128 samples, and then determine the maximum polyphony/throughput using 256 samples? I.e - I know that increasing the sample buffer to 256 stopped the problem, but how much better did it become?

I've managed to get a result from EWQLP. I had to introduce a time delay between each Note-On, and at the moment I'm at a whopping 100ms (0.1s). I need to look into this further, but:

The polyphony I can achieve at the moment is ~30 from my internal 7200rpm SATA drive. Cf 85 for Kontakt. Huge difference. (I believe EWQLP is 48kHz/24-bit, and my Kontakt instrument is 44.1kHz/24-bit, so not much difference there. Both are uncompressed as far as I can determine).

Once again, varying the ASIO buffer size between 64 and 512 didn't make any difference that I could detect.

I tried varying all the Play settings, but none of them made a difference either. I notice that the RAM size (down the bottom right-hand corner of the Play window) doesn't change, no matter what I do. I'm sure it USED to, so something's changed along the way. Given that the RAM size doesn't change, it could well be that Play's equivalent to Kontakt's pre-load isn't changing either, which would explain why I can't vary the maximum realisable polyphony. I am able to inspect the system to determine the disk transfer size to prove this conclusively, but I haven't bothered yet.

I am very confident that I am maxxing out the disk, because if I repeat a test without clearing the Windows file system cache, the polyphony is much higher.

I have not determined how fragmented these particular EWQLP samples are, or how closely they are all located together on disk. This can make a big difference.

EDIT: I have iterrogated EWQLP, and I have found that the disk transfer size DOES change - it changes when the Maximum Voices engine setting is changed. At the minimum setting, it reads 32kBytes at a time. At 512 voices, it still reads in blocks of 32k, however it does 9 back-to-back reads each time it reads from a given sample file, making an effective logical read size of 288k. I don't know why the polyphony doesn't improve as the Maximum Voices is increased.Regarding the RAM size display that I referred to, I suspect that I noticed it change when loading and unloading mics. I don't remember whether I ever checked to see whether it changed when any of the engine settings were changed, so please ignore my initial concern for that.

The Ivory II American D has 49 GB of samples compared to the 4.23 GB for the Vintage D.

A bit off-topic, but since this thread has gone all "technical" mode anyways, maybe some tech-guru about these things can explain how, for example, Vintage D can achieve the same (or even better) quality with it's 4,2 GB compared to 49 GB of Ivory?

Ivory is several pianos. My older version 1.7 has four pianos in 59 GB. That's 15 GB each.

The newer Ivory v2 has three pianos in 77 GB, perhaps 26 GB each.

Still, there's a big difference between 4 GB Vintage and 15 GB old Ivory and 26 GB new Ivory.

Part of that might be the larger number of sample levels in the one product, fewer in the other. More sample levels may give some improved authenticity. But there's much more to quality than just the number of sample levels. That is, a bigger library need not necessarily impress you more than a smaller library.

I think what this demonstrates is that the compression, length, and number of samples is not the limiting factor at this level. Vintage D is good because they sampled a good piano using good techniques and then made good engineering decisions after that (post-processing, kontakt scripting, etc.).

Ivory also did a good job with those things, but adds to that a larger number of layers, non-compressed samples, and whatever else they put in to make it so large. But those latter things do not make the critical difference because they are not the limiting factor.

Standards for software pianos are high, but not so high that the difference between compressed and uncompressed samples, for example, matters.

Galaxy uses Kontakt's standard NCW lossless compression feature (available since K4) - so it is not limiting quality. Compression is slow, but decompression almost instant. I think Kontakt is buffering samples in compressed format, so it allows more sound loaded in the same RAM space. The real bottleneck beeing disk I/O, this schema arrangement allows for lower latency, at the cost of some higher CPU load, which is not critical with current HW.

The real bottleneck beeing disk I/O, this schema arrangement allows for lower latency, at the cost of some higher CPU load, which is not critical with current HW.

If you mean lower latency for the performer at the keyboard, I don't think so. I agree that the bottleneck is the disk, but the main effect of the compression would be to increase the overall effective data rate that the disk can provide, which would increase the polyphony.

I've just done some Googling - yes it is maintained in compressed format in RAM, and yes, N.I consider the CPU overhead to be negligible.

Well, Greg, I think polyphony (with voice killing options), latency (constant/jitter) are very interdependent things, which I wanted to investigate but had no time for this. You can translate better effective data rate to all or to some selected items of these - depending on the algorithm of Kontakt or the instrument using it. It is also crutial how the KScript program of the instrument is implemented. Momentarily I cannot say much specific about this without having worked in in more detail.

And I agree from Your previous post that different "buffers" or caches (ASIO audio driver, pre-load buffer in Kontakt) have different roles and effect of the different performance characteristics and should not get mixed up.

(One remark: Galaxy samples are of 48Kbit/24bit not 44.1/24. I get with my gear slightly but audibly better results by upsampling to 192000bit/s - at the cost of latency, but only on a weaker PC).

As you can see, a lot of us on PW (including myself) make a hobby out of chasing a more realistic digital piano sound. I think that most of us would acknowledge that all digital/software pianos fall far short of an acoustic -- but it's still fun to try to get "just a little bit closer." If you have some money to spend and you enjoy fiddling around with electronics, software pianos make a great hobby. If you really have to get "the sound," start saving up for a concert grand.

You can play it back in 96, which I assume means it is upsampling, but the samples are 48.

How does that work? I mean, if samples are 48, how can you go higher than that,,hmm. Of course I'm not a tech-expert of any kind, but as I understand, with audio it's always the case that You can go FROM higher to lower, but can't go from lower to higher, if the orginal source is lower (at least that's the case, for instance, going from FLAC to mp3 not other way around).

You can play it back in 96, which I assume means it is upsampling, but the samples are 48.

How does that work? I mean, if samples are 48, how can you go higher than that,,hmm. Of course I'm not a tech-expert of any kind, but as I understand, with audio it's always the case that You can go FROM higher to lower, but can't go from lower to higher, if the orginal source is lower (at least that's the case, for instance, going from FLAC to mp3 not other way around).

Yes, theoretically, it could make a difference. The discrete, sampled audio has to be filtered to remove high frequency "aliases" of the real signal. By setting the sampling rate to 96kHz in the software, the software is performing SOME of this filtering, and is reducing the amount of filtering that the digital to analog converter (DAC) has to do (in the audio interface). The DAC is now being fed with a 96kHz digital audio stream, which is a higher resolution version of the original signal. (it doesn't contain any more information, though - i.e - if the highest frequency in the original is, say, a 14kHz piano overtone, then there will be no overtones any higher than this in the 96kHz version). The DAC still has to perform some filtering, but less than if it were being fed the 48kHz stream.

Now - it will only make a difference if the software does the filtering better than the DAC does. This might sound unlikely, but given the immense power of today's computers - I simply don't know.

That's great. I believe you, and I'll believe you even more if you drop in next time your're in my neighbourhood and I can subject you to a double-blind test. ;^) (just being cheeky)

Note that there's actually a possibility that the fidelity is LESS when you do that, but you prefer the sound. I.e - the high frequency aliasing may actually make it sound better to you, even though it's technically worse. (this could be the case if the software is doing worse filtering than the DAC) For example, I have read that some people actually prefer MP3 recordings that have audible artifacts!!!

I agree that there is a possibility that the DAC turns off all processing at such a high sample rate - very interesting question!