On Dec 21, 2007 6:55 PM, Jeremy A <[EMAIL PROTECTED]> wrote:
> Alexander Chemeris wrote:
> >
> >> Finally I have a problem with remote DTMF events seeming to kill local
> >> audio output. I've not quite characterised it yet but is it a known
> problem?
> >>
> >
> > I do not completely understand what do you mean "kill local audio
> output".
> > What are you refering to as "local audio output"? If you mean problem,
> > similar to one with playing file - similar approach of fixing it could
> be used
> In my case the audio is dropped indefinitely. I tried several cases with
> different types of DTMF notification - inband, via RTP, via SIP notify.
> It appears that inband doesn't affect audio - I presume because the TAPI
> doesn't do in-band DTMF detection?.
That is correct -- no in-band DTMF detection. Both with the release you are
using, and with the latest svn version.
I haven't characterized it fully yet but a single DTMF tone causes a
> drop. Repeated DTMF tones eventually cause audio to restart.
>
> Perhaps I should move to the svn version first and see if I can
> replicate the problem?
Yes, you'll get better response from us if you use the latest svn code -- as
I am not very familiar with the old code myself, and it has been a long
time. -- Plus, any potential fixes that may need to be made will be made to
the svn version :)
> Finally, I have a minor (and ugly) fix to allow selection of Linux audio
> device at initialisation by using an environment variable. In good
> software engineering practice the library should not look at environment
> variables - but at least it works till a better solution comes around.
No doubt, with latest svn code, using the new 'Topology graph' (you have to
explicitly turn it's use on in the build via 2 compiler defines that can be
passed via CFLAGS, CXXFLAGS) -- a replacement to the 'call flowgraph', this
hack of yours may not work -- we have entirely re-written the audio drivers
-- there are now separate classes for each driver (windows WinMM, linux OSS)
-- but you can try it out! My guess - your patch probably will work ok for
default svn code, but not when using topology graph.
The Topology graph is a more flexible flowgraph type -- it allows one to
more easily incorporate any sorts of resources into the graph -- in fact, it
only knows resources as generic resources -- thus it is easy to create a new
resource, and add it to the flowgraph.
diff dmaTaskPosix.cpp dmaTaskPosix.cpp.orig
> 538d537
> < #include <stdlib.h>
> 542,544d540
> < char * audiodevice = getenv("SND_DEVICE_SIPX");
> < if (!audiodevice) audiodevice = "/dev/dsp";
> <
> 551c547
> < fd = open(audiodevice, O_RDWR);
> ---
> > fd = open("/dev/dsp", O_RDWR);
> 554c550
> < osPrintf("OSS: could not open %s; *** NO SOUND!
> ***\n",audiodevice);
> ---
> > osPrintf("OSS: could not open /dev/dsp; *** NO SOUND! ***\n");
> 596c592
> < osPrintf("OSS: %s opened OK, %dHz %d-bit %s\n", audiodevice, speed,
> samplesize, (stereo==1) ? "stereo" : "mono");
> ---
> > osPrintf("OSS: /dev/dsp opened OK, %dHz %d-bit %s\n", speed,
> samplesize, (stereo==1) ? "stereo" : "mono");
>
--
Keith Kyzivat
SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
