Date:	Fri, 5 Jun 1998 23:57:58 -0400 (EDT)
From:	Derrick J Brashear <shadow@DEMENTIA.ORG>
Subject: audio as it should be: another snapshot
To:	sparclinux@vger.rutgers.edu

Hi,

I just uploaded another 2.0 audio snapshot to 
ftp://ftp.dementia.org/pub/linux/sparcaudio/audio-2.0.33-980605.tar.gz

As with the previous ones, this one is for 2.0 kernels only, though I do
promise these changes will get into the 2.1 tree soon. A list of what's done
and to do appears below; A patch to make SunOS raplayer work which must be
applied to the kernel is also included. If you have problems other than lack of
support for your LX, 10, 20, please let me know. Enjoy.

-D

(What follows is a long description of what's here, what's in progress, and
what's still to come)

What's here:

a) playback support. Works as near to perfectly in the 4231 as I suspect it
ever will. Presumably works as good as it ever did in the AMD; My IPC is still
down and I can't play with it. Still no support for the DBRI.

b) ioctls. Most of the DSP-style ioctls an OSS-aware application would want to
use are supported. One in particular not yet supported which I wish to fix is
SNDCTL_DSP_SETFMT. What this means is that all those apps you got with RedHat
4.2 should work assuming you only use play. Plus, AUDIO_SETINFO now copies out
the "current state" structure.

c) SunOS compatibility. There's enough STREAMS io compatibility in the audio
midlevel to make raplayer 3.0 for SunOS work, *if* you apply the included patch
to fs/read_write.c. It removes code which causes sys_write to exit when it gets
a 0 length write. The change was already done in 2.1 kernels, and I've had no
problems with it in mine. Alternately, you can use the complete included
fs/read_write.c, which I include from my kernel. This actually makes raplayer 3
work better on my SS4/110 running 2.0.33 than either raplayer 3 or rvplayer 5
do on the Ultra 1/170 running Solaris 2.5.1 in my office. One side effect of
how I did the compatibility, which calls for "asynchronous notification" upon
processing of the buffer inserted by a zero length write (e.g. sending a
SIGPOLL to processes which have registered for it), is that raplayer will
rebuffer needlessly several times when starting, but after that be very stable
and reliable. I'm working on a fix, but right now I can't find a way to do it
without other side effects.

d) pause support was added. The pause support is not yet implemented for the
amd, because I can't test what I believe the correct way to do it is. For the
4231 it's slightly harder because you need to stop dma but not interfere with
what's next up...

e) oh, and monitor gain works correctly for the 4231. i finally got an audio
source when i brought a cable home from work tonight....

Todo:
f) amd sync. put all the features done for 4231 and not for amd yet in the amd

g) dbri support. right now there's no dbri support whatsoever, so the speaker
on my LX sits idle:-(

h) push all this to 2.1. Jakub Jelinek has graciously been testing 2.1 code
I've been sending him as he gets a chance, so when he's satisfied that it
works, I'll push it all into the main CVS branch

j) record support. it's unclear to me if this works for the amd, but it
definitely does not for the 4231. the 4231 requires similar dma support as what
I did for play, and some other work. 

h is currently ongoing, and j should be starting in a few hours. audio input
would complete a project intended to allow me to record from the radio, now
only 21 months after it would last have been useful to me:-)

-D

-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of the message to majordomo@vger.rutgers.edu