Subject: [linux-audio-dev] HD-recording frustration: linux makes it almost impossible :-(
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sun Apr 09 2000 - 23:31:10 EEST
Hi,
I rewrote my HD recording demo-code from scratch,
using C++.
It can now record data as well.
Notice that in the following text I am refering to audio tracks
in 32bit format (signed long) in order to simulate Paul's 24bit recording.
( 32bit 44.1khz mono)
I am using 1MB buffer per track (ringbuffer)
On my box ( IBM 16GB EIDE UDMA) I can easily to 24 tracks
PLAYBACK only while surfing the web, (firing up netscape is a nice test),
starting gimp, viewing PDFs with acroread etc.
When I push performance to the limits I can go up to 36-38 tracks,
but then I have to avoid any background disk activity in order not to
miss the deadlines. (I tried with a dedicated audio disk, it works perfectly)
Now to TRACK WRITING:
here is where the REAL PAIN starts:
I am doing first read ahead on all input tracks and the write behind on all
output tracks.
The problem is when there is a buffer cache flush (kernel disk write buffers),
then things get realy ugly.
even with the disk thread using SCHED_FIFO, it doesn't get rescheduled
for 4-8 secs SOMETIMES. (since I am calling read() and write() )
ARRGH !
Hopefully SCSI disk will make this better , but on Windoze
you can record painless on EIDE disks, therefore the HD recording
has to work on Linux on IDE disk as well, or I am forced to call
it an UNUSABLE OS. :-)
Even with 2MB buffer per track we miss a deadline sometimes.
And that is independent of the algorithm, I think Ardour will encounter the
same problems.
I am trying this on kernel 2.2.12 ( kernel of RH 6.1), hopefully
2.2.14 and 2.3.x kernels reduce the stall problem.
even tring to fdatasync() the tracks now and then , doesn't buys us anything.
Any thoughts ?
PS: I comared mmap() to read() and must say that in fact when reading
256k at time you get a bit better performance, and there seems to be less
paging activity using read() instead of mmap().
I will release my code within the next 48hours, so you ULTRA SCSI folks,
can benchmark your disk with my test program.
It is fully thread safe now (discovered a buq where the disk thread was
flipping pointers of track structures under the audio thread's ass,
which obviously updated the wrong structures on SMP boxes :-) )
I tried FAT vs EXT2, almost no difference , the main problem still remains
the write buffer flushing.
Paul, your statement about ringbuffers == bad is wrong , since
the boundary condition occurs very seldom , ( a small % of cases),
plus I am doing page alignment of read()s and write()s therefore
it should be pretty optimized.
I am going to test with 2.2.14 in the next hours and will tell you if it brings
some performance enhancements.
comments meanwhile ?
PS2: I will demonstrate to Paul that varispeed is PAINLESS (no or
little performance degradation) with my code, (first demo will not contain
varispeed).
Benno.
This archive was generated by hypermail 2b28 : Sun Apr 09 2000 - 23:22:09 EEST