Summary:ASTERISK-09400: chan_oss & chan_alsa in conference with zap channels
Reporter:Konstantin Prokazoff (oryx)Labels:
Date Opened:2007-05-08 06:41:50Date Closed:2011-06-07 14:08:27
Versions:Frequency of
Description:chan_oss (& chan_alsa) while belong to same conference with zaptel channels (tested with 1/2/4 E1 circuit-packs) produce pure sound output, while input from sound device acceptable. Tested on: 82801-ICH2 (Analog Devices AD1885) and compat. chips, ALC AC97, SBLive!, ES1371, CMI.


There are no buffering (phase shifting) between two synchronous devices (for example conference with different latency) and sound device.
Comments:By: Joshua C. Colp (jcolp) 2007-05-14 12:05:02

Can you clarify a bit more on what you mean?

By: Konstantin Prokazoff (oryx) 2007-05-15 02:47:04

Can you execute such experiments:
1) console dial to context where simple answer/musiconhold, listen to music quality.
2) console dial to context where simple answer/meetme. While console (in my case oss/dsp) in meetme room, provide incoming call to same conference thru zap trunk (one active channel w'be enough). While console and zap in meetme room, originate call (by spooling or from CLI) with idea to provide same musiconhold source (as used in experiment 1) for this meetme room. Listen to music quality.
Thnx in advance.
Maybe additional info I was provided not truly right, but I haven't ideas or resolution for such situation for today.

By: Konstantin Prokazoff (oryx) 2007-05-18 03:53:53

Have checked yesterday on Diamond Monster Sound card (Aureal chip AU8830). There are no such situation, strange. chan_alsa works fine, but chan_oss no.

By: Tilghman Lesher (tilghman) 2007-11-01 18:00:00

There's clearly a language barrier, and unfortunately, unless we understand what you're trying to say, we can't be of any help.

Feel free to reopen if you can find someone who can write better English and also understands this issue.