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.8 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, UNPARSEABLE_RELAY,URIBL_BLOCKED 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 BE8311F66E for ; Thu, 27 Aug 2020 12:40:34 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kBHCg-0001Oz-3j; Thu, 27 Aug 2020 12:40:30 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kBHCe-0001Or-RN for sox-devel@lists.sourceforge.net; Thu, 27 Aug 2020 12:40:28 +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:Cc:To:From:Date:Sender:Reply-To: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=3Xu9YqZs3eOEcv1kj0aMHEYCNgp7r/8lAq5EihxRqaQ=; b=Um8JkwJbiRxW5DjBwMABip2Tae x4iVPclqj+O9/M9eMNM/RQ2KbSkrv+hwTHmwlsYcWPOGyK5r09d/4LJ/kUbL4Xj47clXPAM/e/m7n 538lv9XXEwK5b5pvBcOL8YUrmQ1OG0vLfZB/MOjsnsXjut0mTUKK+rH553eBCuQUFMvw=; 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:Cc:To :From:Date:Sender:Reply-To: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=3Xu9YqZs3eOEcv1kj0aMHEYCNgp7r/8lAq5EihxRqaQ=; b=YZtYOHywyVv8CdIGq0RP3kX3AI VTW9WVJeoIwt4d3zVVRkz4uhn1UZ4v9Mqt3c3k95waUH4h5KB0Pp1Nw/D9xjiisfXb6NeSPAudxIt 6iP6cbXlmYv2HBgq4S3ovXZ/c6MknOGp8jtz/DLrogHAids88kiHHP6o0cU09nJDXMKI=; Received: from uvt.stare.cz ([185.63.96.79] helo=mx.stare.cz) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1kBHCa-004v00-EB for sox-devel@lists.sourceforge.net; Thu, 27 Aug 2020 12:40:28 +0000 Received: from localhost (stare.cz [local]) by stare.cz (OpenSMTPD) with ESMTPA id 2f8c415b; Thu, 27 Aug 2020 14:40:16 +0200 (CEST) Date: Thu, 27 Aug 2020 14:40:14 +0200 From: Jan Stary To: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= Message-ID: <20200827124014.GA20713@www.stare.cz> References: <20200827092158.GA5768@www.stare.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Headers-End: 1kBHCa-004v00-EB Subject: Re: Build system cleanup 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="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: sox-devel-bounces@lists.sourceforge.net > > checking for strdup... yes > > > > Not specific to NetBSD of course, but why are we running these > > tests (taking strdup as a random example)? Is there a POSIX > > system without strdup? And if we miss strdup, then what? > > With that configure.ac line changed to check for xstrdup instead, > > this will just become > > > > checking for xstrdup... no > > > > but everyting follows as before. Which means we have checked for > > a function (via AC_CHECK_FUNCS), found out it does not exist, > > and ignored the result. What is that for? > > I already explained this about five times. The only explanation I have seen so far is "it was warranted in the olden days". Perhaps it was; but why are we checking for e.g. strdup() in 2020 (and ingoring the result of AC_CHECK_FUNCS anyway)? > > checking for sys/soundcard.h... yes > > > > On NetBSD, sys/soundcard.h says > > > > This is an OSS (Linux) audio emulator. > > Use the Native NetBSD API for developing new code, > > and this only for compiling Linux programs. > > > > The check is > > > > SOX_FMT_HEADERS([oss], [sys/soundcard.h], [SOUND_MIXER_MUTE], > > [], [devices]) > > > > so at least we correctly recognize this as OSS emulation. > > But the check does not work universaly: NetBSD has > > /usr/include/sys/soundcard.h -> ../soundcard.h, but e.g. > > OpenBSD only has /usr/include/soundcard.h (same code though). > > Apparently, the name makes a difference: > > a test for "sys/soundcard.h" will fail on OpenBSD. > > > > checking whether SOUND_MIXER_MUTE is declared... no > > > > Why SOUND_MIXER_MUTE, specificaly, out of all the others? > > For example, SOUND_MIXER_INFO is declared, which would > > make the oss emulation detected (not saying this is > > the correct test). > > > > Lastly, oss requires a library to be linked: > > https://netbsd.gw.com/cgi-bin/man-cgi?ossaudio > > That would be /usr/lib/libossaudio.so - I believe a recent > > commit has concluded that oss does not require any library > > (being a bunch of defined ioctls); on NetBSD, it maybe does. > > > > $ nm /usr/lib/libossaudio.so | grep oss > > 0000000000001f60 T _oss_ioctl > > Real OSS does _not_ need a library. That is _only_ used for the > incomplete emulation that we don't want. The test is chosen such that > it passes on Linux, FreeBSD, and Solaris while failing on NetBSD and > OpenBSD. In case it is intended to detect OSS as not present on OpenBSD and NetBSD (who only emulate OSS), it seems to work as intended. > > checking for sys/audioio.h... yes > > > > This seems to be NetBSD's native audio interface. > > https://netbsd.gw.com/cgi-bin/man-cgi?audio > > It's what the NetBSD port of SoX uses: > > http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/audio/sox/ > > > > checking whether AUDIO_HWFEATURE_DUPLEX is declared... no > > > > ... but we miss that, because of this. > > It seems NetBSD's audio system came from Sun audio > > (/usr/pkg/bin/sox reports AUDIO DEVICE DRIVERS: sunau), > > but it's not quite the same; in particular, > > AUDIO_HWFEATURE_DUPLEX is not defined. > > Already fixed. The detectin works, thanks: Audio devices: alsa no ao no coreaudio no oss no pulseaudio no sndio no sunaudio yes waveaudio no It doesn't actually play though: $ play -V -n -b 16 synth 1 play INFO sunaudio: Sun Audio driver only supports bytes and words play: SoX v14.4.2 play INFO nulfile: sample rate not specified; using 48000 Input File : '' (null) Channels : 1 Sample Rate : 48000 Precision : 32-bit Output File : 'default' (sunau) Channels : 1 Sample Rate : 48000 Precision : 16-bit Sample Encoding: 16-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no play INFO sox: effects chain: input 48000Hz 1 channels play INFO sox: effects chain: synth 48000Hz 1 channels play INFO sox: effects chain: dither 48000Hz 1 channels play INFO sox: effects chain: output 48000Hz 1 channels In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0 Memory fault (core dumped) $ gdb ~/bin/sox sox.core GNU gdb (GDB) 7.12 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64--netbsd". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/hans/bin/sox...done. [New process 1] Core was generated by `sox'. Program terminated with signal SIGSEGV, Segmentation fault. #0 sunwrite (ft=0x713985f0c400, pInput=0x713986083000, cInput=7040) at sunaudio.c:481 481 SOX_SAMPLE_TO_SIGNED_16BIT(pInput[i], cClips); (gdb) bt #0 sunwrite (ft=0x713985f0c400, pInput=0x713986083000, cInput=7040) at sunaudio.c:481 #1 0x000071398601a3bd in sox_write (ft=0x713985f0c400, buf=, len=) at formats.c:1037 #2 0x0000000000404be0 in output_flow (effp=, ibuf=, obuf=, isamp=0x7f7ffff6b6b0, osamp=) at sox.c:644 #3 0x0000713986029f7d in flow_effect (n=3, chain=0x713985f1c0c0) at effects.c:257 #4 sox_flow_effects (chain=, callback=callback@entry=0x40443e , client_data=client_data@entry=0x0) at effects.c:449 #5 0x0000000000408a33 in process () at sox.c:1780 #6 main (argc=, argv=) at sox.c:2988 _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel