Subject: Re: Problem with switching sound cards.
To: Dr. Rene Hexel <rh@vip.at>
From: Frederick Bruckman <fb@enteract.com>
List: port-i386
Date: 05/09/2001 15:17:47
On Wed, 9 May 2001, Dr. Rene Hexel wrote:

> > Hmm, I compiled xmms yesterday (after updating the pkgsrc tree), and
> > whenever I play a mp3 file, it stutters horribly.
>
>   This could be a side-effect of our pthreads being non-preemptive.  It
> works fine here, but if your CPU load is too high, this may be a
> problem.  You could try playing around with the various buffer sizes and
> percentages in xmms' preferences ...

I think, rather, it's not correctly determining the amount of free
space in the audio device's buffer, so it ends up blocking in write(),
when it could be using that time better to calculate ahead for the
next write(). Consider the following, from xmms-1.0.1/Output/OSS/audio.c...

static void oss_calc_device_buffer_used(void)
{
        audio_buf_info buf_info;
        if(paused)
                device_buffer_used = 0;
        else if (!ioctl(fd, SNDCTL_DSP_GETOSPACE, &buf_info))
                device_buffer_used = (buf_info.fragstotal *  buf_info.fragsize) - buf_info.bytes;
}

With the present implementation in NetBSD of
SNDCTL_DSP_GETOSPACE(&buf_info), the value returned will always be
nearly zero, no matter what the high water mark (hiwat) is set to.
With the patch I submitted to libossaudio (PR lib/12796), it works out
to be the value of play.seek, which I believe is what they want.

Try applying the patch from the PR (the last patch) and rebuilding and
reinstalling libossaudio, to see if that makes a difference. If that
works, we can put a conditional compile in "audio.c" in the xmms
package to better support older NetBSD systems.


Frederick