Re: [linux-audio-dev] 32/96 x 24 playback improvements, I think

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] 32/96 x 24 playback improvements, I think
From: Benno Senoner (sbenno_AT_gardena.net)
Date: to helmi  03 2000 - 17:06:51 EST


On Thu, 03 Feb 2000, Kai Vehmanen wrote:
> On Thu, 3 Feb 2000, Benno Senoner wrote:
>
> > - mmap() / munmap() instead of read()
> > (read() seems to read ahead too much, therefore wasting some of the disk
>
> Hmm, I tend to use library functions instead of direct system calls.
> So in this case, I use fread(). Am I wasting resources, or is the
> difference insignificant?

as Paul pointed out fread() does intermediate buffering, therefore
if you want to squeeze out the last bit of performance from your disk,
use lower level functions like read()/write() / mmap()
Note that mmap() is protable across all POSIX-ish OSes.
>
> > - using large buffers at least 1MB/track , otherwise you get not enough
> > reliability
>
> I've tried this technique with ecasound, but I haven't got very good
> results. I have a dedicated thread, which handles all file inputs.
> Each input has two 512kB buffers, which are used for
> mmap-mlock-use-munlock-munmap. All threads run with SCHED_FIFO.
> When I use this with large number of inputs (I usually test with 7-8 stereo
> input files), I get dropouts when buffers are switched. I have
> a P166MMX with Quantum EIDE drives. I have DMA enabled, but it seems
> that mmapping those 512kB blocks still freezes the whole machine.
> With normal buffering (and using fread()'s), there're no dropouts.
> Am I doing something wrong here or is this a hardware problem?

Kai, remember that you should run SCHED_FIFO only the thread which does the
audio processing.
Usually I run the disk reader without SCHED_FIFO, although you may use
SCHED_FIFO with lower priority than the audio thread.

To know what's wrong in your app I would need to know more details how you
manage disk i/o and/or read your sources. :-)

Paul, even if you are ANTI-EIDE , I can only say that recent disks
(disks which support UDMA), work very well,
especially the IBM and Maxtor ones.
The performance is ok (for example the 18GB disk does 16MB/sec when reading a
large file), and reliability too (I have some IDE disks running for 3-4 years
on my servers without any problem).

Therefore I don't see any reason to bash (good) EIDE disks, especially
since the price/MByte is only half of the price of SCSI disks.

Looking at the tests of standaline HD Recordes in the german "Keyboards"
magazine, I see that most of them are build using regular IDE disks.

I think even for audio recording on PC , UDMA disks are more than adequate,
except if you need a big number of tracks , but then the bottleneck shitfs to
other components, like CPU which is unable to do realtime signal processing on
all tracks etc.

Benno.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST