Skip site navigation (1)Skip section navigation (2)
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>
References:  <5103A438.9010806@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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,
Clemens



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5103C03D.4040201>