>Well I don't think alsa has ever said it could do that, or has ever said it >wanted to.
true. i'm not saying its ALSA's job. but its a job that something has to do. >If one wishes to sample sync audio from two different programs, there has to >be a method for comparing the two streams to see if they are in sync or not. not true. >I don't know how MacOS X does it, but I would assume that it somehow encodes >the presentation time stamp into the audio streams being sent between >applications. nope. it does it the same way that JACK does it (and Rewire, and every plugin system including VST/MAS/TDM/RTAS/LADSPA and others): you use a callback approach. every participant in the processing network provides a callback which is called with a number of frames to process. this ensures that its audio input and/or output is locked to every other participant. >One could probably add this feature to alsa quite easily, by adding a >"presentation time stamp" to the snd_pcm_write function call. The if two >applications were trying to output sound at the same time, alsa-lib could >compare presentation time stamps, and keep everything in sync. sorry, but thats not running in sample sync. thats "chasing sync". if one of them "drifts", the others follow. running in sample sync means that they never drift. its like the difference between word clock and a time sync signal like MTC or SMPTE. the former avoids any drift by having everyone use the same sample clock; the latter allows the different parties to catch up or slow down or jump around as required. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
