Subject: Re: [linux-audio-dev] more numbers for multichannel playback
From: David Olofson (david_AT_gardena.net)
Date: Wed Apr 05 2000 - 05:33:07 EEST
On Tue, 04 Apr 2000, Paul Barton-Davis wrote:
[...]
> Excellent. But later things start to get worse:
>
> 0: rah target 5388332 requires 262144 bytes (46.147msecs)
> 1: rah target 5421100 requires 294912 bytes (41.467msecs)
> 2: rah target 5421100 requires 294912 bytes (58.935msecs)
> 3: rah target 5421100 requires 262144 bytes (101.688msecs)
> 4: rah target 5453868 requires 294912 bytes (48.352msecs)
> 5: rah target 5453868 requires 294912 bytes (46.394msecs)
> 6: rah target 5486636 requires 327680 bytes (84.197msecs)
> 7: rah target 5486636 requires 294912 bytes (65.517msecs)
> 8: rah target 5486636 requires 262144 bytes (96.208msecs)
> 9: rah target 5519404 requires 294912 bytes (182.217msecs)
> 10: rah target 5552172 requires 294912 bytes (102.100msecs)
> 11: rah target 5584940 requires 327680 bytes (86.519msecs)
> 12: rah target 5584940 requires 327680 bytes (60.348msecs)
> 13: rah target 5584940 requires 327680 bytes (214.142msecs)
> 14: rah target 5650476 requires 360448 bytes (141.156msecs)
> 15: rah target 5683244 requires 393216 bytes (165.175msecs)
> 16: rah target 5716012 requires 425984 bytes (329.143msecs)
> 17: rah target 5748780 requires 425984 bytes (240.222msecs)
> 18: rah target 5814316 requires 491520 bytes (59.614msecs)
> 19: rah target 5814316 requires 491520 bytes (128.623msecs)
> 20: rah target 5847084 requires 491520 bytes (293.053msecs)
> 21: rah target 5912620 requires 557056 bytes (236.032msecs)
> 22: rah target 5945388 requires 589824 bytes (203.362msecs)
> 23: rah target 5978156 requires 589824 bytes (325.902msecs)
This looks kind of weird to me... The time it takes to read n bytes
for T tracks should be something like
avg_seek_time * T + n * T / avg_transfer_rate
but the above suggests that something completely different is taking
place...
Are your files by any chance heavily fragmented? (And do note that
"heavily fragmented" for this kind of use may even be larger chunks
than ext2 considers to be fragmentation at all!)
The chunks (should roughly equal your disk write size, unless ext2 is
being nasty) have to exactly match and coincide with the read size (ie
you can't use any other size than 256 kB), or you'll get a lot more
seek overhead as soon as the read-ahead fails to keep track of the
mess.
Ex: (file chunks = 6 chars, read size = 4 chars)
Disk: 111111222222333333444444111111222222333333444444
Read 1: 1111 2222 3333 4444
Read 2: 11 22 33 4411 22 33 44
Read 3: 1111 2222 3333 4444
etc...
Result: +50% seek overhead.
Alternatively, the chunks must be significantly larger than the
normal read size (ie some 1024 kB or more for a 256 kB normal read
size).
Ex: (file chunks = 16 chars, read size = 4 chars)
Disk: 1111111111111111222222222222222233333333333333334444444444444444
Read 1: 1111 2222 3333 4444
Read 2: 1111 2222 3333 4444
Read 3: 1111 2222 3333 4444
etc...
Have you tried writing one file at a time to a freshly formatted
partition, and then playing them all back using your algo? If that
doesn't work, it's either because of a bug in your code, or because
ext2 is chopping the data up too much, being optimized for larger
numbers of smaller files, and truly random access rather than
multichannel sequential access.
I'm very positive that your drive can do a lot better than this, as
the performance of my old 5.1 GB 5400 rpm IDE drive could cope with
16 tracks of 44.1 kHz stereo using the same buffer size. Somewhere
above 70% of the average transfer rate is where you should begin to
expect problems - although you may have to dump ext2fs to get there.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Wed Apr 05 2000 - 06:44:16 EEST