I'm using arecord to record directly to a USB key:
Code:
arecord -f cd > /mnt/usb/myfile.wav
But I see buffer overruns at 30 second intervals, which correspond with short bursts of USB write activity.
I'm assuming this is related to:
Code:
/proc/sys/vm/dirty_expire_centiseconds
And the > is actually writing to the page cache until the above expires.
When I tune this down I get a buffer overrun at what ever the dirty_expire_centiseconds is set to, so I think the pdflush is locking the cache while it writes to USB.
So I started looking for a non blocking pipe buffer and found "bfr" which I've inserted in between the record and the output file.
Code:
arecord -f cd | bfr -b5m > /mnt/usb/myfile.wav
This should from what I understand provide a 5 meg non blocking pipe buffer to decouple the read and write.
I still get overruns !
After putting a load of trace in bfr.c and running in debug mode, I still see the write operation blocking, even though O_NONBLOCK is set. This stalls the read side of the pipe and arecord still overflows.
I've also tried running bfr forked, which should separate the read and write into 2 pids, and both processes appear to stall during the pdflush.
Can anyone tell me what pdflush blocks / locks out during a fs sync ?
Also if anyone can suggest a good way of buffering an arecord stream smoothly to USB key with pdflush firing I'd be much appreciative.
Tia.
Andy.
Last edited by radoulov; 01-16-2012 at 11:44 AM..
Reason: Code tags!
I have used the arecord command like this
arecord -d 1 test.wav
It is keep on waiting. I need to manually interrupt it by ctrl-c. Why it is not interrupting after one second?
The arecord version which I am using is :
arecord: version 1.0.23 by Jaroslav Kysela (3 Replies)
Discussion started by: thillai_selvan
3 Replies
LEARN ABOUT REDHAT
fifo
FIFO(4) Linux Programmer's Manual FIFO(4)NAME
fifo - first-in first-out special file, named pipe
DESCRIPTION
A FIFO special file (a named pipe) is similar to a pipe, except that it is accessed as part of the file system. It can be opened by multi-
ple processes for reading or writing. When processes are exchanging data via the FIFO, the kernel passes all data internally without writ-
ing it to the file system. Thus, the FIFO special file has no contents on the file system, the file system entry merely serves as a refer-
ence point so that processes can access the pipe using a name in the file system.
The kernel maintains exactly one pipe object for each FIFO special file that is opened by at least one process. The FIFO must be opened on
both ends (reading and writing) before data can be passed. Normally, opening the FIFO blocks until the other end is opened also.
A process can open a FIFO in non-blocking mode. In this case, opening for read only will succeed even if noone has opened on the write side
yet; opening for write only will fail with ENXIO (no such device or address) unless the other end has already been opened.
Under Linux, opening a FIFO for read and write will succeed both in blocking and non-blocking mode. POSIX leaves this behaviour undefined.
This can be used to open a FIFO for writing while there are no readers available. A process that uses both ends of the connection in order
to communicate with itself should be very careful to avoid deadlocks.
NOTES
When a process tries to write to a FIFO that is not opened for read on the other side, the process is sent a SIGPIPE signal.
FIFO special files can be created by mkfifo(3), and are specially indicated in ls -l.
SEE ALSO mkfifo(3), mkfifo(1), pipe(2), socketpair(2), open(2), signal(2), sigaction(2)Linux Man Page 1999-06-20 FIFO(4)
01-16-2012
arecord, pdflush and bfr.
