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=ham 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 A007320281 for ; Tue, 7 Nov 2017 08:50:51 +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 1eBzas-00036O-2X; Tue, 07 Nov 2017 08:50:50 +0000 Received: from sfi-mx-3.v28.ch3.sourceforge.com ([172.29.28.193] 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 1eBzaq-00036C-Av for sox-users@lists.sourceforge.net; Tue, 07 Nov 2017 08:50:48 +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:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=y9vvWbzgm7BZQat6oD4iGd2Wp8khBwEoo/cCfOQ7O3s=; b=iq7YpdQKM7ba12XY8853mQ4T6a akweYJawByf24JYW9ChwjtZtP6ixkLSO9DiKp2l599dJ+IFUqgmQwVdBcTdL78YxZVRo70awz0ZF+ P6dyQ8IYodAR1C+iJzuFb98y1nTrwwyCpOCJ9Oh5tYZ4eUPVNAuRldH8D+XKvBOPxjyc=; 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:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=y9vvWbzgm7BZQat6oD4iGd2Wp8khBwEoo/cCfOQ7O3s=; b=DmDj6ikVVo7JhUGlhUtpsc2Woh NLMH7w9MpX1JtQumeTQWFoR2q3x3uoUh0Xvh3JddZfzuQmUAJt8jSlc5W2+hAsLF++us7p8vsn2IJ vwuy18BdFiZ8VrI0OMnLYPmh2USkzFf40/DeZOaw3+PRvwMJxxgyRk88UZwbvWf2Q528=; Received: from ns.stare.cz ([79.98.77.229] helo=mx.stare.cz) by sfi-mx-3.v28.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) id 1eBzam-0001ln-Gz for sox-users@lists.sourceforge.net; Tue, 07 Nov 2017 08:50:48 +0000 Received: from www.stare.cz (localhost [127.0.0.1]) by www.stare.cz (OpenSMTPD) with ESMTP id 7f6bc613 for ; Tue, 7 Nov 2017 09:50:36 +0100 (CET) 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: 1eBzam-0001ln-Gz Subject: Re: how to interpret tell_off, and the right way to use sox_seek X-BeenThere: sox-users@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-users@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: sox-users-bounces@lists.sourceforge.net > 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-users mailing list Sox-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-users