Quoting Eric S. Johansson <[EMAIL PROTECTED]>:

> At 05:23 PM 4/19/2001 -0700, Dmitri wrote:
> >Quoting Eric S. Johansson <[EMAIL PROTECTED]>:
> >a) load module "audio.o"
> >b) plug the microphone in
> >c) point your audio software to /dev/audio.
> 
> did that and got some interesting results (see further down)
> 
> 
> >That's it. In case of problems you always can test the thing by
> >
> >$ od -t x2 < /dev/audio
> >
> >which should print 16-bit numbers that change as you speak. IIRC,
> >they are signed short integers.
> 
> when I tried this test from /dev/audio, what I saw was a bunch of ff7f/ff80 
> type numbers with no audio input.  Speaking did not give me a large range 
> of numbers but that's probably just an artifact of the default volume 
> setting.  The first byte never changed from ff.  Doing a little snooping, I 
> discovered that the OSS sound driver for my laptop soundcard is probably an 
> 8-bit driver.

It all depends on default settings of the driver. I am not that
good in audio ioctls yet :-( But you can use 'rec' and 'play' commands
to experiment, they do change settings as needed, and they have quite
useful --help option.

But I wouldn't be to worried about internal structure of the audio data.
All you need is to make it work with your speech recognition software.

> So I try the same test on /dev/audio1 and I get very different numbers 
> looking like 8080 7f80 807f and other things looking like it's just two 
> samples.  Am I getting messed up by the built-in driver forcing the USB 
> driver to 8-bit?

It is probably default setting too. USB devices have several "native"
formats that they are willing to produce or consume, and on top of that
any software can convert formats too. Do not worry about that - until
it causes a problem.

> capture audio data; talking real loud:
> 
> 0022460 7376 7576 7c72 8580 9592 9395 7d8b 6671

Yes, this is 8-bit stream. Value 0x80 is silence (center line) there.

> an unrelated problem seems to be that the built-in audio somehow seems to 
> turn on the built-in microphone and I get this nice little feedback loop 
> between the built-in microphone and the built-in speakers.

Use a mixer app (like gmix) and unclick "Recording" button on the
built-in card tab.

> I'm wondering if I should go through the hassle of trying to build ALSA 
> into the system (remember, I have limited hand use)or just going with the 
> for fee OSS drivers.

You want ALSA only if the kernel driver does not support your builtin
sound card. But you say it works, so don't worry about that. USB audio
device does not need ALSA alltogether.

> I'm also having trouble with getting the mixers to 
> work with the USB device.
> They only want to work with the built-in device.

> May 12 12:54:31 ccd kernel: usb.c: registered new driver audio
> May 12 12:54:31 ccd kernel: usbaudio: device 2 audiocontrol interface 0 has 
> 1 input and 0 output AudioStreaming interfaces
> May 12 12:54:31 ccd kernel: usbaudio: device 2 interface 1 altsetting 0 
> does not have an endpoint
> May 12 12:54:31 ccd kernel: usbaudio: device 2 interface 1 altsetting 1: 
> format 0x00000010 sratelo 8000 sratehi 48000 attributes 0x01
> May 12 12:54:31 ccd kernel: usbaudio: constructing mixer for Terminal 2 
> type 0x0101

You have mixer, it has been constructed by the driver. Have a look
at gmix, it should have two tabs - one for each audio device.

> May 12 12:54:31 ccd kernel: usbaudio: workaround for broken Philips Camera 
> Microphone descriptor enabled

I remember that someone added this hack, but why YOU see it? Maybe
Philips camera and your microphone use the same chip? Don't know.
It could be a problem.

> [root@ccd /root]# ls -l /dev/audio* /dev/dsp*
> crw-------    1 esj      sys       14,   4 Aug 24  2000 /dev/audio
> crw-------    1 esj      sys       14,  20 Aug 24  2000 /dev/audio1
> crw-------    1 esj      sys       14,   7 Aug 24  2000 /dev/audioctl
> crw-------    1 esj      sys       14,   3 Aug 24  2000 /dev/dsp
> crw-------    1 esj      sys       14,  19 Aug 24  2000 /dev/dsp1
> crw-------    1 esj      root      55,   0 Aug 24  2000 /dev/dsp56k
> 
> I also don't understand why they are owned by me instead of audio or 
> something else.

Because you need r/w access to them. You could play with groups and
permissions, of course, but if you are the only user on that laptop
then this is a quick-and-dirty solution. Again, don't worry until
it causes problems.

You need now to try your audio application. Use 'rec' to make sure
you can capture sound from your USB microphone, and use 'play' to
play it back on internal sound card. Try several formats just in
case. I don't see anything being badly broken or out of order.
It's time to start using your voice recognition software.

Thanks,
Dmitri

-- 
I guess it is one of the disadvantages of VLSI that it's no longer
so feasible to add instructions to your machines.
  (Richard M. Stallman)

PGP signature

Reply via email to