From owner-freebsd-multimedia  Fri Sep 15  7:14:43 2000
Delivered-To: freebsd-multimedia@freebsd.org
Received: from rnocserv.urc.ac.ru (rnocserv.urc.ac.ru [193.233.85.2])
	by hub.freebsd.org (Postfix) with ESMTP id 2DB6637B422
	for <multimedia@freebsd.org>; Fri, 15 Sep 2000 07:14:14 -0700 (PDT)
Received: from urc.ac.ru (belle.rnoc.urc.ac.ru [193.233.85.10])
	by rnocserv.urc.ac.ru (8.11.0/8.9.3) with ESMTP id e8FEDjN28971
	for <multimedia@freebsd.org>; Fri, 15 Sep 2000 20:14:10 +0600 (ESS)
	(envelope-from anton@urc.ac.ru)
Message-ID: <39C22E96.C4469170@urc.ac.ru>
Date: Fri, 15 Sep 2000 20:13:42 +0600
From: Anton Voronin <anton@urc.ac.ru>
Organization: URC FREEnet
X-Mailer: Mozilla 4.74 [ru ] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: multimedia@freebsd.org
Subject: Re: pcm & full-duplex
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-multimedia@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Orion Hodson wrote:

> <39C2165F.28CBAFBE@urc.ac.ru>Anton Voronin writes:
> > Hi all,
> > I just wish to ask, is it a bug or an intended behaviour of ioctl's
> > SNDCTL_DSP_GETCAPS command, that it reports full-duplex capability only when
> > applied to file descriptor opened with O_RDWR but not with O_RDONLY?
>
> This sounds like the right behaviour - the device is in half duplex
> mode so the current capability is half duplex.  It's not going to
> become full duplex without being re-opened.

Ok, anyway I had to fix rat ;)

> > Some applications (like rat) check for full-duplex using O_RDONLY,
> > and so fail to operate with it...
>
> I'm not sure if other applications open O_RDONLY and check for full
> duplex with SNDCTL_DSP_GETCAPS, but AFAIK rat on FreeBSD never has in
> the "full duplex only" versions (3.2 onwards).

At least 4.0.4 seems to do so:

int vox_audio_duplex(int audio_fd)
{
        /* Find out if the device supports full-duplex operation. The device mu
         * be open to do this, so if we're passed -1 as a file-descriptor we op
         * the device, do the ioctl, and then close it again...
         */
        int options;
        if (audio_fd == -1) {
                audio_fd = vox_audio_open_rw(O_RDONLY);
                if (ioctl(audio_fd, SNDCTL_DSP_GETCAPS, &options) == -1) {
                        vox_audio_close(audio_fd);
                        return FALSE;
                }
                vox_audio_close(audio_fd);
                return (options & DSP_CAP_DUPLEX);
        }
        /* Audio device already open */
        if (ioctl(audio_fd, SNDCTL_DSP_GETCAPS, &options) == -1 ) {
                return FALSE;
        }
        return (options & DSP_CAP_DUPLEX);
}

>  However, there is a
> problem with older rat versions and newpcm.

> There was a time with the previous pcm driver when some half duplex
> cards successfully opened O_RDWR, so an AIOGCAP call with
> AFMT_FULLDUPLEX check was necessary to determine if the card really
> was full duplex.  Under newpcm open O_RDWR fails for half duplex
> cards.  However, the use of AFMT_FULLDUPLEX is deprecated (or
> forgotten) under newpcm so applications using this test fail to
> realize the device is full duplex, e.g. rat.

rat-3.0.35 right the one I've fixed to work with newpcm, used AIOGFMT with
AFMT_FULLDUPLEX, not AIOGCAP. But the problem was in O_RDONLY rather than in
deprecated calls (because I tried both).

> The current rat source code probes for which pcm is present and acts

> accordingly.  The current ports version of rat needs updating to
> reflect the changes as does the rat web page.  We'll try to do this
> soon.

That would be great (I still haven't seen 4.2.9 sources, because it takes too
long to fetch them ;) Hope your new port will solve all problems!

> - Orion.

Regards,
    Anton

--
Anton Voronin

Ural Regional Center of FREEnet,
Southern Ural State University,
Chelyabinsk, Russia




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message