Subject: Re: [linux-audio-dev] munlock and mmap
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Apr 05 2000 - 02:06:01 EEST
>Had you looked better at my code I sent you (the famous
>lockfree ringbuffer), then you wouldn't have these problems now.
>:-)
benno - I am pretty upset by this comment, despite the smiley on the
end. I *did* read your code. If you remember, it turned out not to be
threadsafe on SMP systems, so I fixed it. Your code doesn't work for
what I'm doing. I've spent the last 10 days working on various
approaches to this problem, and I have yet to find a fully bomb proof
solution.
The fact that you can play back 60 tracks has nothing to do with my
situation, as I understood your code. I don't have a copy of it
anymore, so if you want to post it, please do, and I'll try to point
out why it doesn't work for an ardour-like application. For one thing,
the situation when you some of the time you are recording and take
into account that data recorded at time N belongs at time (N -
latency) in the file creates some real hairiness. I've been through 6
major design approaches to this so far. Perhaps I'm just missing
something obvious.
Note also that, as demonstrated by the two test programs I wrote,
using mmap/mlock can be massively slower than using read.
>For example if you have 26 files of 1GB each, you are unable to
>mmap() all the files simultaneously into mem due to the fact that the
>x86 has only 4GB (2GB) of address space. With the mmap() / munmap()
>trick the limit is only the disk space, and the max filesize of ext2
>( 2GB).
A 2GB address space is quite adequate to hold 24 tracks of 32bit/48kHz
sound of the lengths that any studio would likely work with. If people
want more and want to mmap the whole thing, they should use an alpha.
--p
This archive was generated by hypermail 2b28 : Wed Apr 05 2000 - 01:44:39 EEST