[oops, resending because i used the old lkml address by accident]
Hi Tom,
Can you have a look at Doug Ledford's 0.13 driver? this incorporates
most or all of the fixes you mentioned, except for SiS support, and some
other fixes; it hasn't been incorporated into the main kernel quite yet
because it needs more testing.
it's located at http://people.redhat.com/dledford/i810_audio.c.gz
i've put a lot of work into this driver and i'd like to see everyone
working on i810 code continue to work off a single base of source code
rather than ending up with yet another fork...
thanx,
Nathan Bryant
Nathan Bryant wrote:
> [oops, resending because i used the old lkml address by accident]
>
> Hi Tom,
>
> Can you have a look at Doug Ledford's 0.13 driver? this incorporates
> most or all of the fixes you mentioned, except for SiS support, and
> some other fixes; it hasn't been incorporated into the main kernel
> quite yet because it needs more testing.
Let me allow for a bit of advertising... Hist SiS changes work fine for
me with the exception
of recording.,
On Thu, Jan 03, 2002 at 01:54:43PM +0100, Martin Dalecki wrote:
> Nathan Bryant wrote:
> > Can you have a look at Doug Ledford's 0.13 driver? this incorporates
> > most or all of the fixes you mentioned, except for SiS support, and
> > some other fixes; it hasn't been incorporated into the main kernel
> > quite yet because it needs more testing.
>
>
> Let me allow for a bit of advertising... Hist SiS changes work fine for
> me with the exception
> of recording.,
I did not have the pointer to Doug's latest version of the i810
driver. I will integrate my patches into his latest version and will
send it to the list. I will also have another look at recording but
it would be great if you could be a little bit more specific of your
recording results.
What happened?
How did you try to record?
Did the system crash?
Did the program you used for recording crash?
Was the recording trash?
How did it sound? To fast? To slow? Crackling? Random noise? All of it?
What hardware do you have? K7S5A or a different MB with a SiS735 chipset?
Thanks,
Thomas
--
Thomas Gschwind Email: [email protected]
Technische Universit?t Wien
Argentinierstra?e 8/E1841 Tel: +43 (1) 58801 ext. 18412
A-1040 Wien, Austria, Europe Fax: +43 (1) 58801 ext. 18491
Thomas Gschwind wrote:
>On Thu, Jan 03, 2002 at 01:54:43PM +0100, Martin Dalecki wrote:
>
>>Nathan Bryant wrote:
>>
>>>Can you have a look at Doug Ledford's 0.13 driver? this incorporates
>>>most or all of the fixes you mentioned, except for SiS support, and
>>>some other fixes; it hasn't been incorporated into the main kernel
>>>quite yet because it needs more testing.
>>>
>>
>>Let me allow for a bit of advertising... Hist SiS changes work fine for
>>me with the exception
>>of recording.,
>>
>
>I did not have the pointer to Doug's latest version of the i810
>driver. I will integrate my patches into his latest version and will
>send it to the list. I will also have another look at recording but
>it would be great if you could be a little bit more specific of your
>recording results.
>
>What happened?
> How did you try to record?
> Did the system crash?
> Did the program you used for recording crash?
> Was the recording trash?
> How did it sound? To fast? To slow? Crackling? Random noise? All of it?
> What hardware do you have? K7S5A or a different MB with a SiS735 chipset?
>
Well my hardware is an Elitegroup, AMI-BIOS, with a SiS735. The AC'97
codec chip, which doesn't
get recognized properly by linux, is a avance logic (AL107) chip. The
whole thing is running
at a fixed 48000 Hz clock, which is derived from the USB host bridge.
XMMS is working fine, since it does understand the issue of fixed
frequency PCM
decoders. mplayer is usable with -ao sdl:esd, aka. piping the output
through esd, since the
esd doesn't have problems with fixed chip codecs. However the sound
frequency
transponder in ESD is really navie. It doesn't do any true filtering
apparently, so
one can hear the overleap frequency from 44.1 kHZ to 48kHz for
example. The artsd from KDE as usuall is failing blatantly and locks the
system hard...
And I don't have neither the time, nor inclination for debuggin it...
(Unless I could compile the whole KDE proerply with some recent gcc-3.x
for RedHat ;-).
Recodring did lockup the system hard as well immediately, no matter what.
However I will certainly try the whole again, since it would be really
nice to have the whole
stuff running properly under KDE. I'm not going to use GNOME in no time ;-).
N'f info?
Martin Dalecki wrote:
[snip]
> example. The artsd from KDE as usuall is failing blatantly and locks
> the system hard...
> And I don't have neither the time, nor inclination for debuggin it...
> (Unless I could compile the whole KDE proerply with some recent
> gcc-3.x for RedHat ;-).
There were numerous problems in the 0.04 i810_audio driver that caused
problems with artsd. It sounds as if Tom has at least partial fixes for
most of these in his patch, but he doesn't mention the poll() problem
that we encountered...
artsd should work with 0.13 if we can get the SiS changes merged in. The
artsd problems weren't specific to the type of hardware changes Tom is
reporting... more like generic problems with the driver's
userland-interface semantics and DMA state tracking.
> Recodring did lockup the system hard as well immediately, no matter what.
Recording is something I never really tested heavily, though it does
seem to work at least minimally on my system (driver-default rates,
etc.) I'd be interested in any feedback as to whether it works in 0.13,
both from SiS users and otherwise...
Other people have said that RealProducer works fine, though, with newer
versions of Doug's driver, at all rates, etc.
I tried the 0.13 driver yesterday. It appears to work fine, but when
I insert my Orinoco WaveLan card they system locks up. I reverted to
the i810 audio driver included in kernel v2.4.16 and this problem
isn't encountered.
Is there a conflict with the orinoco and orinoco_cs drivers from
kernel v2.4.16?
- Nick
Nick Papadonis wrote:
>I tried the 0.13 driver yesterday. It appears to work fine, but when
>I insert my Orinoco WaveLan card they system locks up. I reverted to
>the i810 audio driver included in kernel v2.4.16 and this problem
>isn't encountered.
>
>Is there a conflict with the orinoco and orinoco_cs drivers from
>kernel v2.4.16?
>
>- Nick
>
Damned if I know! Is your system perhaps assigning a shared interrupt
between the orinoco and audio?
Nick Papadonis wrote:
> I tried the 0.13 driver yesterday. It appears to work fine, but when
> I insert my Orinoco WaveLan card they system locks up. I reverted to
> the i810 audio driver included in kernel v2.4.16 and this problem
> isn't encountered.
>
> Is there a conflict with the orinoco and orinoco_cs drivers from
> kernel v2.4.16?
Possibly. If anything it's likely that either the orinoco or the i810
driver is not handling spurious interrupts properly. Now, since I've been
using my i810 device in a machine that doesn't share it's interrupt I can't
*personally* vouch that it handles things properly, but from looking at the
interrupt handler code, it should. The other possibility is that the
orinoco might enable interrupts on the pcmcia slot before it actually
registers its own interrupt handler. If it does, and the card already has
the interrupt line lit up, then it can generate an interrupt storm that
looks like a machine lockup. A way to test that is to unload the i810 sound
driver and anything else that might use the interrupt the orinoco uses, then
load the orinoco, wait until it's fully up and running, then load the i810
driver and see if things work that way. If it does, then it's almost
certainly an init sequence issue in the orinoco driver.
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
Doug Ledford wrote:
> Possibly. If anything it's likely that either the orinoco or the i810
> driver is not handling spurious interrupts properly. Now, since I've
> been using my i810 device in a machine that doesn't share it's
> interrupt I can't *personally* vouch that it handles things properly,
> but from looking at the interrupt handler code, it should. The other
> possibility is that the orinoco might enable interrupts on the pcmcia
> slot before it actually registers its own interrupt handler. If it
> does, and the card already has the interrupt line lit up, then it can
> generate an interrupt storm that looks like a machine lockup. A way
> to test that is to unload the i810 sound driver and anything else that
> might use the interrupt the orinoco uses, then load the orinoco, wait
> until it's fully up and running, then load the i810 driver and see if
> things work that way. If it does, then it's almost certainly an init
> sequence issue in the orinoco driver.
Forgot to mention, my machine is sharing IRQ 17 between a 3c905 and the
i810. So it seems ok here. Perhaps there's a problem with the orinoco
driver's ISR.
I took have problems recording. I'm using the i810 driver
in 2.4.16
I can do:
cat < /dev/sound/dsp > /dev/sound/dsp
and get a few seconds delayed echo of what is going on, as I would expect.
However, if I try to use anything more complicated, it locks up my system
- no keyboard, no network, needs to be hard booted.
The programs I have tried are "rec" which comes with sox-12.17.1 and a
downloaded utility called voice chat.
What happens is: the recording happens, but when the program ends, either
by itself or by being killed, the system locks up.
So maybe this is something to do with restoring settings at the end of the
recording?
Playback happens with no problem.
Below is the lspci output for the sound system, if it is of any use.
If there is any more info anyone wants, please ask.
00:1f.5 Multimedia audio controller: Intel Corporation: Unknown device
2445 (rev 11)
Subsystem: Compaq Computer Corporation: Unknown device 008c
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 5
Region 0: I/O ports at 2000 [size=256]
Region 1: I/O ports at 2400 [size=64]
--
Ben Clifford [email protected]
http://www.hawaga.org.uk/ben/ GPG: 30F06950
(310) 443 4485 (United States) 0709-227-5268 (United Kingdom)
telnet/ssh [email protected] password guest to talk
webcam: http://barbarella.hawaga.org.uk/benc-cgi/watchers.cgi
Job Required - Will do most things unix or IP for money.
Ben Clifford wrote:
> I took have problems recording. I'm using the i810 driver
> in 2.4.16
>
> I can do:
>
> cat < /dev/sound/dsp > /dev/sound/dsp
>
> and get a few seconds delayed echo of what is going on, as I would expect.
>
> However, if I try to use anything more complicated, it locks up my system
> - no keyboard, no network, needs to be hard booted.
>
> The programs I have tried are "rec" which comes with sox-12.17.1 and a
> downloaded utility called voice chat.
>
> What happens is: the recording happens, but when the program ends, either
> by itself or by being killed, the system locks up.
>
> So maybe this is something to do with restoring settings at the end of the
> recording?
>
> Playback happens with no problem.
>
> Below is the lspci output for the sound system, if it is of any use.
>
> If there is any more info anyone wants, please ask.
Your particular report sounds like the recording bugs that have already been
fixed by my 0.13 version of the driver. Please download that and see if
recording works better for you. It can be found at
http://people.redhat.com/dledford/i810_audio.c.gz
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
> Ben Clifford wrote:
> Your particular report sounds like the recording bugs that have already been
> fixed by my 0.13 version of the driver. Please download that and see if
> recording works better for you. It can be found at
> http://people.redhat.com/dledford/i810_audio.c.gz
I dumped that into my kernel source directory - it seems to have pretty
much inverted the problem:
rec now doesn't crash.
However, playback *does* now crash the machine.
It crashes at the same time as rec was crashing, at the end of the
playback, although this time it locks up on something as simple as:
cat anything > /dev/dsp
It manages to display the shell prompt again before crashing.
Its been several years since I attempted to do any kernel debugging - can
someone advise what I can do to get more info?
Ben
--
Ben Clifford [email protected]
http://www.hawaga.org.uk/ben/ GPG: 30F06950
telnet/ssh [email protected] password guest to talk
webcam: http://barbarella.hawaga.org.uk/benc-cgi/watchers.cgi
Job Required - Will do most things unix or IP for money.