On Wed, Oct 8, 2008 at 2:41 AM, Jeremy A <[EMAIL PROTECTED]> wrote: > 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.
We've changed audio I/O model, but we've made it much more flexible ;) So, you can use read()/write() interface - look into Mp[io]dOss for an example. We've done a lot of tunning of this driver to achieve good latency whilst getting no drops and we've found blocking read()/write() the best solution here. Feel free to consult questions on design, etc. >>> 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. Yeah, you should avoid blocking calls in audio I/O thread, and disk I/O is the worst thing here. Why don't you want to use usual recording capabilities, built into sipXtapi? If you need specific file format - feel free to improve MprRecorder to support them. Though, if you really want to do a lot of recording - I'd recommend to offload this to separate thread. We can discuss the design of this fitting best to sipXmediaLib, if you're interested. PS To enable Topology graph under Linux pass --enable-topology-graph switch to sipXmediaAdapterLib interface. -- Regards, Alexander Chemeris. 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/
