From owner-freebsd-multimedia@FreeBSD.ORG Sat Jan 26 11:39:37 2013 Return-Path: Delivered-To: freebsd-multimedia@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 124BBE43; Sat, 26 Jan 2013 11:39:37 +0000 (UTC) (envelope-from clemens@ladisch.de) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id CBCBBAF9; Sat, 26 Jan 2013 11:39:36 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8143020A32; Sat, 26 Jan 2013 06:39:29 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 26 Jan 2013 06:39:29 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=OIr+2WwuIKlVTVkRRVY9Jh YOx/M=; b=ZtErkOW6u21PqJpA8yOExhtLigTTzhiFtNGZVfGvlT8ARY/4cyZ7eG dbXodS0OQ4ArjWAZRyCLHGXswbWqtf63rHI8Vn4VMapq3MiakmHii2fwE3ECNkvx BAAmeIrJdDirEFnwI5jSy1AX3s8loWUJLzcUsg8u2H6YxNRiGGwIM= X-Sasl-enc: Ao/rxkLODXM7xzNd35ER7xV3ibBr+aAFP/blB3LrdKgo 1359200369 Received: from [192.168.42.11] (unknown [176.6.185.40]) by mail.messagingengine.com (Postfix) with ESMTPA id B405C8E0811; Sat, 26 Jan 2013 06:39:28 -0500 (EST) Message-ID: <5103C03D.4040201@ladisch.de> Date: Sat, 26 Jan 2013 12:38:37 +0100 From: Clemens Ladisch User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110323 Thunderbird/3.1.9 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: sound(4) vs alsa oss plugin References: <5103A438.9010806@FreeBSD.org> In-Reply-To: <5103A438.9010806@FreeBSD.org> Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@FreeBSD.org X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 11:39:37 -0000 Andriy Gapon wrote: > For some reason ALSA OSS plugin developers decided to use SNDCTL_DSP_GETOPTR and > SNDCTL_DSP_GETIPTR to track state of playback/recording. The reason might be compatibility with all the other OSS implementations out there. > Of all information returned by these ioctl they use just 'ptr' to track the > progress by hardware. > > Now I see that under a "right mix" of circumstances the following is possible: > - a buffer is completely empty for recording or completely full for playback > - an application / ALSA checks the buffer pointer and gets some value P > - the application sleeps for some time, perhaps oversleeps due to system load or > something else > - the buffer is completely filled or drained depending on the direction > - the application / ALSA checks the buffer pointer and gets the same value P > - the application assumes that the buffer is in the old state and waits further > - sound(4) code knows that the buffer is in the new state and does nothing > > So, couple of questions: > - apparently this used to work (works?) in Linux - how? What evidence do you have that this particular case is handled correctly in Linux? :o) > - is there any trick that we can do in our sound(4) code to prevent this 'ptr' > full cycle from happening? Not really. It's the logic in the ALSA OSS plugin that should be fixed to also use the 'bytes' field. > Ideally, it's the logic in the ALSA OSS plugin that should be fixed, but... > The upstream is not very responsive. Not very active. Patches will be accepted. (As long as they don't break with all the other OSS implementations ...) Regards, Clemens