From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3561 216.34.176.0/20 X-Spam-Status: No, score=-3.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,T_DKIM_INVALID shortcircuit=no autolearn=unavailable autolearn_force=no version=3.4.0 Received: from lists.sourceforge.net (lists.sourceforge.net [216.34.181.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 6888A20281 for ; Tue, 7 Nov 2017 10:05:48 +0000 (UTC) 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.89) (envelope-from ) id 1eC0lM-0004oP-Ca; Tue, 07 Nov 2017 10:05:44 +0000 Received: from sfi-mx-2.v28.ch3.sourceforge.com ([172.29.28.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eC0lL-0004oI-JO for sox-devel@lists.sourceforge.net; Tue, 07 Nov 2017 10:05:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:To:From:Date:Resent-To:Resent-Message-ID:Resent-Date: Resent-From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Sender:Resent-Cc:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=y9vvWbzgm7BZQat6oD4iGd2Wp8khBwEoo/cCfOQ7O3s=; b=jTYn/RO1ytvSWq7GhYzSPYB7NE gf72scqhBPDhDRm8H+6/n8y3bWLyWHqwLt+7XBfrd1eC+w8g/2PDDOEaPorKn/HQm+qkMIHieWLW+ FXAdjpsLHjYoJ/7RyXgOGegk92E1lbEcZPlwTQdExGokb2u+J8MXzL56qbwf42M1iO7s=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To: From:Date:Resent-To:Resent-Message-ID:Resent-Date:Resent-From:Sender:Reply-To :Cc:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Sender: Resent-Cc:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=y9vvWbzgm7BZQat6oD4iGd2Wp8khBwEoo/cCfOQ7O3s=; b=i jEwi9TT2iSw5H652RVoutOOpZKhb6Yxk1TzdqWbcRP3MGTCZTejzBEs5wPmZtdT02GLY9ZLTXZFvj FlglT7AB6aduYt0eVLjfkidGon2n88SM5URgr2DgdQY72ZSVYlsvH0NqSIzbKTfAuF3rsthlaBwcU 9ZUnoWsFdT9aRDJY=; Received: from mx.stare.cz ([79.98.77.229]) by sfi-mx-2.v28.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) id 1eC0lJ-0000X2-Ti for sox-devel@lists.sourceforge.net; Tue, 07 Nov 2017 10:05:43 +0000 Received: from www.stare.cz (localhost [127.0.0.1]) by www.stare.cz (OpenSMTPD) with ESMTP id fd55aeea for ; Tue, 7 Nov 2017 11:05:34 +0100 (CET) Resent-From: Jan Stary Resent-Date: Tue, 7 Nov 2017 11:05:34 +0100 Resent-Message-ID: <20171107100534.GA31914@www.stare.cz> Resent-To: sox-devel@lists.sourceforge.net Date: Tue, 7 Nov 2017 09:50:36 +0100 From: Jan Stary To: sox-users@lists.sourceforge.net Message-ID: <20171107085036.GA34760@www.stare.cz> Mail-Followup-To: sox-users@lists.sourceforge.net References: <20171106111001.GA80730@www.stare.cz> <20171106190645.GA61378@www.stare.cz> <20171106210932.GA41280@www.stare.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Headers-End: 1eC0lJ-0000X2-Ti Subject: Re: [SoX-users] how to interpret tell_off, and the right way to use sox_seek X-BeenThere: sox-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sox-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: sox-devel-bounces@lists.sourceforge.net Sender: "SoX-devel" > First, it reads (which presumably moves the file pointer forwards), > then it seeks back to where it was. > I've verified in gdb that it actually does call sox_seek() (again and > again and again, but not forever). I have also verified in gdb that > it is reading the same samples. Ah, I see what your problem is now. > So sox_seek() is definitely being called, and definitely working. > But nevertheless, the reading done after the seeking eventually fails. Here is my slight rewrite of your example: #include #include #include #include int main(int argc, char **argv) { sox_format_t *s; int32_t buf[1024]; ssize_t r; int i; if (argc < 2) errx(1, "usage: ./soxseek input"); if (sox_init() != SOX_SUCCESS) errx(1, "Cannot init libsox"); if ((s = sox_open_read(*++argv, 0, 0, 0)) == NULL) errx(1, "Cannot open `%s'", *argv); for (i = 1; (r = sox_read(s, buf, 1024)) > 0; i++) { printf("[%04d] %zd samples, starting with %0x\n", i, r, *buf); if (sox_seek(s, 0, SOX_SEEK_SET) != SOX_SUCCESS) errx(1, "Cannot seek"); } /* No way to test for sox_read() error */ return 0; } (Note how I don't use sox_site_t for the sox_read() return value, because it does not exist, eventhough that's what libsox(3) documents.) $ sox -n /tmp/file.wav synth trim 0 $((1024 * 1000))s $ cc -o soxseek soxseek.c -lsox -I/usr/local/include/ -L/usr/local/lib $ ./soxseek /tmp/file.wav [0000] 1024 samples, starting with 0 [0001] 1024 samples, starting with 0 [....] [0999] 1024 samples, starting with 0 [1000] 1024 samples, starting with 0 So I think you are right. It does seek back to the begining of the sine wave (thus reporting 0 as the first sample value in the buffer), but it gets exhausted at EOF anyway. I suspect now it is a bug in sox_seek() if we are calling it right. > Certainly if you do analogous coding with calls to fread() and > fseek(), it would not terminate. Yes, the following will read the same file forever: #include #include #include #include int main(int argc, char **argv) { int fd; int32_t buf[1024]; ssize_t r; int i; if (argc < 2) errx(1, "usage: ./seek input"); if ((fd = open(*++argv, O_RDONLY)) == -1) err(1, NULL); for (i = 1; (r = read(fd, buf, 1024)) > 0; i++) { printf("[%04d] %zd samples, starting with %0x\n", i, r, *buf); if (lseek(fd, 0, SEEK_SET) == -1) err(1, NULL); } return (r != 0); } > What i'm trying to do now is to determine the correct way to use > sox_seek() if i am using it incorrectly. If i'm using it correctly, > then i would like confirmation of my characterization (that it has > some internal counter which is decremented until it hits zero). I share your suspition now. > (I did have a signal processing problem that i was considering > earlier, but that's not relevant now because i avoided the sox_seek > issue by rearranging the computation. So i can do my dsp, but i do > wonder about correct usage of sox_seek.) Should we move this to sox-devel? Jan ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel