From owner-freebsd-multimedia@FreeBSD.ORG Sun Feb 3 10:43:47 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 1F82826D; Sun, 3 Feb 2013 10:43:47 +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 34E3D1BC; Sun, 3 Feb 2013 10:43:45 +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 MAA07244; Sun, 03 Feb 2013 12:43:44 +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 1U1x32-0006Eb-Kz; Sun, 03 Feb 2013 12:43:44 +0200 Message-ID: <510E3F5F.8090104@FreeBSD.org> Date: Sun, 03 Feb 2013 12:43:43 +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: Alexander Motin Subject: Re: sound(4) vs alsa oss plugin References: <5103A438.9010806@FreeBSD.org> <5108111F.3080205@FreeBSD.org> In-Reply-To: <5108111F.3080205@FreeBSD.org> X-Enigmail-Version: 1.4.6 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: Sun, 03 Feb 2013 10:43:47 -0000 on 29/01/2013 20:12 Alexander Motin said the following: > 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. I have a very nasty local kernel-side hack that "fixes up" 'ptr' wrap-around based on a check of 'blocks'. But root causes are, of course: - an application using sleep and GET*PTR for interacting with OSS - ALSA OSS using just 'ptr' - a 10 millisecond sleep taking e.g. 100 milliseconds once in a while (or under some circumstances) > 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. Well, some sound distortion/corruption is very bad, but completely blocked sound is even worse. I have the following patch for ALSA OSS, but haven't tested it yet: diff --git a/oss/pcm_oss.c b/oss/pcm_oss.c index d43b44c..4729962 100644 --- a/oss/pcm_oss.c +++ b/oss/pcm_oss.c @@ -83,7 +83,13 @@ static snd_pcm_sframes_t oss_pointer(snd_pcm_ioplug_t *io) fprintf(stderr, "*** OSS: oss_pointer error\n"); return 0; } - ptr = snd_pcm_bytes_to_frames(io->pcm, info.ptr); + + /* + * Note that the following calculations will produce a temporary glitch + * when info.bytes wraps around UINT_MAX or INT_MAX depending on type + * of info.bytes in an OSS implementation. + */ + ptr = snd_pcm_bytes_to_frames(io->pcm, info.bytes) % io->buffer_size; return ptr; } -- Andriy Gapon