Re: i810 audio patch

[Doug Ledford <dledford@redhat.com>]

Nathan Bryant wrote:

> 
> 
> got this during a quake run with only DEBUG_INTERRUPTS enabled
> 
> it seems that we aren't making it properly chase its tail during mmap 
> mode.


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 :-/

> so it runs through once and then stops. the final timeout is 
> waiting for a completion that's never going to come.
> 
> Dec  4 23:33:50 lasn-001 kernel: Intel 810 + AC97 Audio, version 0.07, 
> 23:28:08 Dec  4 2001
> Dec  4 23:33:50 lasn-001 kernel: PCI: Setting latency timer of device 
> 00:1f.5 to 64
> Dec  4 23:33:50 lasn-001 kernel: i810: Intel ICH 82801AA found at IO 
> 0x2400 and 0x2000, IRQ 17
> Dec  4 23:33:51 lasn-001 kernel: i810_audio: Audio Controller supports 2 
> channels.
> Dec  4 23:33:51 lasn-001 kernel: ac97_codec: AC97 Audio codec, id: 
> 0x4144:0x5360 (Analog Devices AD1885)
> Dec  4 23:33:51 lasn-001 kernel: i810_audio: AC'97 codec 0 Unable to map 
> surround DAC's (or DAC's not present), total channels = 2
> Dec  4 23:33:51 lasn-001 kernel: i810_audio: setting clocking to 41231
> Dec  4 23:34:00 lasn-001 kernel: NVRM: AGPGART: allocated 257 pages
> Dec  4 23:34:00 lasn-001 kernel: NVRM: AGPGART: allocated 128 pages
> Dec  4 23:34:00 lasn-001 kernel: CHANNEL NUM 1 PORT 10 IRQ ( ST8 DAC HWP 
> 16384,0,16384
> Dec  4 23:34:00 lasn-001 kernel: COMP 8 )
> Dec  4 23:34:01 lasn-001 kernel: CHANNEL NUM 1 PORT 10 IRQ ( ST8 DAC HWP 
> 32768,16384,16384
> Dec  4 23:34:01 lasn-001 kernel: COMP 16 )
> Dec  4 23:34:01 lasn-001 kernel: CHANNEL NUM 1 PORT 10 IRQ ( ST8 DAC HWP 
> 49152,32768,16384
> Dec  4 23:34:01 lasn-001 kernel: COMP 24 )
> Dec  4 23:34:01 lasn-001 kernel: CHANNEL NUM 1 PORT 10 IRQ ( ST15 DAC 
> HWP 65536,49152,16384
> Dec  4 23:34:01 lasn-001 kernel: COMP 32 DAC HWP 65536,65536,0
> Dec  4 23:34:01 lasn-001 kernel: LVI DAC HWP 65536,65536,0
> Dec  4 23:34:01 lasn-001 kernel: DCH - STOP )
> Dec  4 23:34:02 lasn-001 kernel: cdrom: open failed.
> Dec  4 23:34:03 lasn-001 kernel: DAC HWP 65536,65536,0


Interesting...two seconds after the buffer ran out of data, quake 
*finally* calls one of the ioctls that then calls i810_update_ptrs()...


> Dec  4 23:34:07 lasn-001 kernel: NVRM: AGPGART: freed 128 pages
> Dec  4 23:34:07 lasn-001 kernel: NVRM: AGPGART: freed 257 pages
> Dec  4 23:34:07 lasn-001 kernel: DAC HWP 65536,65536,0
> Dec  4 23:34:10 lasn-001 kernel: i810_audio: drain_dac, dma timeout?


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).


> 



-- 

  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems