[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47D6A28C.4060804@keyaccess.nl>
Date: Tue, 11 Mar 2008 16:17:32 +0100
From: Rene Herman <rene.herman@...access.nl>
To: Bob Tracy <rct@...s.com>
CC: Takashi Iwai <tiwai@...e.de>,
ALSA devel <alsa-devel@...a-project.org>,
Michael Cree <mcree@...on.net.nz>,
linux-kernel@...r.kernel.org,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
linux-alpha@...r.kernel.org, Krzysztof Helt <krzysztof.h1@...pl>
Subject: Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha
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:
>> $ 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 ...
>> > $ 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.
View attachment "es18xx_revert_wavetable_input.diff" of type "text/plain" (763 bytes)
Powered by blists - more mailing lists