From owner-freebsd-multimedia@FreeBSD.ORG Thu May 24 00:34:18 2012 Return-Path: Delivered-To: multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E4761065674 for ; Thu, 24 May 2012 00:34:18 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 982EF8FC0C for ; Thu, 24 May 2012 00:34:17 +0000 (UTC) Received: by werg1 with SMTP id g1so6613253wer.13 for ; Wed, 23 May 2012 17:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OawF055RuXsTy8Z0P4XTuvlUQ9szHWrh6JFjI+bq9fw=; b=TgCtO1l/lqrZfKDWkqvuE9JzDZtRKwjuAPIpflmYwgCLthF0K3BvnTMy38SHzxN6nE wQ9ZUh2zPzFFKAj39B+gM8FN1WeMwPkWTVHNupFVV63zv5iVGx5bkAQhEA5PKS9F3V+Z /jyBAcN/vj/6/p3e93erAaiT44ndpjRER2NNMyZJWZZFIc7OHlkXGO63Csm7PTZzBD6G ZiEg44r/cxZe0qFkRttxgmLSA+vXDp8sq0EtNwxulbM1yqWYied4S9Hse4buzsYpLnoJ 82qrADB6drtan9pCECHHCl7ObxUox0gHJIEUy+jW5tKOhwtedFF7zaQVIpDr3lObf3Cn poWQ== Received: by 10.216.218.230 with SMTP id k80mr15682523wep.39.1337819653402; Wed, 23 May 2012 17:34:13 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id fm1sm43733491wib.10.2012.05.23.17.34.11 (version=SSLv3 cipher=OTHER); Wed, 23 May 2012 17:34:12 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FBD8202.9010308@FreeBSD.org> Date: Thu, 24 May 2012 03:34:10 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120328 Thunderbird/10.0.3 MIME-Version: 1.0 To: Konstantin Belousov References: <20120522220640.GB2358@deviant.kiev.zoral.com.ua> <4FBD2D50.5080205@FreeBSD.org> <20120523193718.GF2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120523193718.GF2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimedia@freebsd.org Subject: Re: NV10 hdac issue X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 00:34:18 -0000 On 05/23/12 22:37, Konstantin Belousov wrote: > On Wed, May 23, 2012 at 09:32:48PM +0300, Alexander Motin wrote: >> On 05/23/12 01:06, Konstantin Belousov wrote: >>> I have (another) Atom motherboard from Intel, DN2800MT. Now, the problem >>> is with distorted sound. Anything is played as if some pause is inserted >>> after the next sample is finished. So I hear the proper pitch, but with >>> guggle between fragments. I am not sure how to describe it better, except >>> to say that it sounds as if buffering was not enough, for regular short >>> intervals of approx. 0.5 sec. >>> >>> I do not believe that 1.8Hhz Atoms are too slow to decode mp3 or to play >>> wav. >>> >>> The hda controller is >>> hdac0@pci0:0:27:0: class=0x040300 card=0x20128086 chip=0x27d88086 >>> rev=0x02 hdr=0x00 >>> codec is Realtek ALC888. The verbose dmesg from hda_snd load is at >>> http://people.freebsd.org/~kib/tom.dmesg.txt , assuming this is useful. >>> >>> I would want to get normal sound from this board, thanks in advance. >> >> I haven't seen alike reports neither for this controller, nor for this >> CODEC. I would try to experiment with: >> 1) disabling MSI interrupts with hint.hdac.0.msi=0 >> 2) switching to polling mode without using any interrupts with >> dev.hdac.0.polling=1 >> 3) changing buffer size with hw.snd.latency >> 4) changing playback format (or vchans format it it is used) >> 5) setting sysctl hw.snd.verbose=2 and checking for application level >> underruns with `cat /dev/sndstat`. > > Thank you, setting hw.snd.latency to 10 fixed the issue. Still, I do not > understand why default settings for the driver are not enough for the > machine. latency=10 means buffering for about 0.3s, that is quite a lot. I've tested some systems with smallest possible buffer of just 0.6ms and they were working about fine even in that case. If it works for large buffer I would suppose that controller operates well, because using only two interrupts per period even single loss should be heard. Can't it be some insane SMI handler or something alike? Aren't there any other lags noticed? -- Alexander Motin