On 11-03-08 15:07, Bob Tracy wrote:

Both native ALSA and emulated OSS playback are broken based on last 
night's testing.  Just to rule out sound hardware issues, this morning I
built a 2.6.25-rc4 kernel with OSS (sb driver), and that seems to be 
working fine.

Okay... From your testing report:

quoted

$ sox foo.wav -t alsa default

Playback results in infinite loop over the first quarter second or so
of audio.  Using "aplay" results in same looping behavior over a longer
segment of audio -- maybe a half second.

This is behaviour consistent with the IRQ being dead ...

quoted

quoted

$ sox foo.wav -t ossdsp /dev/dsp

Identical results to using "play" (as expected): for the 50K ".wav"
file, I hear the entire file approx. 1.8 times.

... and this isn't. Worse yet, we have a conflicting report from Michael 
where things are fine while using aplay and I'm seeing nothing particularly 
suspicious recently. I suppose it used to work and I suppose the behaviour 
you are describing above is 100% repeatable?

Given that you can use aplay -- probably no difference with "aplay -M" ?

To get to the bottom of this we might need to get a specific failed version 
(for readers, it's not been verified that this is a regression since 2.6.24) 
but we can try to get lucky first.

The most recent change to sound/isa/es18xx.c that's not utterly impossible 
to have made a difference is 1bc9eed379399484d3f5d5a0834674983969bc1, 
"es18xx: Enable wavetable input from ESS chips". I don't know if you're a 
GIT user. If you are, you can revert it simply with

$ git revert 1bc9eed3

If you're not a GIT user, applying the attached should work. Unlikely, but 
as said, we can try.

I tried a few rmmod/insmod cycles with different values for dma2.
Results as follows:

(a) dma2=1 (== dma1): no change
(b) dma2 option omitted : no change
(c) dma2=-1 : probe failed

Okay. A and B seem to at least confirm it's not the 16-bit DMA.

Rene.