Subject: Re: [linux-audio-dev] munlock and mmap
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: Wed Apr 05 2000 - 01:10:26 EEST
Hmm...
A pseudo code attempt using read.
#define Tbutler 0.100 // 1/10 second, far from seek time (use less)
#define fs 46000 // or someting close...
#define tracks 24
#define samples round_up_to_multiple_of_page_size(tracks*Tbutler*fs)
#define fragments 4 // use less?
typedef int Sample;
Sample buffer[tracks][fragments][samples] // lots of megs...
FILE *fd[tracks] = ...
int alternating, track;
// Begin to read samples[*][all but last][*] from their respective file
for (alternating = 0; alternating < fragments - 1; alternating++)
for (track = 0; track < tracks; track++)
read(fd[track], &buffer[track][alternating][0],
samples*sizeof(Sample));
clone(audio process); // it starts playback of tracks
// Butler
while (1)
{
for (track = 0; track < tracks; track++) {
read(fd[track], &buffer[track][alternating][0],
samples*sizeof(Sample));
usleep(Tbutler - read time of this track); // periodic indication
via RTC or audio thread?
}
alternating = (alternating+1) % fragments; // optimize with &
}
Would this be workable? You get the idea.
/RogerL
Paul Barton-Davis wrote:
>
> yeah, now i *really* understand why i did this.
>
> i wanted to map the file once, so that the audio thread and butler
> thread never had any races over the current VM location of the mmap
> buffer.
>
> if i have to munmap() the track file in pieces so that i can tell the
> kernel that i don't care about sections of memory anymore, it means
> that i can't have a single location where the mmap buffer can always
> be found.
>
> this starts to get hairy again.
>
> needless to say, i am determined to make this work without XFS, raw
> I/O or anything else, just so that when those things become
> compelling, it all works even better. sigh.
>
> --p
-- Home page: http://www.norran.net/nra02596/
This archive was generated by hypermail 2b28 : Wed Apr 05 2000 - 02:57:52 EEST