From owner-freebsd-multimedia@FreeBSD.ORG Fri Apr 24 17:08:08 2015 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C777A9EB for ; Fri, 24 Apr 2015 17:08:08 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CE5F16B3 for ; Fri, 24 Apr 2015 17:08:08 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id 82A311602C3; Fri, 24 Apr 2015 10:08:07 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 1D844160155; Fri, 24 Apr 2015 10:08:04 -0700 (MST) Message-ID: <553A7874.8080806@pinyon.org> Date: Fri, 24 Apr 2015 10:08:04 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Hans Petter Selasky , freebsd-multimedia@freebsd.org Subject: Re: uaudio0 -> audacity not recording References: <5536BC53.4070107@pinyon.org> <55375172.8040605@selasky.org> <553805E1.80303@pinyon.org> <553A20FA.2070801@selasky.org> <553A5A07.1080701@pinyon.org> <553A6659.2020808@selasky.org> In-Reply-To: <553A6659.2020808@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 17:08:08 -0000 Hi Hans, On 04/24/15 08:50, Hans Petter Selasky wrote: > On 04/24/15 16:58, Russell L. Carter wrote: >> >> >> On 04/24/15 03:54, Hans Petter Selasky wrote: >> >>> >>> Could you check or dump: >>> >>> sysctl -a | grep pcm >> >> Sure... >> >> dev.pcm.%parent: >> dev.pcm.0.%desc: USB audio >> dev.pcm.0.%driver: pcm >> dev.pcm.0.%location: >> dev.pcm.0.%pnpinfo: >> dev.pcm.0.%parent: uaudio0 >> dev.pcm.0.hwvol_step: 5 >> dev.pcm.0.hwvol_mixer: vol >> dev.pcm.0.play.vchans: 4 >> dev.pcm.0.play.vchanmode: fixed >> dev.pcm.0.play.vchanrate: 48000 >> dev.pcm.0.play.vchanformat: s16le:2.0 >> dev.pcm.0.rec.vchans: 1 >> dev.pcm.0.rec.vchanmode: fixed >> dev.pcm.0.rec.vchanrate: 48000 >> dev.pcm.0.rec.vchanformat: s16le:2.0 >> dev.pcm.0.buffersize: 0 >> dev.pcm.0.bitperfect: 0 >> dev.pcm.0.mixer.vol_0_0.val: -8225 >> dev.pcm.0.mixer.vol_0_0.min: -32768 >> dev.pcm.0.mixer.vol_0_0.max: 0 >> dev.pcm.0.mixer.vol_0_0.desc: USB Audio CODEC >> dev.pcm.0.mixer.vol_0_1.val: -8225 >> dev.pcm.0.mixer.vol_0_1.min: -32768 >> dev.pcm.0.mixer.vol_0_1.max: 0 >> dev.pcm.0.mixer.vol_0_1.desc: USB Audio CODEC >> dev.pcm.0.mixer.mute_1.val: 0 >> dev.pcm.0.mixer.mute_1.min: 0 >> dev.pcm.0.mixer.mute_1.max: 1 >> dev.pcm.0.mixer.mute_1.desc: USB Audio CODEC >> dev.pcm.0.feedback_rate: 0 >> >> > > Hi, > > If you run: > > sysctl dev.pcm.0.mixer.vol_0_0.val=-16000 > sysctl dev.pcm.0.mixer.vol_0_1.val=-16000 > > Does it make any difference? No difference, still garbled noise being output by rec. Rec appears to be receiving bits from the audio adapter; if I stop the audio source, the monitor correctly goes to zero. I raised mixer pcm from 75 to 100, and now I can hear in the garbled noise some tones that sound like they might be from the source. > Also try play with: > > sysctl dev.pcm.0.mixer.mute_1.val=0 This is where it is to begin with, so no effect. To be precise, I can hear the garbled output on 'play output.flac'. > sysctl dev.pcm.0.mixer.mute_1.val=1 And this causes the 'play output.flac' to be silent, even as the monitor is registering the same as before (about half the indicated max level for both channels). Thanks for taking a look at this. Russell > --HPS