Date: Sat, 26 Jan 2013 12:38:37 +0100 From: Clemens Ladisch <clemens@ladisch.de> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-multimedia@FreeBSD.org Subject: Re: sound(4) vs alsa oss plugin Message-ID: <5103C03D.4040201@ladisch.de> In-Reply-To: <5103A438.9010806@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
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, Clemenshome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5103C03D.4040201>