From: Manuel Jander <manuel.jander@usm.cl>
To: Raymond <rayau@netvigator.com>,
alsa-devel <alsa-devel@lists.sourceforge.net>,
openvortex-dev <openvortex-dev@nongnu.org>
Subject: Re: Re: au8830 - front / rear channels swapped after first play and Surround40
Date: Sat, 12 Mar 2005 22:10:21 -0300 [thread overview]
Message-ID: <1110676221.4034.28.camel@localhost> (raw)
In-Reply-To: <4232B5ED.1080508@netvigator.com>
Hi Raymond,
On Sat, 2005-03-12 at 17:27 +0800, Raymond wrote:
> > > 3) Is the bug related to "vortex: IRQ fifo error" ?
>
> > No, thats not a bug. Thats normal.
>
> http://lists.gnu.org/archive/html/openvortex-dev/2004-03/msg00007.html
>
> I think the front/rear swap bug is related to that "vortex: IRQ fifo error".
AFAIK the FIFO error occurs only one time, the first time data is being
DMA'ed. It could be that this error is some kind of data underrun, and
it does only happen once, because we never flush the FIFO's when
stopping a stream. Remaining data in the FIFO's may be messing the
channel deinterlacer, because the amount of data loaded in the fifo is
random, generating a random offset. Since the the PCI bus is 32 bit
wide, that problem would not affect stereo streams, because one 32 bit
transaction maps to two 16 bit samples. Only where a frame is more that
32bits, this problem would become apparent. This is just a theory, but
maybe it could be worth a try, to enforce a absolute flush of the FIFO
data when stopping a DMA stream.
> As the hardware equalizer is only connected from the front channels to
> the CODECOUT(0/1) in the ALSA au88x0 driver when playing at 4 channel
> sound through hw:0,0 (adb)
>
[snip!]
> It seem that the patch mentioned in
>
> http://lists.gnu.org/archive/html/openvortex-dev/2003-12/msg00009.html
>
> intened to fixed the problem in the OSS application in
>
> http://lists.gnu.org/archive/html/openvortex-dev/2003-11/msg00016.html
I'm not that sure that these things are related directly. The patch in my
opinion is just hiding either a hardware issue or a software problem. It
may be related to the the way the fifos are stopped and resumed.
>
> 1) Is the FIFO is still suspending not stopped ?
Don't know. AFAIK the fifos can be stopped or just paused. What
difference that makes, i don't know.
Best Regards
--
Manuel Jander
Electronic Engineer
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
next prev parent reply other threads:[~2005-03-13 1:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-12 9:27 au8830 - front / rear channels swapped after first play and Surround40 Raymond
2005-03-13 1:10 ` Manuel Jander [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-03-17 3:23 Raymond
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1110676221.4034.28.camel@localhost \
--to=manuel.jander@usm.cl \
--cc=alsa-devel@lists.sourceforge.net \
--cc=mjander@users.sourceforge.net \
--cc=openvortex-dev@nongnu.org \
--cc=rayau@netvigator.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.