View Single Post
#17
2013-02-09, 20:21
 SteveDiverse Join Date: Nov 2003 Posts: 3,533
Quote:
 Originally Posted by joshuajohn89 the audio must be sampled at two or more different rates simultaneously, while only the stream of the highest resolution that can be played without ill effect will be output at any given time as a performance safeguard.
Lets use rates of 96k and 88k as the examples...

Running at 96k, computer is calculating 96k samples per second (each sample represents 1/96k second).

Running at 88k, computer is calculating 88k samples per second (each sample represents 1/88k second).

88k rate is not just taking 96k and dropping 8k samples each second - it's a whole different alignment of sample points.

In order to run at both rates the computer has to simultaneously calculate the samples for 96k and 88k, which means calculating 184k samples per second.

How's it going to do that if it's already having problems calculating 96k samples per second?

And the problem is a matter of maxing out the CPU - or at least maxing out the ability of the CPU to process sound in real time.

In order to prevent the sound from stopping and automatically stepping down the rate (from say 96k to 88k) the computer would have to 'look ahead', which would mean calculating a buffer of some time duration (perhaps only a few milliseconds) and then playing the buffer back 'behind' the calculations.

if the buffer length shrinks, it means that playback is catching up with the calculations, which means the calculation is starting to fall behind (or already has fallen behind) which would trigger the step down in sample rate.

Note, however, that this buffer would mean built-in latency that you couldn't get rid of.

The look-ahead/buffer concept is actually how most anti-skip features work on CD players. the sound for several seconds is placed in a buffer and then the D/A conversion (playback) starts.

If the player is moved in a way that causes the play-head to skip, playback of the buffer continues and the play-head is 'recovered' and returned to normal read. Since calculations are a little faster than playback, the buffer quickly 'refills' to its full length.

Sound only stops if the time required to recover the play-head exceeds the duration of time held in the buffer.

This works for CD playback because the listener doesn't notice the 'latency' because once the song starts to play, it continues in real time. the only 'lag' is that from pushing play to the start of the song playing.

With a live or interactive situation like Reason, you would notice it because you'd start triggering sounds with your controller, the calculations would be done in real time, but the playback would lag by that delay that is the buffer.
__________________

HP Pavillion DV7T-3300 Laptop | i7 Q720 @ 1.6 GHz | 4GB RAM | Win7 Pro 64-bit
m-audio Axiom Pro 61 keyboard controller || iPad2 | RetouchControl DUO | TouchOSC | LoopBe30 MIDI
m-audio Mobile Pre USB (original) audio interface | ASIO4ALL || RĂ˜DE NT-3 mic
Reason 6.5.3 || Pulsar | Saturation Knob | Rough Rider | TSAR-1 | Uhbik-A | Re-Tron | Polar | Echobode | Uhbik Q | Uhbik F | Morfin XF | Uhbik S | Uhbik D | Uhbik G | CV Suite Line Processor | wbl5515 | Uhbik P | RE-2A | Radical Piano

Last edited by SteveDiverse; 2013-02-09 at 20:45.