[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: audio?

On Mon, 18 Oct 1999 sharkey@superk.physics.sunysb.edu wrote:

> But if you have an 8-bit wav file, how does endianness matter?  I would think
> that it would be the same either way.  Maybe I'm just naive about audio
> formats.

you probably are. default setting for /dev/audio is 8bit mono ulaw. a wav
may or may not have a header which happens to be of the correct size to be
one or more audio "blocks" and hence not upset things when you cat it to
/dev/audio, i dunno. sun "au" is more my bag, though lately it's been mp3 
or nothing. In reality a player problem like tplay would be your best bet;
If you get noise, add the -x arg (for byte swapping) and try again. I have
a 4231 in my SS4, and I wrote the driver. I assure you, it does work. 

As to /dev/dsp versus /dev/audio, in 2.2 kernels SunOS/Solaris ioctls
worked much better than Linux ioctls. People whined, so I went back and
entirely rewrote the Linux (OSS-compatibility) interface. I checked it
into 2.3 only, because I was operating under the impression 2.2 was
frozen. Later, David Miller fixed a problem in the 2.2 kernel 4231 driver
which I had already fixed another way in 2.3, so I guess I was wrong:-) 
I don't know if he then back-copied my 2.3 changes to 2.2 or not.
Hopefully he'll stick with my 2.3 code base, since it allows tweaking
everything via e.g. aumix. You can turn each input and output on and off,
and change the volume of input and output. You can also turn the "monitor"
(mix mono input to output) on and off.

Anyhow, you *should* be able to get all of drivers/sbus/audio/* and
include/asm-sparc/audioio.h (or include/asm-sparc64/audioio.h if sparc64)
from the CVS tree on cvs.on.openprojects.net, in the devel (2.3) tree,
drop them in your 2.2 kernel, and compile. 

If you then still have problems with the ioctls, send me mail. 


Reply to: