From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan Stary Newsgroups: gmane.comp.audio.sox.devel Subject: Re: Adjusting write buffer for recording Date: Sun, 11 Aug 2013 19:10:35 +0200 Message-ID: <20130811171034.GB26948@www.stare.cz> References: Reply-To: sox-devel@lists.sourceforge.net NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1376241056 23346 80.91.229.3 (11 Aug 2013 17:10:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Aug 2013 17:10:56 +0000 (UTC) To: sox-devel@lists.sourceforge.net Original-X-From: sox-devel-bounces@lists.sourceforge.net Sun Aug 11 19:10:55 2013 Return-path: Envelope-to: gcasd-sox-devel@m.gmane.org X-ACL-Warn: Mail-Followup-To: sox-devel@lists.sourceforge.net Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -2.7 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -2.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1V8ZAC-0007ma-5M X-BeenThere: sox-devel@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sox-devel-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.comp.audio.sox.devel:310 Archived-At: Received: from lists.sourceforge.net ([216.34.181.88]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V8ZAM-0005Pa-8J for gcasd-sox-devel@m.gmane.org; Sun, 11 Aug 2013 19:10:54 +0200 Received: from localhost ([127.0.0.1] helo=sfs-ml-1.v29.ch3.sourceforge.com) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V8ZAE-0008JP-R4; Sun, 11 Aug 2013 17:10:46 +0000 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V8ZAE-0008JK-5f for sox-devel@lists.sourceforge.net; Sun, 11 Aug 2013 17:10:46 +0000 Received: from mx.stare.cz ([79.98.77.229] helo=www.stare.cz) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V8ZAC-0007ma-5M for sox-devel@lists.sourceforge.net; Sun, 11 Aug 2013 17:10:46 +0000 Received: from www.stare.cz (localhost [127.0.0.1]); by www.stare.cz (OpenSMTPD) with ESMTP id 5a33e906; for ; Sun, 11 Aug 2013 19:10:35 +0200 (CEST) On Aug 09 14:05:32, shane.blaser@callfire.com wrote: > Hello I have an application that processes audio as rec writes the file. Does this mean that rec(1) writes into a pipe and your application is reading that pipe? > rec is buffering the data before it writes and I get > the updates about 2 or 3 seconds late. How do you know that? How exactly are you reading what rec(1) is writing? > I have played with the --buffer pram and I not been able to see a > difference. > > I would like to tell rec to write the data as soon as it gets it or reduce > the file write buffer size. That's what --buffer is supposed to do ... > I have silence detection on > rec -c 1 -r 8000 --buffer 4096 currentRecording.wav silence 1 0.0001 2.1% 1 > 15.0 2.6% > > The writes look like this > > Size of currentRecording.wav = 24576 Size of currentRecording.wav = 36864 > *Size* *of* *currentRecording.wav* *=* *45056* *Size* *of* * > currentRecording.wav* *=* *77824* The steps are indeed multiples of 4096. Can you try with other --buffer to see if the data becomes available to your application in the chunks that rec(1) is writing? ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk