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
http://www.infosys.tuwien.ac.at/Staff/tom/SiS7012/
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
stereo).
* SNDCTL_DSP_GETxPTR
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
distribution.
Thomas
-- Thomas Gschwind Email: tom@infosys.tuwien.ac.at 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
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:27 EST