Re: [Openvortex-dev] Low volume, distortion, etc

[Ryan Underwood]

On Sat, Jun 14, 2003 at 08:52:53PM -0500, Callum Lerwick wrote:
> >I also have an SQ2500 and have experienced the exact same symptoms
> >dating back to the original aureal driver.  There must be something
> >peculiar about the SQ2500 in particular, because the people with plain
> >au8830 cards never complain about this problem.
> 
> I have the pre-SQ whitebox au8830 card (dell?) and still have these 
> problems.

What is your motherboard chipset?  I have a MS-6163 BXMaster with
i440BX.  The Vortex is sharing an IRQ with the video card, a Matrox
G400.  My CPU is a Celeron-II 533 overclocked at 840mhz.

The stereo swapping does seem to correspond with CPU activity for me,
though not necessarily a high CPU load.  Certain things will trigger it
every time, such as reloading a window in Mozilla.

> Just pulled the latest CVS. 1) The audio levels are great. PCM at 100% 
> and master at %50 gives me nice clear undistorted audio. Put master 
> higher and it gets very very loud, yet crystal clear. (Yay 200w amp and 
> 65w speakers...)

Great!

> 2) Start/end playback seems to be fixed. No more cutting things off.

Again, more improvements.

> 3) Stereo swapping still there, but seems to happen less. Related to 
> fragment size fix?

This does seem to be some sort of underflow condition happening
somewhere.  If I were to hazard a guess, it is like the vortex chip is
doing something like the following:

1. Starts playing a stream with two DMA buffers in memory, one for each
output stream

2. the buffer for the left channel runs out due to CPU activity, poor
granularity, etc; and the chip, without having received a signal to stop
playing, barrels onward through memory, runs into the buffer for the
right channel after passing through a little garbage (that's the "click/pop"
you hear when the swapping happens), and continues playing the right
channel's DMA buffer on the left channel's stream instead.  The same
thing happens on the right channel, so now the chip is playing the wrong
buffer into each output stream.

3. Restarting playback starts the whole thing over, until the chip hits
an underrun condition on a buffer again.

The problem with this theory is that 1) I haven't had time to see if
it's supported by the code, and 2) I don't know how the chip would Keep
playing the buffers on the wrong streams, even as new buffer data gets
loaded into memory by the driver from userspace.

Only other thing I can think of would be the AC97 codec getting
confused, but as it requires very little in the way of state
maintenance, I have trouble seeing how it could be getting confused by
outside forces.

HTH,
-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253