From owner-freebsd-multimedia@FreeBSD.ORG Sat Jan 26 09:39:12 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 EA97E3E6; Sat, 26 Jan 2013 09:39:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C16A47FA; Sat, 26 Jan 2013 09:39:11 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA10220; Sat, 26 Jan 2013 11:39:07 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tz2E6-000HgF-RG; Sat, 26 Jan 2013 11:39:07 +0200 Message-ID: <5103A438.9010806@FreeBSD.org> Date: Sat, 26 Jan 2013 11:39:04 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-multimedia@FreeBSD.org Subject: sound(4) vs alsa oss plugin X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit 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 09:39:13 -0000 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. -- Andriy Gapon