Re: sipXtapi hardware requirements

Hi Keith,

Thank you for your quick and helpful answer,
regarding to the spezialized input and output audio drivers,
do you have some more information? What kind of changes are
necessary to get an efficient driver?
Is it a an appreciable effort? At the moment I`m using the
OSS emulation
of the Linux alsa driver.
Thank you for your help!

Regards
Karsten


-------- Original-Nachricht --------
> Datum: Tue, 15 Apr 2008 15:01:49 -0400
> Von: "Keith Kyzivat" <kkyzivattripleplayint.com>
> An: "Karsten Schubotz" <Karstenvipgmx.de>
> CC: sipxtapi-devlist.sipfoundry.org
> Betreff: Re: [sipxtapi-dev] sipXtapi hardware
requirements

> We have successfully got sipXtapi working on ~200MHz
ARM hardware, but 
> it required rewriting specialized input and output
audio drivers, due to
> inefficient driver design.  This may be what is causing
the fragmented
> sound
> you hear -- that the audio driver is not delivering
data fast enough to
> sipXtapi.

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gm
x.net/de/go/multimessenger
_______________________________________________
sipxtapi-dev mailing list
sipxtapi-devlist.sipfoundry.org
List Archive: http
://list.sipfoundry.org/archive/sipxtapi-dev/

Hi Karsten,

As Keith already said, we were able to get sipXtapi working
on
ARM926EJ-S  100MHz (or 133MHz, do not recall exactly, but
<< 200MHz!)
with G.711 in three-way conference mode with some CPU power
still
available. We also were able to get 1-to-1 call with Speex
NB 8kbps *almost*
working on that CPU freq, only a few MIPS missing for it to
work perfectly.

First thing you need to do is to enable Topology graph
instead
of old PhoneMediaInterface by defining following
preprocessor defines:
  ENABLE_TOPOLOGY_FLOWGRAPH_INTERFACE_FACTORY
  DISABLE_DEFAULT_PHONE_MEDIA_INTERFACE_FACTORY
Among other things this will enable use of our new audio I/O
interface.
OSS version of this interface should work fairly well in
embedded
environment. Though, as Keith said, we still had to write
our own
audio I/O kernel driver and sipX interface driver to get
stable
audio quality. Biggest problem with ALSA drivers (and, so,
OSS drivers
as well, because we used oss emulation) on our dev.board
was that they were not able to wake up thread, waiting for
audio
I/O operation completition on time, delaying it by various
amounts
of time. We're synchronizing our audio processing to this
I/O
completion events, so this is very improtant to get them
working
and waking up our processing thread ASAP after I/O operation
is done.
I guess this is your most issue wich you should solve.

Other our issue, which is probably not that important for
you,
was general mutex performance on ARM. We need to replace
mutex operations in some essential places to lock-free
operations
to speed-up our code and meet real-time requirement.
Though,
you have 4x CPU power, so this might not be that big issue
for you. I plan to commit my lock-free work to svn someday,
but
I'm not sure they're ready for wide usage nowdays. But, if
you
want to give them a try, I'll post them here.

-- 
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
_______________________________________________
sipxtapi-dev mailing list
sipxtapi-devlist.sipfoundry.org
List Archive: http
://list.sipfoundry.org/archive/sipxtapi-dev/

Hi Alexander, Hi Keith,

Thank you for your comprehensive answers!

> First thing you need to do is to enable Topology graph
instead
> of old PhoneMediaInterface by defining following
preprocessor defines:
>  ENABLE_TOPOLOGY_FLOWGRAPH_INTERFACE_FACTORY
>  DISABLE_DEFAULT_PHONE_MEDIA_INTERFACE_FACTORY

I set this configuration in the CC- and CXX Flags for
compiling the sipXmediaAdapterLib. After compiling the whole
sipXtapi, I run the sipXmediaAdapterLib testsuite and there
I could see that the Topology flowgraph interface was
enabled.
So I think this configuration is OK.

I should note, that by running the sipXmediaLib testsuite,
especially the 
test “MprBridgeTest::TestSimpleMixPerformance” It lasts
about 1 min to 
process 10000 bridge Frames. The same test on a standard
Linux PC (dual 
core) lasts only a half second.
Perhaps, this has something to do with the mutex performance
on ARM.

> Other our issue, which is probably not that important
for you,
> was general mutex performance on ARM. We need to
replace
> mutex operations in some essential places to lock-free
operations
> to speed-up our code and meet real-time requirement.
Though,
> you have 4x CPU power, so this might not be that big
issue
> for you. I plan to commit my lock-free work to svn
someday, but
> I'm not sure they're ready for wide usage nowdays. But,
if you
> want to give them a try, I'll post them here.

I would like to rule out the opportunity that the mutex
operation could 
influence the performance.
For me it would be a great help if you could post the
lock-free work to 
svn! Probably, the basic cause of my audio problem can be
found in the 
kernel driver, as you both described in your mails.

> As Keith already said, we were able to get sipXtapi
working on
> ARM926EJ-S  100MHz (or 133MHz, do not recall exactly,
but << 200MHz!)
> with G.711 in three-way conference mode with some CPU
power still
> available.

I`m also using the same ARM926EJ-S Core!

> Though, as Keith said, we still had to write our own
> audio I/O kernel driver and sipX interface driver to
get stable
> audio quality.

This seams not to be an easy job to make some changes in the
audio drivers 
of the Linux kernel. I’m using the 2.6.19.2 Kernel. I will
take a look at 
my audio I/O Kernel driver and will search for the
responsible operations 
you mentioned. Is there a chance to get a view in your
changes you made in 
your audio driver? I’m not sure if they match for my
kernel, but I think 
they could be a really good guideline for the work I have to
do.


> sipXtapi in it's current form uses a 30ms audio driver
buffer on windows,
> and I believe it is the same on Linux, or perhaps 20ms
(I'm not 
> currently looking at the source) using the new sipXtapi
driver wrapper 
> framework which is provided when you use the new
flowgraph (see earlier 
> entries in the mailing list for how to enable this).

I took a lock at the sources and I think it`s 10 ms. I found
a formula in 
MpInput/OutputDeviceDriver.h

getFramePeriod(samplesPerFrame,samplesPerSec)               
      
		return (1000*samplesPerFrame)/samplesPerSec   

( My debug results were:
     samplesPerSec = 8000
     samples per frame = 80
     return value = 1000 * 80 / 8000 = 10[ms] )

I´m not sure if this formula represents the audio driver
buffer.

> You may also want to test using simple OSS play and
record applications, 
> as sipXtapi uses OSS in it's current incarnation. This
will then test
> the impact that the OSS emulation layer has on the
sound processing.

I’ve made a simple test program, which writes and reads
160 Byte packages 
to dev/dsp alternately. I’ve connected a frequency
generator to line In. 
The result was that the sound which came out of line out was
clear. By
changing the frequency, it lasts more than half a second,
before I could 
hear it on Line out. It seams that the audio buffer is quiet
large. It 
collects about 4000 byte (8000 samples/sec means 4000
samples/half a 
second) before it pushes them to line out. 

So far, thank you for your really good assistance!

Regards
Karsten

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu
sparen! 
Ideal fĂĽr Modem und ISDN: http://www.gmx.n
et/de/go/smartsurfer
_______________________________________________
sipxtapi-dev mailing list
sipxtapi-devlist.sipfoundry.org
List Archive: http
://list.sipfoundry.org/archive/sipxtapi-dev/