From: Nathan Bryant <nbryant@optonline.net>
To: Doug Ledford <dledford@redhat.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mario Mikocevic <mozgy@hinet.hr>
Subject: Re: i810 audio patch
Date: Wed, 05 Dec 2001 02:24:03 -0500 [thread overview]
Message-ID: <3C0DCB93.20304@optonline.net> (raw)
In-Reply-To: <3C0C16E7.70206@optonline.net> <3C0C508C.40407@redhat.com> <3C0C58DE.9020703@optonline.net> <3C0C5CB2.6000602@optonline.net> <3C0C61CC.1060703@redhat.com> <20011204153507.A842@danielle.hinet.hr> <3C0D1DD2.4040609@optonline.net> <3C0D223E.3020904@redhat.com> <3C0D350F.9010408@optonline.net> <3C0D3CF7.6030805@redhat.com> <3C0D4E62.4010904@optonline.net> <3C0D52F1.5020800@optonline.net> <3C0D5796.6080202@redhat.com> <3C0D5CB6.1080600@optonline.net> <3C0D5FC7.3040408@redhat.com> <3C0D77D9.70205@optonline.net> <3C0D8B00.2040603@optonline.net> <3C0D8F02.8010408@redhat.com> <3C0D9456.6090106@optonline.net> <3C0DA588.2080000@optonline.net> <3C0DAC2C.8060506@redhat.com>
Doug Ledford wrote:
> Yes and no. We aren't chasing our tail, but that's because the
> application is suppossed to call the GETOPTR ioctl in order to trigger
> a pointer update. In short, the GETOPTR ioctl is our cue that the
> application knows about the empty space and will fill it. We can
> always make the thing chase it's tail unconditionally, but then you
> risk playing total garbage when the application falls behind :-/
This is what happens under most of the drivers i've played quake with
(under DOS too, I think). OSS and OSS/Free, and most of the other PCI
drivers I've looked at, I believe they don't actually program the DMA
engine during GETOPTR calls. Actually one could argue that in the case
of quake it's better to let it chase its tail indefinitely (that's what
they seem to have assumed when they wrote the game anyway according to
comments in the source code) because that allows ambient sounds to
continue uninterrupted during some slowdown, eg possible network
congestion. (The side effect is that sometimes you end up with endlessly
repeating weapon sound effects if you fire during congestion but of
course that coincidence happens less often than congestion itself)
> I see no reason to drain the dac on close for mmaped stuff. The
> application can check GETOPTR to see if the last stuff has played if
> it really cares that much. I'm going to skip the drain_dac() calls on
> mmap from now on. That will solve that problem (and it's also the
> right thing to do if we are chasing our tail and have set the software
> pointer to God only knows where as far as the final sounds are
> concerned).
yep...
next prev parent reply other threads:[~2001-12-05 7:24 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-04 0:20 i810 audio patch Nathan Bryant
2001-12-04 4:26 ` Doug Ledford
[not found] ` <3C0C58DE.9020703@optonline.net>
2001-12-04 5:18 ` Nathan Bryant
2001-12-04 5:40 ` Doug Ledford
2001-12-04 6:07 ` Nathan Bryant
2001-12-04 7:08 ` Nathan Bryant
2001-12-04 16:46 ` Doug Ledford
2001-12-04 20:14 ` Nathan Bryant
2001-12-04 20:16 ` Doug Ledford
2001-12-04 14:35 ` Mario Mikocevic
2001-12-04 19:02 ` Nathan Bryant
2001-12-04 19:21 ` Doug Ledford
2001-12-04 20:41 ` Nathan Bryant
2001-12-04 21:15 ` Doug Ledford
2001-12-04 21:39 ` Nathan Bryant
2001-12-04 21:53 ` Nathan Bryant
2001-12-04 22:29 ` Nathan Bryant
2001-12-04 22:49 ` Nathan Bryant
2001-12-04 23:09 ` Doug Ledford
2001-12-04 23:31 ` Nathan Bryant
2001-12-04 23:44 ` Doug Ledford
2001-12-05 1:26 ` Nathan Bryant
2001-12-05 2:48 ` Nathan Bryant
2001-12-05 3:05 ` Doug Ledford
2001-12-05 3:28 ` Nathan Bryant
2001-12-05 4:25 ` Doug Ledford
2001-12-05 5:14 ` Nathan Bryant
2001-12-05 5:23 ` Doug Ledford
2001-12-05 20:04 ` Nathan Bryant
2001-12-05 20:05 ` Nathan Bryant
2001-12-05 20:10 ` Doug Ledford
2001-12-05 21:12 ` Nathan Bryant
2001-12-05 21:25 ` Doug Ledford
2001-12-05 21:36 ` Nathan Bryant
2001-12-05 21:56 ` Nathan Bryant
2001-12-05 22:31 ` Doug Ledford
2001-12-05 22:43 ` Doug Ledford
2001-12-05 23:46 ` Nathan Bryant
2001-12-05 23:51 ` Doug Ledford
2001-12-05 23:57 ` Nathan Bryant
2001-12-06 0:25 ` Doug Ledford
2001-12-06 0:50 ` Nathan Bryant
[not found] ` <3C0EC0ED.3000603@optonl! ine.net>
2001-12-06 0:55 ` Doug Ledford
[not found] ` <3C0EC219.8010107@redhat! .com>
2001-12-06 2:53 ` Nathan Bryant
[not found] ` <3C0EDDC2.608@optonl! ine.net>
2001-12-06 3:39 ` Doug Ledford
[not found] ` <3C0EC219.8010107@redhat!.com>
[not found] ` <3C0EE865.1090607@red! hat.com>
2001-12-06 4:02 ` Nathan Bryant
2001-12-06 4:09 ` Doug Ledford
2001-12-06 15:45 ` i810 audio patch (it _works_ for me :) Mario Mikocevic
2001-12-06 17:00 ` i810 audio patch Pascal Junod
2001-12-05 4:41 ` Nathan Bryant
2001-12-05 5:10 ` Doug Ledford
2001-12-05 5:35 ` Nathan Bryant
2001-12-05 7:24 ` Nathan Bryant [this message]
2001-12-04 23:05 ` Doug Ledford
2001-12-04 9:03 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2001-12-06 19:49 Nathan Bryant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C0DCB93.20304@optonline.net \
--to=nbryant@optonline.net \
--cc=dledford@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mozgy@hinet.hr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox