From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Martin Guy Newsgroups: gmane.comp.audio.sox.devel Subject: Re: sox spectrogram patches Date: Sat, 26 Dec 2015 14:37:47 +0100 Message-ID: References: <20151226104316.GA5868@dcvr.yhbt.net> 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 1451137121 18483 80.91.229.3 (26 Dec 2015 13:38:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Dec 2015 13:38:41 +0000 (UTC) To: sox-devel@lists.sourceforge.net Original-X-From: sox-devel-bounces@lists.sourceforge.net Sat Dec 26 14:38:23 2015 Return-path: Envelope-to: gcasd-sox-devel@m.gmane.org Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.51 as permitted sender) client-ip=74.125.82.51; envelope-from=martinwguy@gmail.com; helo=mail-wm0-f51.google.com; X-Received: by 10.28.218.17 with SMTP id r17mr50322907wmg.90.1451137068406; Sat, 26 Dec 2015 05:37:48 -0800 (PST) In-Reply-To: <20151226104316.GA5868@dcvr.yhbt.net> X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (martinwguy[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1aCp2g-000384-EE 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:456 Archived-At: Received: from lists.sourceforge.net ([216.34.181.88]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aCp37-0008RB-Q6 for gcasd-sox-devel@m.gmane.org; Sat, 26 Dec 2015 14:38:22 +0100 Received: from localhost ([127.0.0.1] helo=sfs-ml-4.v29.ch3.sourceforge.com) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1aCp2k-00061C-DM; Sat, 26 Dec 2015 13:37:58 +0000 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1aCp2i-000616-L0 for sox-devel@lists.sourceforge.net; Sat, 26 Dec 2015 13:37:56 +0000 Received: from mail-wm0-f51.google.com ([74.125.82.51]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1aCp2g-000384-EE for sox-devel@lists.sourceforge.net; Sat, 26 Dec 2015 13:37:56 +0000 Received: by mail-wm0-f51.google.com with SMTP id l126so223305742wml.0 for ; Sat, 26 Dec 2015 05:37:54 -0800 (PST) Received: by 10.27.144.195 with HTTP; Sat, 26 Dec 2015 05:37:47 -0800 (PST) On 26/12/2015, Eric Wong wrote: > Martin Guy wrote: >> - remove arbitrary limit on spectrogram output height (was 1200) > > Seems alright, did you check for possible integer overflow issues > from raising the limit? Only by inspection and testing a range of heights/widths. >> - add FFTW3 support, which is between 150 and 250 times faster than >> the slow built-in FFT routine > > I do have problems with eyesight and do not see well; > so I can't comment on actual images. "cmp" tells me that the PNG files are identical with/without FFTW > I've made some minor edits to configure.ac for portability and > robustness Yes, I've done relatively little configure.ac hacking and was hoping someone who knows better might improve things. Thanks for the heads-up on these possible issues > I'd prefer if we could avoid CPP inside C functions entirely; > but that's a larger task and can be split into another patch. Do you mean, where there is a configure option, have two separate functions, one with the HAVE_ code and one with the HAVE_NOT code? Yes, it's ugly, I agree. One alternative would be to use "if (HAVE_FFTW)" and let the compiler turn if(0) or if(1) into constant code removal. Thanks again for stepping in to work on this. I was about to leave sox to die, given that its fathers have abandoned it. If we can get a last twitch of life out of them, it would be best they appoint you as its official maintainer. Blessings M ------------------------------------------------------------------------------