On Tue, 7 Jan 2003, Jeff Pierce wrote:
> I am really getting frustrated.
>
> I am writting a VOIP app for amateur radio which has been half duplex
> sound, but now needs to go to FULL duplex.
> My app uses OSS type access, ioctl calls, as many using it only have OSS
> free from teh kernel distrobutions.
>
> Ok, I get alsa 0.9.0rc6 and compile and install it for via82c686, which
> I get running with the half duplex code. No problem. I then write a
> super simple app using OSS ioctl to test if full duplex will work that
> way, not using alsa api. It simply reads the /dev/dsp and just writes
> the buffer right back to /dev/dsp. Run it on and it works no problem.
> Using alsamixer to change the line out audio on the pcm control, etc.
>
> Ok I have another Linux box with a SB Vibra16C to do testing between the
> two boxes. I install alsa 0.9.0rc6 on it and install for sb16. I try
> running my full duplex app on it. What an abortion!!!
>
> First, in alsamixer, where is the "mixer" control to keep mic from going
> directly to output. I find "auto mic", UNMUTING it stops mic from output
> with no app working.
>
> Then the really big problem. When running my fullduplex app, the mic
> audio is once again at the output, albeit at a lower volume and the pcm
> control HAS NO EFFECT on it, and the actual audio read from and written
> to /dev/dsp is 5 seconds behind my speaking it, if it makes it at all.
> This is the audio that the pcm control will vary.
>
> It seems to me the snd-sb16 has a whole lot of problems, beacause code
> that works perfectly on a via82c686 alsa driver screws up on a sb16 alsa
> driver.
>
> Even my half duplex VOIP code that runs perfectly on oss SB16 and alsa
> via82c686 has problems running with alsa sb16. Run the sb16 oss drivers
> and audio is IMMEADIATLY sent to the receiving machine. Run it using
> alsa sb16 and sometimes it has a 5-7 second delay BEFORE it is sent.
> Stop the app and restart it,nothing done to alsa drivers, and you do not
> have the delay.
>
> What's wrong with the alsa sb16 driver?
See these comments in the SB driver:
* Note: This is very ugly hardware which uses one 8-bit DMA channel and
* second 16-bit DMA channel. Unfortunately 8-bit DMA channel can't
* transfer 16-bit samples and 16-bit DMA channels can't transfer
* 8-bit samples. This make full duplex more complicated than
* can be... People, don't buy these soundcards for full 16-bit
* duplex!!!
* Note: 16-bit wide is assigned to first direction which made request.
* With full duplex - playback is preferred with abstract layer.
*
* Note: Some chip revisions have hardware bug. Changing capture
* channel from full-duplex 8bit DMA to 16bit DMA will block
* 16bit DMA transfers from DSP chip (capture) until 8bit transfer
* to DSP chip (playback) starts. This bug can be avoided with
* "16bit DMA Allocation" setting set to Playback or Capture.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Alsa-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-user
