Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 03 Feb 2013 15:32:07 +0200
From:      Alexander Motin <mav@FreeBSD.org>
To:        Andriy Gapon <avg@FreeBSD.org>
Cc:        freebsd-multimedia@FreeBSD.org
Subject:   Re: sound(4) vs alsa oss plugin
Message-ID:  <510E66D7.9070608@FreeBSD.org>
In-Reply-To: <510E3F5F.8090104@FreeBSD.org>
References:  <5103A438.9010806@FreeBSD.org> <5108111F.3080205@FreeBSD.org> <510E3F5F.8090104@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 03.02.2013 12:43, Andriy Gapon wrote:
> 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;
>  }
> 
> 

What is the idea of this patch? Won't calculated result be exactly the same?

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?510E66D7.9070608>