From: "sam detweiler" <sdetweil@gmail.com>
To: alsa-devel@alsa-project.org
Cc: evanbtcohen@gmail.com
Subject: arecord stops capturing data when streaming to stdout after max wav file size data processed
Date: Fri, 15 Dec 2017 11:31:12 -0600 [thread overview]
Message-ID: <0a7101d375ca$80c034c0$82409e40$@gmail.com> (raw)
The github smart-mirror project uses arecord on pi devices to capture user
audio. This is a long running application,
(I expect my mirror to be on 24/7)
Anyhow, after 18 hours, we stop receiving audio data.
I have debugged it to the capture routine in aplay.c
Basically it is not intended to run forever.
rest = count; <---- get the remaining size from the count
total size
// don't let the remaining data size be too
big
if (rest >
fmt_rec_table[file_type].max_filesize)
rest =
fmt_rec_table[file_type].max_filesize;
if (max_file_size && (rest > max_file_size))
rest = max_file_size;
write the 'file' header
/* setup sample header */
if (fmt_rec_table[file_type].start)
fmt_rec_table[file_type].start(fd, rest);
/* capture */
fdcount = 0;
while (rest > 0 && recycle_capture_file == 0
&& !in_aborting) {
size_t c = (rest <=
(off64_t)chunk_bytes) ?
(size_t)rest
: chunk_bytes;
size_t f = c * 8 /
bits_per_frame;
if (pcm_read(audiobuf, f) !=
f) {
in_aborting
= 1;
break;
}
if (xwrite(fd, audiobuf, c)
!= c) {
perror(name);
in_aborting
= 1;
break;
}
count -= c; <--- decrement
the file size
rest -= c; <---- decement
the remaining data
fdcount += c;
}
Eventually rest AND count will be 0 or less
than 0 (for wav this is 2 gig).
Then we loop back up, start another file,
and then while rest >0, it is not any longer
Then we loop, and write a new file header,
and then rest <0, so no data capture..
If this is stdout, we should NOT decrement
the rest and size counters.. but let the timelimit and sample limit stop the
outer loop
while ((file_type == FORMAT_RAW &&
!timelimit && !sampleslimit) || count > 0);
so my proposed change is
/* capture */
fdcount = 0;
while (rest > 0 && recycle_capture_file == 0
&& !in_aborting) {
size_t c = (rest <=
(off64_t)chunk_bytes) ?
(size_t)rest
: chunk_bytes;
size_t f = c * 8 /
bits_per_frame;
if (pcm_read(audiobuf, f) !=
f) {
in_aborting
= 1;
break;
}
if (xwrite(fd, audiobuf, c)
!= c) {
perror(name);
in_aborting
= 1;
break;
}
If(!stdout){
<---- add this test
count -= c;
<--- decrement the file size
rest -= c;
<---- decement the remaining data
fdcount +=
c;
}
}
Sam
reply other threads:[~2017-12-15 17:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='0a7101d375ca$80c034c0$82409e40$@gmail.com' \
--to=sdetweil@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=evanbtcohen@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox