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: Mon, 12 Aug 2013 18:03:42 +0200 Message-ID: <20130812160341.GA18420@www.stare.cz> References: <20130811171034.GB26948@www.stare.cz> <20130812060933.GA6491@www.stare.cz> 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 1376323435 16965 80.91.229.3 (12 Aug 2013 16:03:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Aug 2013 16:03:55 +0000 (UTC) To: sox-devel@lists.sourceforge.net Original-X-From: sox-devel-bounces@lists.sourceforge.net Mon Aug 12 18:03:57 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.8 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -2.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1V8uaz-0001iS-Ut 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:314 Archived-At: Received: from lists.sourceforge.net ([216.34.181.88]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V8ub6-0004oR-9r for gcasd-sox-devel@m.gmane.org; Mon, 12 Aug 2013 18:03:56 +0200 Received: from localhost ([127.0.0.1] helo=sfs-ml-3.v29.ch3.sourceforge.com) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V8ub4-0002Ms-NN; Mon, 12 Aug 2013 16:03:54 +0000 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V8ub3-0002Mn-Aa for sox-devel@lists.sourceforge.net; Mon, 12 Aug 2013 16:03:53 +0000 Received: from mx.stare.cz ([79.98.77.229] helo=www.stare.cz) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V8uaz-0001iS-Ut for sox-devel@lists.sourceforge.net; Mon, 12 Aug 2013 16:03:53 +0000 Received: from www.stare.cz (localhost [127.0.0.1]); by www.stare.cz (OpenSMTPD) with ESMTP id b97e6cbe; for ; Mon, 12 Aug 2013 18:03:43 +0200 (CEST) On Aug 12 07:31:24, shane.blaser@callfire.com wrote: > Yes i am calling stat, Wouldn't it be easire to just write to a pipe, and have your application read from that pipe? > But I can see that the file size does not change > for a few seconds and then the data is flushed. > > What I am doing is decoding caller id on a phone line: > So the flow goes like this: Please, in the future, _start_ with such top level description of what you are trying to do. Make it easy for people to help you. > 1. rec listening with silence detection > 2. Call comes in and recording starts. > 3. Caller id is between 1st and second ring. > (ok this is were the issue comes in) > after the first ring I get the first part of the caller id signal written > to disk (call it 1/2 of the caller id signal). Let me understand this: in the phone calls you are recording, there is a piece of _audio_ signal, comming between the first and second ring, which carries the caller's ID. Is that right? Can you please elaborate? I never knew there is something like that coming on a phone line. > (listening to the audio I know we have whole signal.) So this caller ID is an _audible_ signal, present in the audio of the phone call? > But not until after the second ring > do I get the audio for the rest of the caller id written to disk. > Can I have rec write silence to the file after the recording starts? Of course: just rec(1) everything, without using the 'silence' effect. What you are doing now is the exact opposite: you are telling rec(1) _not_ to write until a certain treshold of 'silence' is surpassed. I am too lazy now to look up your exact 'silence' parameters, but could it be that the caller ID audio signal contains enough 'silence' so that rec(1) pauses? Jan ------------------------------------------------------------------------------ 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