From owner-freebsd-multimedia@FreeBSD.ORG Tue Jan 29 18:12:53 2013 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0065C21B; Tue, 29 Jan 2013 18:12:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by mx1.freebsd.org (Postfix) with ESMTP id 469B3E2A; Tue, 29 Jan 2013 18:12:52 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id j4so435624bkw.17 for ; Tue, 29 Jan 2013 10:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZnfOVxho/vQCSjeIXBI4lFXH+MHYkVrQx7jPDRf0ppY=; b=HwM4mp2PczJOwjkX1mC04dZTiqVfL9OlLrKqEEitBNDR74akyeqWwNz/Fjes6lp17E 5Hk+HlN9s5vwZi8NivRHdllQQHi5SzkviFLwTOhkCkqa8if35JdIc+AE1be6PU9bd+KC xCzpzMhsxmhUGi+i9SDLI3UD4j2jOVxvskVqaSNK9B9sITXa9dCCL7Nr8ATqY/gGQtqq 925N6Sr5CWmJXV7dYl4bdYNgq0qYrCPhHIdJv8xTpmwx7wSHSpaiKasFJui+tDm+6608 YFgY+MBhB91U/C0gPwz1WtFLTgbCNFrJPnHAvKdsZslOFbDPGp5m/ni3RL05FH5nCJLV UVJw== X-Received: by 10.204.9.21 with SMTP id j21mr589452bkj.32.1359483171025; Tue, 29 Jan 2013 10:12:51 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([91.198.175.1]) by mx.google.com with ESMTPS id o9sm9803599bko.15.2013.01.29.10.12.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 10:12:49 -0800 (PST) Sender: Alexander Motin Message-ID: <5108111F.3080205@FreeBSD.org> Date: Tue, 29 Jan 2013 20:12:47 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130125 Thunderbird/17.0.2 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: Tue, 29 Jan 2013 18:12:53 -0000 On 26.01.2013 11:39, Andriy Gapon wrote: > > I think I discovered an interesting/unusual problem. > > For some reason ALSA OSS plugin developers decided to use SNDCTL_DSP_GETOPTR and > SNDCTL_DSP_GETIPTR to track state of playback/recording. > http://manuals.opensound.com/developer/SNDCTL_DSP_GETOPTR.html > http://manuals.opensound.com/developer/SNDCTL_DSP_GETIPTR.html > 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 > > The above is only possible, obviously, if the buffer size is a multiple of a > sample size. > > So, couple of questions: > - apparently this used to work (works?) in Linux - how? > - is there any trick that we can do in our sound(4) code to prevent this 'ptr' > full cycle from happening? > > Ideally, it's the logic in the ALSA OSS plugin that should be fixed, but... > The upstream is not very responsive. I wonder if they still care about OSS at all. > While patching audio/alsa-plugins is relatively easy, fixing a binary package > for audio/linux-f10-alsa-plugins-oss is not. And it's needed for things like > skype, etc. > > What do you think? > > P.S. > it's because of audio problems with skype that I found this issue. I am not sure how it supposed to work in Linux, but IMHO it is obvious that single ptr field is not sufficient in such conditions to identify full buffer wrap. Additional checks for bytes or blocks fields could help, but that is user-level side. I am not sure what kernel can do about it. >From the other side, case when buffer wrapped completely is IMHO already fatal situation. It means that we are already late -- hardware already started to either play or overwrite previous buffer. That is probably not much better then if we would woke up some samples later. -- Alexander Motin