Alexander Chemeris wrote: > > > I'd not recommend using them in long term. They are deprecated > and are not supported in new Topology flowgraph. We're planning > to remove old dmaTask as soon as we have a slice of free time. > > I'd recommend you to switch to Topology graph and implement > normal ALSA interface for it. Look into MpInputDeviceDriver and > MpOutputDeviceDriver base classes and Mpid*/Mpod* existing > classes as a good example. We'll be glad to include ALSA > support for new audio I/O to mainline. >
I think my existing ALSA classes should easily slot in with any new architecture you have - unless you are changing the audio I/O model from basic read/write fixed buffers - as existing - to callback operation. > >> as-heard sound recording using the excellent libsndfile which can write >> in most formats with on-the-fly format conversion/compression. >> > > Do you record right from the audio I/O functions? Yes. There is no discernible effect from doing it in the audio capture chain. My target hardware is Geode 500 Mhz and I first considered using a separate logging thread, but the load is so light there was no need. My tests included using libsndfile live transcoding to GSM format for storage size reasons - now discarded in favour of a sound log archiver doing higher compression. The only reason I get audio loss is other processes taking too much CPU. >From previous experience it's a good idea to run audio threads at near top real-time priority. Tweaking the ALSA buffer size manages audio loss but if they get too big then latency can becomes a problem. _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
