[Fwd: i810_audio]

[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

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

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.

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

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.

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]

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.

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

Damned if I know! Is your system perhaps assigning a shared interrupt between the orinoco and audio?

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

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.