From owner-freebsd-multimedia@FreeBSD.ORG Tue Apr 26 20:16:51 2011 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 B503A1065673; Tue, 26 Apr 2011 20:16:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6C2AE8FC20; Tue, 26 Apr 2011 20:16:51 +0000 (UTC) Received: by iwn33 with SMTP id 33so1136298iwn.13 for ; Tue, 26 Apr 2011 13:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=/iyKqk/GfYanWQR47zLJHcFxImxt6GazbpJRLigPFl4=; b=TqLSXSuI44ZbQs63CkIJFEhwcV50H3bXL7/ycukDbSRCmlmtwgPiWk5q9G1EVFkgoZ y0HjiZNs7jzsK/twnbaFHDRKbRb7cqQZdZMGV7QpRC5exnDAcE4tDb4Y7VscCYMCY+mK 16piXi2I+y/8y6C7PJZx8ArK+ViNnO1kOBr0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=orJ++wCXeq3dYu2GIbudxNlipDBtrwXsTqrxoIlBzvE/KGpHp1dUenPMPfwvpYoxt/ Yw+8LXG65Do1BKMx+HHIkRM3yF5Oy/e/kMrxVwJf7TzaAIz6tRwygI5Q/GdWABT4LLG1 uDNbtd0yJVHWsv15bwhMHKaV2UWYf3phIWePA= Received: by 10.42.146.73 with SMTP id i9mr1444170icv.252.1303845630636; Tue, 26 Apr 2011 12:20:30 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 19sm9737ibx.35.2011.04.26.12.20.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 12:20:29 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 26 Apr 2011 12:19:42 -0700 From: YongHyeon PYUN Date: Tue, 26 Apr 2011 12:19:42 -0700 To: Andriy Gapon Message-ID: <20110426191942.GB9893@michelle.cdnetworks.com> References: <4DB6F7BA.4070808@FreeBSD.org> <4DB701C4.30802@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DB701C4.30802@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Juergen Lock , multimedia@freebsd.org Subject: Re: SNDCTL_DSP_GETIPTR implementation X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 20:16:51 -0000 On Tue, Apr 26, 2011 at 08:32:52PM +0300, Andriy Gapon wrote: > on 26/04/2011 19:50 Andriy Gapon said the following: > > > > Guys, > > > > I reading this http://manuals.opensound.com/developer/SNDCTL_DSP_GETOPTR.html > > It says: "In mmap mode (only) the ptr field tells the location where the next > > sample will be recorded." > > In my opinion that means that we have a mistake in our code and the following > > patch should be applied. But I am not sufficiently familiar with this code. > > It seems that with this change linux alsa lib with oss plugin works for audio > recording now. E.g. in skype. > Hope I wasn't sloppy with my testing again, so I will re-test. > > Juergen, > will you be able to test this too? > > > --- a/sys/dev/sound/pcm/dsp.c > > +++ b/sys/dev/sound/pcm/dsp.c > > @@ -1655,7 +1655,7 @@ dsp_ioctl > > /* XXX abusive DMA update: chn_rdupdate(rdch); */ > > a->bytes = sndbuf_gettotal(bs); > > a->blocks = sndbuf_getblocks(bs) - rdch->blocks; > > - a->ptr = sndbuf_getreadyptr(bs); > > + a->ptr = sndbuf_getfreeptr(bs); > > rdch->blocks = sndbuf_getblocks(bs); > > CHN_UNLOCK(rdch); It had been long time ago since I read sound code so I'm not sure my understanding is correct or not. I think our implementation slightly violates OSS API. bytes of count_info for both SNDCTL_DSP_GETOPTR and SNDCTL_DSP_GETIPTR is number of bytes played/recorded so far but our code always returns a fragment size. However I think it returns correct ptr value in the fragment. I think applications should not rely on SNDCTL_DSP_GETOPTR or SNDCTL_DSP_GETIPTR since byte can reset to 0 after long running of playing/recording. SNDCTL_DSP_GETOPTR/SNDCTL_DSP_GETIPTR and SNDCTL_DSP_GETODELAY/SNDCTL_DSP_GETOSPACE are normally used to track overrun condition so old sound code tried to return accurate ptr to application by triggering DMA. However this was disabled long time ago because it can cause unnecessary delays so application can get same ptr in successive ioctls which in turn may make application think playback/recording is not working. This may happen on applications that try to respond smarter and have complex buffering strategies. How about reviving chn_rdupdate() in SNDCTL_DSP_GETIPTR? This may introduce additional latencies but you may be able to know the root of the issue. > > } else > > > > P.S. leading (indenting) whitespace in this file is a mess. > Agreed.