[Gllug] OT: algorithm needed

[salsaman at xs4all.nl]

On Mon, August 11, 2008 12:42, Andrew Farnsworth wrote:
> Peter Corlett wrote:
>> On 10 Aug 2008, at 22:38, salsaman at xs4all.nl wrote:
>> [...]
>>
>>> That's right - I should have added that each read should read as
>>> close to
>>> the max as possible (including the final read).
>>>
>>
>> If you think about it for a moment, all solutions which contain
>> ceil(total / max) transfers are equally-close to max.
>>
>> You can increase the number of blocks in a transfer to get it close to
>> max, but at the cost of reducing it elsewhere by an equal number. Each
>> transfer will still have to do an average of total / ceil (total -
>> max) blocks however you balance the individual transfers.
>>
>> The problem appears to be not for want of a good algorithm but the
>> lack of a good definition of the problem.
>>
> Correct me if I am wrong but is not the most efficient method of doing
> these reads the scenario where you have the fewest number of partial
> reads?  In other words, if you have 100 blocks to read, and a max read
> size of 40 blocks, the most efficient is 40,40,20 or 40,20,40 or 20, 40,
> 40?  This way you only get one partial read, where if you normalize your
> reads you get 3 partial buffer reads of 33,33,34 or 33, 34, 33 or
> 34,33,33 and isn't each of these reads non-optimal?  Therefore reading
> in max buffer size from the beginning and let the final read be the
> optimal situation?
>
> Andrew Farnsworth
> --
> Gllug mailing list  -  Gllug at gllug.org.uk
> http://lists.gllug.org.uk/mailman/listinfo/gllug
>
>

Well, that depends on the purpose of the read ;-)

In this case, I do not actually read the X blocks (the blocks are not disk
blocks, but rather audio samples). X is my target number of audio samples
at a certain audio rate and number of channels.

What I do read are input samples, which could be at a different rate,
number of channels, sample size (8, 16, 24 or 32 bit).

In order to reduce the risk of rounding errors, I aim to keep X as high as
possible, but below some user-defined value for audio buffer size.

The value X is then used to calculate the number of input samples to read
(Y), the samples are converted and stored in a buffer. There is one buffer
per input track, thus X is actually divided by number of input tracks.


Thus, for example:

X = 8 * 1024 * 1024 bytes

number of input tracks = 3

X per track = X/3 (rounded to make it even)


out rate is 44100 Hz, 2 channels, float

Thus X per track is divided by 2*sizeof(float) to give result in number of
samples. The result is rounded down so we only read whole samples.


input track 0 is

22050 Hz, 2 channels, 16 bit samples

in bytes = X (samples per track) * 2 * 2 * 44100/22050


I read in in_bytes, and convert, this should give me X per track samples
as output.

Since the input rate can be anything (the user can adjust the speed of
playback, giving a virtual audio Hz), each input read should be as large
as possible to reduce risk of rounding errors.

A rough calculation gives 4 input channels, 2 million bytes per track at a
rate of 40,000, 1 sample dropped per 12.5 seconds of audio. (2 channels 16
bit samples).

For pro-audio you would use something like 96KHz, 32 bit per sample, 5.1
channels, which would be 1 sample per second approx. So pro-audio users
would need to increase the audio buffer size to approximately 1GB (1
sample per 2 minutes of audio).

Regards,
Gabriel.
http://lives.sourceforge.net






-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug