Subject: Re: [linux-audio-dev] munlock and mmap
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Apr 05 2000 - 01:14:37 EEST
On Wed, 05 Apr 2000, Paul Barton-Davis wrote:
> >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.
Apologies for my statement, it was not my intention to offend anyone.
( one of my defects that I too sound offending, when I try to make a joke)
Anyway I can understand your frustration, Linux do not give us any
way to guarantee a certain data-rate while reading / writing to files.
>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.
Yes, by code was a very quick (dirty) hack , not taking care about
SMP-safeness.
>
> 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.
Ok, tomorrow I will get back home, then I will rewrite the output for ALSA,
plus making it thread-safe, so that it can be used as a "real-world"
(at least playback only mode) benchmark.
> 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.
very strange. Maybe this is due to the fact that you are mmap()ing the
entire file and mlock()ing only parts ? I can't say I have to test this
tomorrow.
>
> >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.
I wouldn't say that :
let's assume: 24 tracks 32bit 48kHz :
32bit = 4bytes
4bytes * 24tracks * 48000
2000000000 / ( 24 * 48000 * 4) = ONLY 434 secs per track
7 minutes per track is really to little IMHO.
Therefore I still think it's better to avoid to mmap() the entire file into
mem.
Benno.
This archive was generated by hypermail 2b28 : Wed Apr 05 2000 - 02:30:32 EEST