FWIW both ALSA (Debian 5.0) and Vista work fine on this platform.

Is there any data I can gather while running either of these that would be 
useful in getting OSS working properly ?

thanks and regards.


--- On Fri, 18/9/09, Wannabe Tsotsi <wannabetso...@yahoo.co.uk> wrote:

From: Wannabe Tsotsi <wannabetso...@yahoo.co.uk>
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, 1:09 PM

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





      
-----Inline Attachment Follows-----

_______________________________________________
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

Reply via email to