From owner-freebsd-multimedia@FreeBSD.ORG Sat Jan 26 12:04:31 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 7C29C6A1 for ; Sat, 26 Jan 2013 12:04:31 +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 BD8F7CD1 for ; Sat, 26 Jan 2013 12:04:30 +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 OAA11439; Sat, 26 Jan 2013 14:04:26 +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 1Tz4Uj-000HpW-L2; Sat, 26 Jan 2013 14:04:25 +0200 Message-ID: <5103C648.4090103@FreeBSD.org> Date: Sat, 26 Jan 2013 14:04:24 +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: Clemens Ladisch Subject: Re: sound(4) vs alsa oss plugin References: <5103A438.9010806@FreeBSD.org> <5103C03D.4040201@ladisch.de> In-Reply-To: <5103C03D.4040201@ladisch.de> 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: Sat, 26 Jan 2013 12:04:31 -0000 on 26/01/2013 13:38 Clemens Ladisch said the following: > 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. Possible... Although opensound documentation has a big fat warning: This ioctl call should only be used when using mmap(). In normal applications it's practically useless. >> 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) No real evidence. Just an assumption that since it's done this way and hasn't been changed in many years, then it must work (have been working when OSS was in use) :-) Also, given that ALSA comes from Linux, I assumed that ALSA OSS pluging was developed and tested on Linux and thus primarily with Linux OSS implementation in mind. >> - 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. OK. >> 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 ...) Great to hear. I will try to put together a patch. Are you one of the ALSA developers? Should I contact you in addition to the mailing list? -- Andriy Gapon