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.net/de/go/smartsurfer
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
