From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (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 4E0B31F66E for ; Thu, 13 Aug 2020 11:32:50 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1k6BTQ-0001YX-Gr; Thu, 13 Aug 2020 11:32:44 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k6BTQ-0001YL-7l for sox-devel@lists.sourceforge.net; Thu, 13 Aug 2020 11:32:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version :Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: 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=SeAO0PtyR7VSxrkh/mXRJ/HwUktugoNd9NsgykvotEw=; b=WKykcfFoPLuNaWmZSovb93JXAd hQ/a65DxajQ7qI4p/1BMEzCEh7f5AX6eTODDkMDdg79hW8DQ9KfIPyCkMm3YffGKbTqFoNQEAr2rn UGoBfaIeE6xS+GfTZj1VhvZUVSbiSxkGcAPVoZVb7f7vdMrMMsVBE42OOgUA995qDHk0=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: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=SeAO0PtyR7VSxrkh/mXRJ/HwUktugoNd9NsgykvotEw=; b=LvsiBGKfQqWst5eMGf9bjpWVvM vR+onYKfBrJ5KCnh3Uk8R8qHJLNF3DvXOSq08GXgkTrlwDETs5eqZm4USlonKAha1tgJHNtW9kM5I G4/Ix43TlkCBn859AYyXSt+aWIUUf2KCAhr8IAn24SPrPVarr7Z7J9U4p7UGr7CDk5I0=; Received: from [81.2.72.234] (helo=unicorn.mansr.com) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1k6BTM-004mhY-Bt for sox-devel@lists.sourceforge.net; Thu, 13 Aug 2020 11:32:44 +0000 Received: from raven.mansr.com (raven.mansr.com [IPv6:2001:8b0:ca0d:8d8e::3]) by unicorn.mansr.com (Postfix) with ESMTPS id E031515360; Thu, 13 Aug 2020 12:32:22 +0100 (BST) Received: by raven.mansr.com (Postfix, from userid 51770) id D1D4A21A6F2; Thu, 13 Aug 2020 12:32:22 +0100 (BST) From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Eric Wong References: <20150907011017.GA9788@dcvr.yhbt.net> <20200812062848.GA27511@dcvr> <20200813035350.GA1144@dcvr> Date: Thu, 13 Aug 2020 12:32:22 +0100 In-Reply-To: <20200813035350.GA1144@dcvr> (Eric Wong's message of "Thu, 13 Aug 2020 03:53:50 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Headers-End: 1k6BTM-004mhY-Bt Subject: Re: [PATCH] use posix_fadvise to increase readahead 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 Cc: sox-devel@lists.sourceforge.net Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: sox-devel-bounces@lists.sourceforge.net Eric Wong writes: > M=E5ns Rullg=E5rd wrote: >> Eric Wong writes: >> = >> > Eric Wong wrote: >> >> All relevant audio file formats store data sequentially, so >> >> give a hint to the kernel to perform more readahead. In current >> >> Linux, the readahead hint doubles readahead pages and can help >> >> with playback on slow devices. >> > >> > Btw, I've been running this for a few years, too; but pretty >> > much all on FLAC. >> > >> > I don't know if there's audio formats we support which aren't >> > sequential. Maybe there's some wacky audio format which >> > requires random read all over the place... >> = >> I can't think of any format that isn't mostly sequential, certainly not >> that's supported in SoX. There might exist some format that separates >> channel data such that reading sequentially from multiple starting >> points is the best strategy. > > Yeah, I was wondering about something along those lines, > especially if exceeding 2 channels... I know of formats that interleave channel data in blocks of a few kilobytes, but those don't require seeking. Some MOV/MP4 video files store the video and audio completely separately, but we don't care about those. >> What sort of improvement do you get from this anyway? I'm not opposed >> to the addition, just curious. > > I didn't measure before :x It's more of a "it couldn't hurt" > thing and let the kernel (and configured per-device readahead) > decide. It's only intended as a hint for the kernel, after all. > > My 7200 RPM HDD has 256 MB cache on it; I couldn't measure any > difference even with 'echo 3 >/proc/sys/vm/drop_caches' (Linux) > and reading ~300 MB of stuff before testing in hopes it'd clear > the internal HDD cache. Maybe slower mounts (optical storage, > 4200 RPM HDDs, or network FSes) will see the benefit. > > I used to play audio on a laptop using an sshfs mount back in > the day (with FUSE readahead, too), but haven't had the need or > ability to do that for years, now. Hmm, I prefer not to add code like this on a hunch. Maybe I'll hook up some horrible old laptop drive and see if it makes a difference there. Then again, does anyone care? -- = M=E5ns Rullg=E5rd _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel