From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Shane Blaser Newsgroups: gmane.comp.audio.sox.devel Subject: Re: Adjusting write buffer for recording Date: Mon, 12 Aug 2013 09:16:32 -0700 Message-ID: References: <20130811171034.GB26948@www.stare.cz> <20130812060933.GA6491@www.stare.cz> <20130812160341.GA18420@www.stare.cz> Reply-To: sox-devel@lists.sourceforge.net NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7291931614950404604==" X-Trace: ger.gmane.org 1376324229 26422 80.91.229.3 (12 Aug 2013 16:17:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Aug 2013 16:17:09 +0000 (UTC) To: sox-devel@lists.sourceforge.net Original-X-From: sox-devel-bounces@lists.sourceforge.net Mon Aug 12 18:17:11 2013 Return-path: Envelope-to: gcasd-sox-devel@m.gmane.org X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=nughiIJuBf5M/F3AFm21YE/bNmFvYXxbJZhdOnyws1U=; b=cpx4tmWqAyeUiXpWx8yj9K2JHHU94RXstFywqCGFVDr+MtzzZLkR5R9OHmBFUTEtjA HtNEwmGLE5zvqPV7L8aAUUpwn/DgBio9SniuHuSITxA5KfiJqt1czxuUb/Xs5Op/yVSy 6xB8xOsjpmwYUwR/HAFuEKnXfpBxCnP5kWZO1zlWETntg6oLmrrQxV87b22kt9teSX0h QC67tBeIKCQuIyR24KBLlwU0f6nW+KNIRtr69mdq3uIgVGvtbrZsgA9BWHWdhqM63O6P 7Y97YmoqNvPsJVg72U4MHzs28c9nVWNFQ2RvXLWYw26ymbB2Edy4gHil2BJYcH2URK7M 8yNg== X-Gm-Message-State: ALoCoQmiVh2YN2S5BCHd62oXyMfSyHwTKOhpHSN+Tn4JVhTHJYPKRPG/A1cW3GtSTMRzFsRiMOMi X-Received: by 10.68.106.36 with SMTP id gr4mr25665086pbb.0.1376324213217; Mon, 12 Aug 2013 09:16:53 -0700 (PDT) In-Reply-To: <20130812160341.GA18420@www.stare.cz> X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1V8unj-0008Rc-7C 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:315 Archived-At: Received: from lists.sourceforge.net ([216.34.181.88]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V8unu-0007wC-VU for gcasd-sox-devel@m.gmane.org; Mon, 12 Aug 2013 18:17:11 +0200 Received: from localhost ([127.0.0.1] helo=sfs-ml-2.v29.ch3.sourceforge.com) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V8unm-0000rF-5f; Mon, 12 Aug 2013 16:17:02 +0000 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V8unk-0000r8-F9 for sox-devel@lists.sourceforge.net; Mon, 12 Aug 2013 16:17:00 +0000 Received: from mail-pa0-f49.google.com ([209.85.220.49]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V8unj-0008Rc-7C for sox-devel@lists.sourceforge.net; Mon, 12 Aug 2013 16:17:00 +0000 Received: by mail-pa0-f49.google.com with SMTP id ld10so3143753pab.36 for ; Mon, 12 Aug 2013 09:16:53 -0700 (PDT) Received: by 10.70.10.67 with HTTP; Mon, 12 Aug 2013 09:16:32 -0700 (PDT) --===============7291931614950404604== Content-Type: multipart/alternative; boundary=047d7b6da6d8d32c0604e3c27302 --047d7b6da6d8d32c0604e3c27302 Content-Type: text/plain; charset=ISO-8859-1 comments inline On Mon, Aug 12, 2013 at 9:03 AM, Jan Stary wrote: > 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? > Maybe not sure the file seems to work. > > 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. > Sorry about that > > > 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. > yes it is audible and it sounds like a fax machine or modem .. > > > (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? > Yes see above > > > 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? > After the caller id signal there is a silence until the next ring ... Do you see any way for me to adjust the write buffers, if I can make them smaller I think this issue will fall away ...? > > 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 > _______________________________________________ > SoX-devel mailing list > SoX-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sox-devel > --047d7b6da6d8d32c0604e3c27302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
comments inline


On Mon, Aug 12, 2013 at 9:03 AM, Jan Stary <hans@stare.cz> wrote:
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?=A0
=A0<= /div>
Maybe not sure the file seems to work.=A0


> 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.

Sorry about that=A0

> 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 writ= ten
> 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.
<= br>
yes it is audible and it sounds like a fax machine or modem .= .=A0

> (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?

Yes see above=A0

> 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.=A0

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?
=A0
After the caller id signal there is a silence until the next ring .= ..=A0

Do you see any way for me to adjust the writ= e buffers, if I can make them smaller I think this issue will fall away ...= ?=A0

=A0 =A0 =A0 =A0 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/gam= pad/clk?id=3D48897031&iu=3D/4140/ostg.clktrk
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourcefo= rge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

--047d7b6da6d8d32c0604e3c27302-- --===============7291931614950404604== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ 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 --===============7291931614950404604== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel --===============7291931614950404604==--