Subject: Re: [linux-audio-dev] 32/96 x 24 playback improvements, I think
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: ke helmi 02 2000 - 13:45:48 EST
>From: Paul Barton-Davis <pbd_AT_Op.Net>
>
>reading from the disk in the same size chunks as I would write to the
>Hammerfall (between 4K and 32K).
Err.. right.
I suggest to put the source code available so that we don't have to guess
what else is wrong there. For example, I assumed you already used every
trick mentioned so far... (no offense)
>amortizing the overhead of a disk read over a lot of data. So now, I
>read the whole 1s in a single read(2) call. I then use double
I want to make this clear to myself, please confirm:
several simultaneous 1 seconds (say) reads are split to smaller pieces
so that those reads are actually interleaved by kernel. But now I wonder
how much is the split block size?
Maybe the split block size is what causes dropouts?
My engine works the same way than yours and I have wondered if I should
at all give the splitting to kernel. What is the different in reading
1 seconds blocks or smaller blocks for 26 tracks simultaneously? Overhead
in moving from thread to thread, and kernel space to user space?
Maybe some combined audiocard/disk _driver_ could really push the limits
of the hard disks.
>basically, i just have a gut feeling that this is a good approach that
>can be adjusted and tuned properly. if anyone has any thoughts, please
>let me know.
You could now try that fsync() trick for recorded (to disk) tracks.
Or decrease the amount of memory when virtual memory system flush
data to disk. I suggest to use fsync() for certain reasons.
Juhana
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST