Hello.
In my Linux 2.0.36 with Alsa 0.2 a strange thing happens when I use
fdatasync() to flush recorded audio to disk: the time used for disk
write followed by fdatasync() increases slowly within the time.
See code:
gettimeofday(&t1,NULL);
if (write(fd, &shmbuf[ri], DISKBUFSIZE) != DISKBUFSIZE) {
exit(-1);
}
if (fdatasync(fd) != 0) {
exit(-1);
}
gettimeofday(&t2,NULL);
The time difference t2-t1 increases slowly until recording is impossible.
When I take fdatasync() away, everything seems to go well.
Original motivation for using fdatasync() was to flush virtual memory to
disk more often so that the time used for flush doesn't cause a break
in audio recording. In my earlier Linux, use of fsync()/fdatasync()
was only cure to audio recording dropouts.
-*-
The architecture of my recorder is following. Two processes runs as
normal user processes. "top" shows very low cpu usages.
A/D process:
-reads A/D to a large shared memory buffer in 16k chunks (have tried
1k-8k chunks too); 16k is nearly 0.1 seconds, i.e., ten times the 1/HZ;
-when shared memory buffer has enough data (at least 128k), a SIGCONT
is sent to disk write process and sched_yield() is executed.
Disk write process:
-if shared memory buffer has 128k new audio data, it is written to disk;
-SIGSTOP is sent to itself (done always).
The above works okay without fdatasync(). The SIGCONT is sent only once,
i.e., another is sent only after disk write process has done something for
the previous SIGCONT.
-*-
There are a couple of places to improve the program:
-use plain Alsa interface, not the OSS emulation; anyone has a simple
enough wrapper functions for Alsa library? Now I even don't have any idea
what are the buffer size and the fragment size used in Alsa driver;
this could be the source of problem as well;
-use soft-RT processes; this would turn the process execution order from
guesses to facts; use message queue for waiting instead of SIGSTOP/SIGCONT.
But, I think the program should work okay without those changes.
-*-
I may put the current version of my shmrec available for testing.
Just send me mail. However, shmrec was only a quick hack to my
earlier recording problems. There are now much better solutions
in kernel 2.4. But I just feel that we should find out what goes wrong
when fdatasync() is used.
Juhana
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:24 EST