Thanks very much for your reply Hannu. On the ION platform running Debian 5.0 (2.6.26-2) hdaudio does share an interrupt, but with a seemingly idle USB device, the interrupt count only increases when using OSS hdaudio. This audio problem exists on same platform running 2.6.30 with OSS 4.1 1052b.
/proc/interrupts CPU0 CPU1 23: 39645 0 IO-APIC-fasteoi ehci_hcd:usb3, oss_hdaudio0 Repeatedly playing the same test WAV consistently shows 80630 interrupts on IRQ 23 and 80630 on nVidia HDA (ossinfo reporting), 18520 with VMIX disabled. The hdaudio exhibits the same characteristics as above when using kernel command line option, noapic /proc/interrupts: CPU0 CPU1 15: 160 0 XT-PIC-XT oss_hdaudio0 ossplay'ing same test WAV shows 80630 interrupts on both IRQ15 and nVidia HDA. On a different hdaudio (ALC883) platform, Fedora 10 (2.6.27.30-170.2.82) using the same OSS version, ossplay'ing the same WAV shows 80634 nVidia interrupts, 18521 without VMIX. As there is shared activity on the IRQ (XT-PIC-XT) I'm unsure which were hdaudio. And hdaudio works fine. ossplay is the only application running on both these dev systems, top shows they're idle. Despite the slow sounding, replay echo and crackle, the audio plays for the correct amount of elapsed time. thanks and regards. --- On Fri, 18/9/09, Hannu Savolainen <ha...@opensound.com> wrote: From: Hannu Savolainen <ha...@opensound.com> Subject: Re: [oss-devel] mouse movement/disk access improves broken CX20561 (hdaudio) To: "Discussion mailing list for developers of OSS" <oss-devel@mailman.opensound.com> Date: Friday, 18 September, 2009, 5:47 AM Hi, Looks like the interrupts from the sound hardware don't get delivered to OSS. Some other device(s) share the same interrupt and they block the sound interrupts. Disk/mouse activity causes interrupts which are delivered to OSS too. If this is the case then /proc/interrupts probably reports the interrupts as XT-PIC (instead of APIC) ones. If this is the case then you need to upgrade to a kernel that has APIC driver for the chipset. Another possibility is that you simply run out of CPU time when playing audio. Maybe there is some other application in background that consumes all the CPU time. Best regards, Hannu -------- Wannabe Tsotsi wrote: > Version info: OSS 4.2 (b 2000/200909171030) (0x00040100) OSS_HG > > Platform: Linux/i686 2.6.26-2-686 #1 SMP Sun Jun 21 04:57:38 UTC 2009 > (debian-5.0) > > > Intel Atom CPU + MCP7a ION + Connextant CX20561 (hdaudio) > > > Audio output seems like it is being played very slowly, more of a variable > frequency buzzing with clicks, with VMIX disabled through ossmix, the audio > is played at almost the correct speed but has replay echoes and crackling.. > > Moving the mouse, or accessing the disk (find, ls, etc) pretty much corrects > the audio speed, removes the replay echoes, leaveing some clicks. The audio > output then reverts to above broken modes when mouse movement/disk access > stops. > > ossplay'ing the same audio test song generates the same number of interrupts > regardless of whether running in broken mode or almost correct, with find(1) > accessing the disk. > > Adjusting vmix0-src, vmix0-channels, max_intrate, src_quality and dma_buffsize > doesn't appear to make any difference. > > Neither does changing kernel clocksource and noapic, etc. > > ossinfo -v3 and ossmix info posted under same subject on 4-Front Linux forum. > > I'd appreciate any ideas you may have on this. > > thanks. > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > oss-devel mailing list > oss-devel@mailman.opensound.com > http://mailman.opensound.com/mailman/listinfo/oss-devel > _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
_______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
