public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 2.5.50 - sound driver issues with i810_audio
@ 2002-12-09 21:24 Valdis.Kletnieks
  2002-12-11 22:59 ` Doug Ledford
  0 siblings, 1 reply; 3+ messages in thread
From: Valdis.Kletnieks @ 2002-12-09 21:24 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2547 bytes --]

(please cc: on replies)

Dell Latitude C840.  Under 2.4.18, sound works adequately, using these drivers:

Intel 810 + AC97 Audio, version 0.21, 14:20:41 Jun  5 2002
PCI: Found IRQ 11 for device 00:1f.5
PCI: Sharing IRQ 11 with 00:1f.6
PCI: Setting latency timer of device 00:1f.5 to 64
i810: Intel ICH3 found at IO 0xdc80 and 0xd800, IRQ 11
i810_audio: Audio Controller supports 6 channels.
ac97_codec: AC97 Audio codec, id: 0x4352:0x595b (Unknown)
i810_audio: AC'97 codec 0 supports AMAP, total channels = 2
ac97_codec: AC97 Modem codec, id: 0x5349:0x4c21 (Unknown)

Under 2.5.50, I'm using:

intel8x0: clocking to 48000
ALSA device list:
  #0: Intel 82801CA-ICH3 at 0xd800, irq 11

Sound almost-kinda-sort of works - audio comes out, and sometimes sounds OK,
but there seems to be a buffering issue.  Short bursts of audio (less than a
few seconds) work OK, but longer audio clips tend to break up into distortion.
The odd part is *how* it breaks up.

I've been testing with a several-second audio clip I generated with Festival,
a female voice saying "New mail from I B M I-source List Server".  When I
play it, "New mail from" is almost always OK, sometimes all of it is OK, and
usually it loses it about halfway through.  What comes out sounds like:

New Mail from I B I-sour<M>ce <distorted>list server  st server"

Yes, it sounds like it's taking about half the frames and delaying them a chunk
of time.  The distortion sounds like transients caused by the discontinuities
between frames.  Looking at the code, it seems like the driver is sometimes
managing to get "behind" when adding frames to the ring buffer, so some of
the frames have to wait for a complete loop through before they get output,
or "ahead" so they're played now rather than in proper order, or something.

sound/core/pcm_lib.c has this warning:

/* CAUTION: call it with irq disabled */
int snd_pcm_update_hw_ptr(snd_pcm_substream_t *substream)
{

and a race condition on the various hw_ptr variables *would* explain the
symptoms I'm seeing.  For what it's worth, everything listed in 'lspci' is
on IRQ 11.  I'm wondering if CONFIG_PREEMPT is allowing something else to
get called that unblocks IRQ 11 when pcm_lib thinks it's blocked - but I've
tested this mostly under near-zero loads - no CPU or paging pressure.  Also,
my 2.4.18 kernel has the PREEMPT patches on it as well, so I'm not TOTALLY
convinced they're to blame....

This ring any bells? Any advice how to proceed debugging?
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: 2.5.50 - sound driver issues with i810_audio
  2002-12-09 21:24 2.5.50 - sound driver issues with i810_audio Valdis.Kletnieks
@ 2002-12-11 22:59 ` Doug Ledford
  2002-12-12  5:51   ` Valdis.Kletnieks
  0 siblings, 1 reply; 3+ messages in thread
From: Doug Ledford @ 2002-12-11 22:59 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: linux-kernel

On Mon, Dec 09, 2002 at 04:24:21PM -0500, Valdis.Kletnieks@vt.edu wrote:
> a female voice saying "New mail from I B M I-source List Server".  When I
> play it, "New mail from" is almost always OK, sometimes all of it is OK, and
> usually it loses it about halfway through.  What comes out sounds like:
> 
> New Mail from I B I-sour<M>ce <distorted>list server  st server"
> 
> Yes, it sounds like it's taking about half the frames and delaying them a chunk

This sounds like the problem some chipsets had with wrapping counters in 
the dma pointer read code.  Basically, when the sg segment is advanced to 
the next segment, the offset counter would not be simultaneously cleared 
but instead would be momentarily delayed before the clear occured and a 
read at just the wrong time could result in us thinking that the buffer 
was a full sg segment farther than it was.  There were changes made to the 
oss i810 driver around version 0.18 to solve this problem if I remember 
correctly.  Similar code may be needed in the alsa driver, I'm not sure 
because I have looked at it or tried it (my machine with an i810 doesn't 
run 2.5 kernels).



-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: 2.5.50 - sound driver issues with i810_audio
  2002-12-11 22:59 ` Doug Ledford
@ 2002-12-12  5:51   ` Valdis.Kletnieks
  0 siblings, 0 replies; 3+ messages in thread
From: Valdis.Kletnieks @ 2002-12-12  5:51 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

On Wed, 11 Dec 2002 17:59:28 EST, Doug Ledford said:

> This sounds like the problem some chipsets had with wrapping counters in 
> the dma pointer read code.  Basically, when the sg segment is advanced to 
> the next segment, the offset counter would not be simultaneously cleared 
> but instead would be momentarily delayed before the clear occured and a 
> read at just the wrong time could result in us thinking that the buffer 
> was a full sg segment farther than it was.  There were changes made to the 
> oss i810 driver around version 0.18 to solve this problem if I remember 
> correctly.  Similar code may be needed in the alsa driver, I'm not sure 
> because I have looked at it or tried it (my machine with an i810 doesn't 
> run 2.5 kernels).

Ahh... That would exactly explain what I was seeing, and why it worked under
2.4.18 for me, and gives me a good idea where to look (the relevant code in the
alsa and oss drivers is pretty similar, there's only so many ways to code a
ring buffer when the other part is cast in silicon. ;)

/Valdis


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-12-12  5:43 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-09 21:24 2.5.50 - sound driver issues with i810_audio Valdis.Kletnieks
2002-12-11 22:59 ` Doug Ledford
2002-12-12  5:51   ` Valdis.Kletnieks

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox