From: Mike <cekim@ix.netcom.com>
To: linux-sound@vger.kernel.org
Subject: opti linux alpha full dupleX
Date: Fri, 25 Sep 1998 02:21:06 +0000 [thread overview]
Message-ID: <marc-linux-sound-90671637106977@msgid-missing> (raw)
I have posted a few times to various linux news groups regarding this
problem. I have made some progress, but I need some assistance from
someone who might have hacked through various kernel/sound issues
already.
Quick summary:
1. opti 82c931 works under OSS/LINUX eval with 2.0.35 kernel in full
duplex mode.
2. if only one DMA is assigned to dma/dma16 it records and plays
correctly in SIMPLEX mode.
3. if two dma's are assigned (0 and 1 in my case) it play correctly but
recording results in an infinite buffer overrun and subsequent effective
crash of the sound system (it is no longer available and will not be so
until I reboot).
4. Alpha 164LX RH5.1 base with 2.1.121 patched to 122 kernel. OSS
system = that which comes with 2.1.121 (3.8XX)
I have reduced the mad16 driver to a hardcoded sequence which loads the
address/dma values both to the various registers and to the attachment
to the ad1848 driver.
I was hoping to find something in the mad16 driver which was not
correct, but it all appears to conform with the data sheet and the end
result is the same with the original driver (buffer overrun).
I added some debug to dmabuf.c and discovered:
(this is at about 1145 in the code)
1. qlen is greater than nbufs by one (or perhaps the reverse, but I do
recall that the result is an underflow - the driver is looking for one
more than the card has to offer).
2. it is performing a dma on channel "0" despite the fact that the
driver assigned dma 1 as the capture channel.
This weekend, if I get a chance, I plan to perform the same strip of
ad1848 to find out why the dma channels are being misused (or understand
why that is correct?).
If someone out there could point me to an easier solution than
systematically tearing apart the sound driver structure, I would VERY
appreciative.
Thanks,
/Mike
reply other threads:[~1998-09-25 2:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=marc-linux-sound-90671637106977@msgid-missing \
--to=cekim@ix.netcom.com \
--cc=linux-sound@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox