[Home]

Summary:ASTERISK-01595: Alsa can only connect in one direction
Reporter:antonverburg (antonverburg)Labels:
Date Opened:2004-05-12 05:13:29Date Closed:2004-09-25 02:26:27
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) alsa.patch
( 1) asterisk-stable.patch
( 2) asterisk-unstable.patch
Description:Using latest stable release (0.9.0) I cannot connect to an asterisk Console with chan_alsa.so. I can connect from the alsa-asterisk to an OSS asterisk console, but when I try to connect from the OSS-console to the alsa-console, asterisk does not recognize the codec: When executing "iax2 show channels" at the OSS-console, I get the string: "192.3.2.6        superfrog   00004/00001  00003/00004  00000ms  0007ms  UNKN"



****** ADDITIONAL INFORMATION ******

Asterisk-alsa console tested at Fedora core 1 and RH6.2. Asterisk version 0.9.0. I've done a diff with latest CVS-version. Only an extra 1 has been added in the hangup function, so I don't think it will help me much to upgrade to latest  CVS-version.
Comments:By: Mark Spencer (markster) 2004-05-12 15:13:09

You cannot load both OSS and ALSA, what is it you're trying to do?
By: Matthew Fredrickson (mattf) 2004-05-12 17:29:08

What exactly is your setup?

If I understand you correctly, you are calling from a console on one box (running ALSA) to a console on another box (running OSS), no?
By: Matthew Fredrickson (mattf) 2004-05-12 17:32:46

Also, what happens exactly when you make a call from the OSS-console to the ALSA console?  Do the two machines complete the call or is it rejected because of codec incompatibility?
By: antonverburg (antonverburg) 2004-05-13 11:34:38

Another note: I tried different codecs (GSM, alaw and adpcm) but they have all the same problem

edited on: 05-13-04 10:31
By: antonverburg (antonverburg) 2004-05-14 04:00:41

Another supplement: I've changed the extensions.conf on the Alsa machine. Tried different options:

exten => s,1,Dial(CONSOLE/dsp)
exten => s,1,Dial(CONSOLE/alsa)
exten => s,1,Dial(CONSOLE/ALSA)
exten => s,1,Dial(ALSA/default)
exten => s,1,Dial(ALSA/hw:0)
exten => s,1,Dial(ALSA/somerandomvalue)

For every value with CONSOLE/blahblah, * started waiting for blahblah, but blahblah never picket up.

For every value with ALSA/blahblah, * told me "Everyone is busy at this time"

It din't mather if I wrote ALSA or CONSOLE with captions or not.
By: antonverburg (antonverburg) 2004-05-14 05:35:15

Hm, interesting pointer: I've inserted an ast_verbose message in "static struct ast_frame *alsa_read(struct ast_channel *chan)", so that it should tell me when it's initialized, but I never get this message. Seems that it's never initialized, so there's never detection that "needanswer" has been set to 1... Going to have a closer look...
By: antonverburg (antonverburg) 2004-05-14 10:50:22

Don't be sure, but it seems to me that polling fails somewhere.
By: antonverburg (antonverburg) 2004-05-17 10:42:13

I've fixed this bug. Alsacall didn't open a call because there was no beginning-frame. Have a look at alsa.patch. Appy with "patch -u chan_alsa.c alsa.patch".
By: antonverburg (antonverburg) 2004-05-18 07:22:36

Hm, tested today some more things. This bug fixes some of the problems, but not all. I can now make a connection, and Alsa is answering incoming calls, but still the OSS-machine does not recognize the codec. I am going to work for it next days.
By: antonverburg (antonverburg) 2004-05-19 11:28:17

Hm, after days of probing, I think I got interesting details. When executing *wait_for_answer in app_dial.c, it's looking if the pointers winner and in the same are. "if (winner == in) {bla}". When using the OSS-module, they are the same. When using the Alsa module, they always differ exactly 1295750863. When I changed it to "if (winner-in) == 1295750863" I could make a call to a remote (oss) machine. From the remote machine, I still couldn't make a call to the alsa-machine.

It looks strange to me that those pointers always exactly 1295750863 differ. I realy don't know any more what the reason could be from this mysterious failure. Does somebody please have any idea's????
By: Matthew Fredrickson (mattf) 2004-05-20 02:45:13

Hrm... that's interesting.  I think I'll have to take a look at this tomorrow.  I haven't looked at chan_alsa in a while.
By: antonverburg (antonverburg) 2004-05-24 09:25:39

Hm, when I comment out the code "tmp->fds[0] = sounddev;" in chan_oss.c, it does exactly the same thing wrong as the alsa-module. Shouldn't it be possible that the filedescriptor of the alsa module is __not__ correct?
By: antonverburg (antonverburg) 2004-05-24 10:16:09

Also, when I comment away the "tmp->fds[0] = readdev;" and "tmp->fds[1] = cmd[0];" in chan_alsa.c, nothing changes; I can even set up a call, and receive sound from the oss machine. Sending sound still fails... Maybe tmp->fds[0] is not correct???
By: antonverburg (antonverburg) 2004-05-25 11:12:26

Here's what's going wrong:

