Show
Ignore:
Timestamp:
08/08/02 12:10:34 (6 years ago)
Author:
rossbencina
Message:

- added concrete code to proposal
- added discussion regarding dropping Pa_StreamTime
- added discussion of global timebase vs. per-stream timebase

Files:
1 modified

Legend:

Unmodified
Added
Removed
  • pa_proposals/trunk/015-ImproveCallbackTimestampInfo.html

    r4 r17  
    1818<P><A href="index.html">Enhancement Proposals Index</A>, 
    1919<A href="http://www.portaudio.com/">PortAudio Home Page</A></P> 
    20 <P>Updated: July 23, 2002 </P> 
     20<P>Updated: August 9, 2002 </P> 
    2121 
    2222<H4>Status</H4> 
    2323 
    24 <P>This proposal is under construction.</P> 
     24<P>This proposal is under discussion.</P> 
    2525 
    2626<H4>Background</H4> 
     
    2828<P> 
    2929The information provided by the outTime callback parameter and Pa_StreamTime() function does 
    30 not provide sufficient information to perform some syncronisation tasks such as syncronising 
    31 PortAudio generated audio with another timebase (such as syncronisation pulses in a timestamped 
    32 MIDI event stream.) 
     30not provide sufficient information to perform some syncronisation tasks. One example is that of syncronising 
     31PortAudio generated audio with another timebase, such as syncronisation pulses in a timestamped 
     32MIDI event stream. 
    3333</P> 
    3434 
     
    3636 
    3737<P> 
    38 Remove Pa_StreamTime(). Provide a common time base ( Pa_GetTime() ) and pass three time parameters to the callback: current time, time at which the first sample of the input buffer was recieved, time at which the first sample of the output buffer will play, all relative to the Pa_GetTime() timebase. 
     38Remove the Pa_StreamTime(), as its functionality can be implemented using the features added by the  
     39remainder of this proposal. 
    3940</P> 
    4041 
     42<P> 
     43Add a function to retrieve a stream's time base expressed in seconds.  
     44It is unspecified what this timebase is relative to. 
     45</P> 
     46 
     47<PRE> 
     48typedef double PaTime; 
     49 
     50PaTime Pa_GetStreamTimeBase( PaStream *stream ); 
     51</PRE> 
     52 
     53<P> 
     54Remove the current outTime parameter from the audio callback, and  
     55replace it with a pointer to a PaCallbackTimeInfo structure which contains 
     56the time at which the first sample of the input buffer was received at the ADC input (inputBufferADCTime), 
     57the time at which the first sample of the output buffer will exit the DAC (outputBufferDACTime),  
     58and the time at which the callback was initiated (currentTime). These times are all expressed 
     59in seconds relative to the stream's time base returned by Pa_GetStreamTimeBase(). 
     60</P> 
     61 
     62<PRE> 
     63typedef struct PaCallbackTimeInfo{ 
     64    PaTime inputBufferADCTime; 
     65    PaTime currentTime; 
     66    PaTime outputBufferDACTime, 
     67} PaCallbackTimeInfo; 
     68 
     69typedef int PortAudioCallback( 
     70      void *inputBuffer, void *outputBuffer, 
     71      unsigned long framesPerBuffer, PaCallbackTimeInfo *timeInfo, 
     72      unsigned long flags, void *userData); 
     73</PRE> 
     74 
     75<H4>Discussion</H4> 
     76 
     77<P> 
     78The possibility of retaining Pa_StreamTime() for clients which simply need to display the current stream time was discussed. It was suggested that the functionality currently provided by Pa_StreamTime() could be implemented using the new timestamp parameters, and that doing so would be more robust. One reason is because it is difficult to define a single useful behavior of Pa_StreamTime() in the presence of buffer overruns and underruns. 
     79</P> 
     80 
     81<P> 
     82Originally it was planned to have a global PortAudio timebase returned by a function named Pa_GetTime(). However, different host APIs on the same platform may dictate that their timebases are relative to different time sources (timeGetTime() vs. QueryPerformanceCounter() on windows for example.) Trying to syncronise multiple independent time bases is a problematic task (due to potential clock drift), so it was concluded that a safer approach would be to provide separate time bases for each stream. 
     83</P> 
    4184 
    4285<H4>Impact Analysis</H4>