Re: i810_audio

From: Thomas Gschwind (
Date: Fri Jan 04 2002 - 21:13:29 EST

Hi everybody,

On Wed, Jan 02, 2002 at 04:56:39PM -0500, 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.

I have integrated the SiS patches into Doug's code. Chances are that
it works now also in combination with artsd. Can anybody test this
please? And report your success (or failure)? In case it does not
work you might want to change the fragsize to dmabuf->userfragsize
inside the i810_poll function (line 1596). If I use
dmabuf->userfragsize, however, I get loads of DMA buffer
over/underruns in combination with xmms. According to the sepc, I
think dmabuf->fragsize should be as correct as dmabuf->userfragsize.
I have not found and minimum available space requirement in the poll
man page or the OSS documentation I have?

The patch attached to this email is still relative to the
drivers/sound/i810_audio.c file from the 2.4.17 kernel distribution.
A patched i810_audio.c can be found at

Fixes I applied except for the SiS integration:
* drain_dac
  Use interruptible_sleep_on_timeout instead of schedule_timeout.
  I think this is cleaner. Set the timeout to
  (dmabuf->count * HZ * 2) / (dmabuf->rate * 4)
  since we play dmabuf->rate*4 bytes per second (16bit samples stereo).
  Added stop_dac at the end. Otherwise the system gets locked up sometimes.
* i810_read, i810_write
  Set the timeout to (dmabuf->size * HZ * 2) / (dmabuf->rate * 4)
  since we record / play dmabuf->rate*4 bytes per second (16bit samples
  Don't change the recording / playback buffer. A detailed explanation
  can be found within the patch

Please correct me, if any of the above is wrong.

> 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...

Thanks for the hint! Never was my plan; just did not know that Doug
had more recent code than the code found in the standard kernel


Thomas Gschwind                      Email:
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

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to More majordomo info at Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:27 EST