in channel.c, at (+/-) line 970 to 980, channel.c is checking what sort of frame is passing. If it's an iax2-frame, it should be ignored, if it's a input frame from soundcard, the microphone should be read, and if it's an output frame, the sound should be written to the speakers. To detect the type of the frame, the function ast_fdisset() is been called. This function is defined in the headerfiles (channel.h). For the OSS-module this fucntion works fine, but for ALSA, it's a source of trouble. I used gdb and printf to detect the value of the different c[x]->fps [y]. After that I changed   "if ((res = ast_fdisset(pfds, c[x]->fds[y], max, &spoint)))" to "if (c[x]->fds[y] != 14)". This works fine for the first call. After the hanging up the first call, and making another call, I get a bunch of notice-messages: "May 25 17:08:36 NOTICE[36907952]: chan_iax2.c:2238 iax2_read: I should never be called!"

Does somebody know how to fix the ast_fdisset() function, so that it works for alsa too????
By: antonverburg (antonverburg) 2004-05-26 03:10:42

Hm, CVS-version seems to be upgraded and changed... Trying out the new version...
By: antonverburg (antonverburg) 2004-05-26 04:08:42

Latest (stable) CVS-version still does not work, but *ast_waitfor_nandfds() has been simplified, so it's now easier to understand. I changed the lines 904-913 from channel.c with some ast_verbose functions, in order to see what's going wrong. This is the code I used:

for (y=0;y<AST_MAX_FDS;y++) {
                       if (c[x]->fds[y] > -1) {
                               ast_verbose("c[%d]->fds[%d]=%d, rfds=%d\n",x,y,c[x]->fds[y],rfds);    //<- XXX Added this line
                               if ((FD_ISSET(c[x]->fds[y], &rfds) || FD_ISSET(c[x]->fds[y], &efds)) && !winner) {
                                       /* Set exception flag if appropriate */
                                       if (FD_ISSET(c[x]->fds[y], &efds))
                                               c[x]->exception = 1;
                                       c[x]->fdno = y;
                                       ast_verbose("Succeed at c[%d]->fds[%d]=%d\n",x,y,c[x]->fds[y]); //<- XXX And added this line
                                       winner = c[x];
                               }
                       }
               }


This is the output for OSS-module:

c[0]->fds[7]=11, rfds=1024
c[1]->fds[7]=13, rfds=1024
c[0]->fds[7]=13, rfds=1024
c[1]->fds[0]=10, rfds=1024
Succeed at c[1]->fds[0]=10
c[1]->fds[7]=11, rfds=1024
c[0]->fds[0]=10, rfds=1024
Succeed at c[0]->fds[0]=10
c[0]->fds[7]=11, rfds=1024
c[1]->fds[7]=13, rfds=1024
c[0]->fds[7]=13, rfds=9216
Succeed at c[0]->fds[7]=13
c[1]->fds[0]=10, rfds=9216
c[1]->fds[7]=11, rfds=9216
c[0]->fds[0]=10, rfds=9216
Succeed at c[0]->fds[0]=10
c[0]->fds[7]=11, rfds=9216
c[1]->fds[7]=13, rfds=9216
c[0]->fds[7]=13, rfds=9216
Succeed at c[0]->fds[7]=13

And this is the output for the Alsa-module:

c[1]->fds[0]=13, rfds=65536
c[1]->fds[1]=8, rfds=65536
c[1]->fds[7]=12, rfds=65536
c[0]->fds[0]=13, rfds=65536
c[0]->fds[1]=8, rfds=65536
c[0]->fds[7]=12, rfds=65536
c[1]->fds[7]=16, rfds=65536
Succeed at c[1]->fds[7]=16
c[0]->fds[7]=16, rfds=65536
Succeed at c[0]->fds[7]=16
c[1]->fds[0]=13, rfds=65536
c[1]->fds[1]=8, rfds=65536
c[1]->fds[7]=12, rfds=65536
c[0]->fds[0]=13, rfds=65536
c[0]->fds[1]=8, rfds=65536
c[0]->fds[7]=12, rfds=65536
c[1]->fds[7]=16, rfds=65536
Succeed at c[1]->fds[7]=16

edited on: 05-26-04 03:10

edited on: 05-26-04 08:47
By: antonverburg (antonverburg) 2004-06-02 08:37:19

Iv'e added two patches, to fix all problems. The first one is for stable (1.0) CVS  release, the other for unstable.
By: antonverburg (antonverburg) 2004-06-02 08:52:18

Hm, something goes wrong. Do not use the last two patches.

-> <edit> Huh, sory for this panic, but one of my microphones was damaged. So this patch still works! I'm going to test it now at another system. If that works fine too, it should be added to CVS.

edited on: 06-02-04 07:59
By: antonverburg (antonverburg) 2004-06-15 07:53:45

I've tested the patches above. They worked for a part, but did not fix everything. Now I made a full rewrite from chan_alsa.c. I've posted a patch to this rewrite at a new bugnote. I used a new bugnote, because I fixed all bugs, and not only the fds-bugs. I posted the patch at 1849. The patch from bugnote 1849 should be applied both to the semi-stable and to the latest-cvs release. It has been tested, and seems to be stable and usefull. This bugnote should be closed.
By: Mark Spencer (markster) 2004-06-26 01:36:49

I've put in some major ALSA changes that seem to make it at least run well on my system.  If there are still issues, just open a new ALSA tracking bug.