me/portaudio
Watch
1
0
Fork
You've already forked portaudio
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

removed/cleaned up doxygen @todo items. moved to TRAC

Browse source
This commit is contained in:
rossb 2011-02-02 18:58:17 +00:00
commit b4931e7298
7 changed files with 22 additions and 131 deletions
Download patch file Download diff file Expand all files Collapse all files

20
src/common/pa_front.c
View file

@ -59,18 +59,6 @@
All PortAudio API functions can be conditionally compiled with logging code.
To compile with logging, define the PA_LOG_API_CALLS precompiler symbol.
@todo Consider adding host API specific error text in Pa_GetErrorText() for
paUnanticipatedHostError
@todo Consider adding a new error code for when (inputParameters == NULL)
&& (outputParameters == NULL)
@todo review whether Pa_CloseStream() should call the interface's
CloseStream function if aborting the stream returns an error code.
@todo Create new error codes if a NULL buffer pointer, or a
zero frame count is passed to Pa_ReadStream or Pa_WriteStream.
*/
@ -381,7 +369,7 @@ const char *Pa_GetErrorText( PaError errorCode )
{
case paNoError: result = "Success"; break;
case paNotInitialized: result = "PortAudio not initialized"; break;
/** @todo could catenate the last host error text to result in the case of paUnanticipatedHostError */
/** @todo could catenate the last host error text to result in the case of paUnanticipatedHostError. see: http://www.portaudio.com/trac/ticket/114 */
case paUnanticipatedHostError: result = "Unanticipated host error"; break;
case paInvalidChannelCount: result = "Invalid number of channels"; break;
case paInvalidSampleRate: result = "Invalid sample rate"; break;
@ -1343,7 +1331,7 @@ PaError Pa_CloseStream( PaStream* stream )
else if( result == 0 )
result = interface->Abort( stream );
if( result == paNoError ) /** @todo REVIEW: shouldn't we close anyway? */
if( result == paNoError ) /** @todo REVIEW: shouldn't we close anyway? see: http://www.portaudio.com/trac/ticket/115 */
result = interface->Close( stream );
}
@ -1601,7 +1589,7 @@ PaError Pa_ReadStream( PaStream* stream,
{
if( frames == 0 )
{
/* XXX: Should we not allow the implementation to signal any overflow condition? */
/* @todo Should we not allow the implementation to signal any overflow condition? see: http://www.portaudio.com/trac/ticket/116*/
result = paNoError;
}
else if( buffer == 0 )
@ -1641,7 +1629,7 @@ PaError Pa_WriteStream( PaStream* stream,
{
if( frames == 0 )
{
/* XXX: Should we not allow the implementation to signal any underflow condition? */
/* @todo Should we not allow the implementation to signal any underflow condition? see: http://www.portaudio.com/trac/ticket/116*/
result = paNoError;
}
else if( buffer == 0 )

37
src/common/pa_process.c
View file

@ -41,41 +41,6 @@
@ingroup common_src
@brief Buffer Processor implementation.
The code in this file is not optimised yet - although it's not clear that
it needs to be. there may appear to be redundancies
that could be factored into common functions, but the redundanceis are left
intentionally as each appearance may have different optimisation possibilities.
The optimisations which are planned involve only converting data in-place
where possible, rather than copying to the temp buffer(s).
Note that in the extreme case of being able to convert in-place, and there
being no conversion necessary there should be some code which short-circuits
the operation.
@todo Consider cache tilings for intereave<->deinterleave.
@todo specify and implement some kind of logical policy for handling the
underflow and overflow stream flags when the underflow/overflow overlaps
multiple user buffers/callbacks.
@todo provide support for priming the buffers with data from the callback.
The client interface is now implemented through PaUtil_SetNoInput()
which sets bp->hostInputChannels[0][0].data to zero. However this is
currently only implemented in NonAdaptingProcess(). It shouldn't be
needed for AdaptingInputOnlyProcess() (no priming should ever be
requested for AdaptingInputOnlyProcess()).
Not sure if additional work should be required to make it work with
AdaptingOutputOnlyProcess, but it definitely is required for
AdaptingProcess.
@todo implement PaUtil_SetNoOutput for AdaptingProcess
@todo don't allocate temp buffers for blocking streams unless they are
needed. At the moment they are needed, but perhaps for host APIs
where the implementation passes a buffer to the host they could be
used.
*/
@ -603,6 +568,8 @@ void PaUtil_SetNoOutput( PaUtilBufferProcessor* bp )
assert( bp->outputChannelCount > 0 );
bp->hostOutputChannels[0][0].data = 0;
/* note that only NonAdaptingProcess is able to deal with no output at this stage. not implemented for AdaptingProcess */
}

3
src/common/pa_util.h
View file

@ -46,9 +46,6 @@
Some functions declared here are defined in pa_front.c while others
are implemented separately for each platform.
@todo Document and adhere to the alignment guarantees provided by
PaUtil_AllocateMemory().
*/

28
src/hostapi/dsound/pa_win_ds.c
View file

@ -39,34 +39,6 @@
/** @file
@ingroup hostapi_src
@todo implement paInputOverflow callback status flag
@todo implement paNeverDropInput.
@todo implement host api specific extension to set i/o buffer sizes in frames
@todo implement initialisation of PaDeviceInfo default*Latency fields (currently set to 0.)
@todo implement ReadStream, WriteStream, GetStreamReadAvailable, GetStreamWriteAvailable
@todo audit handling of DirectSound result codes - in many cases we could convert a HRESULT into
a native portaudio error code. Standard DirectSound result codes are documented at msdn.
@todo implement IsFormatSupported
@todo call PaUtil_SetLastHostErrorInfo with a specific error string (currently just "DSound error").
@todo make sure all buffers have been played before stopping the stream
when the stream callback returns paComplete
@todo retrieve default devices using the DRVM_MAPPER_PREFERRED_GET functions used in the wmme api
these wave device ids can be aligned with the directsound devices either by retrieving
the system interface device name using DRV_QUERYDEVICEINTERFACE or by using the wave device
id retrieved in KsPropertySetEnumerateCallback.
old TODOs from phil, need to work out if these have been done:
O- fix "patest_stop.c"
*/

44
src/hostapi/wmme/pa_win_wmme.c
View file

@ -65,35 +65,6 @@
@ingroup hostapi_src
@brief Win32 host API implementation for the Windows MultiMedia Extensions (WMME) audio API.
@todo Fix buffer catch up code, can sometimes get stuck (perhaps fixed now,
needs to be reviewed and tested.)
@todo implement paInputUnderflow, paOutputOverflow streamCallback statusFlags, paNeverDropInput.
@todo BUG: PA_MME_SET_LAST_WAVEIN/OUT_ERROR is used in functions which may
be called asynchronously from the callback thread. this is bad.
@todo implement inputBufferAdcTime in callback thread
@todo review/fix error recovery and cleanup in marked functions
@todo implement timeInfo for stream priming
@todo handle the case where the callback returns paAbort or paComplete during stream priming.
@todo review input overflow and output underflow handling in ReadStream and WriteStream
Non-critical stuff for the future:
@todo Investigate supporting host buffer formats > 16 bits
@todo define UNICODE and _UNICODE in the project settings and see what breaks
@todo refactor conversion of MMSYSTEM errors into PA arrors into a single function.
@todo cleanup WAVEFORMATEXTENSIBLE retry in InitializeWaveHandles to not use a for loop
*/
/*
@ -102,7 +73,7 @@ Non-critical stuff for the future:
For both callback and blocking read/write streams we open the MME devices
in CALLBACK_EVENT mode. In this mode, MME signals an Event object whenever
it has finished with a buffer (either filled it for input, or played it
for output). Where necessary we block waiting for Event objects using
for output). Where necessary, we block waiting for Event objects using
WaitMultipleObjects().
When implementing a PA callback stream, we set up a high priority thread
@ -2839,7 +2810,7 @@ PA_THREAD_FUNC ProcessingThreadProc( void *pArg )
if( waitResult == WAIT_FAILED )
{
result = paUnanticipatedHostError;
/** @todo FIXME/REVIEW: can't return host error info from an asyncronous thread */
/** @todo FIXME/REVIEW: can't return host error info from an asyncronous thread. see http://www.portaudio.com/trac/ticket/143 */
done = 1;
}
else if( waitResult == WAIT_TIMEOUT )
@ -2892,7 +2863,7 @@ PA_THREAD_FUNC ProcessingThreadProc( void *pArg )
we discard all but the most recent. This is an
input buffer overflow. FIXME: these buffers should
be passed to the callback in a paNeverDropInput
stream.
stream. http://www.portaudio.com/trac/ticket/142
note that it is also possible for an input overflow
to happen while the callback is processing a buffer.
@ -3051,7 +3022,9 @@ PA_THREAD_FUNC ProcessingThreadProc( void *pArg )
{
stream->abortProcessing = 1;
done = 1;
/** @todo FIXME: should probably reset the output device immediately once the callback returns paAbort */
/** @todo FIXME: should probably reset the output device immediately once the callback returns paAbort
see: http://www.portaudio.com/trac/ticket/141
*/
result = paNoError;
}
else
@ -4004,8 +3977,3 @@ HWAVEOUT PaWinMME_GetStreamOutputHandle( PaStream* s, int handleIndex )
else
return 0;
}

3
src/os/win/pa_win_hostapis.c
View file

@ -40,9 +40,6 @@
@ingroup win_src
@brief Win32 host API initialization function table.
@todo Consider using PA_USE_WMME etc instead of PA_NO_WMME. This is what
the Unix version does, we should consider being consistent.
*/

18
src/os/win/pa_win_util.c
View file

@ -41,9 +41,6 @@
@ingroup win_src
@brief Win32 implementation of platform-specific PaUtil support functions.
@todo Implement workaround for QueryPerformanceCounter() skipping forward
bug. (see msdn kb Q274323).
*/
#include <windows.h>
@ -129,13 +126,18 @@ double PaUtil_GetTime( void )
if( usePerformanceCounter_ )
{
/* FIXME:
according to this knowledge-base article, QueryPerformanceCounter
can skip forward by seconds!
/*
Note: QueryPerformanceCounter has a known issue where it can skip forward
by a few seconds (!) due to a hardware bug on some PCI-ISA bridge hardware.
This is documented here:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q274323&
it may be better to use the rtdsc instruction using inline asm,
however then a method is needed to calculate a ticks/seconds ratio.
The work-arounds are not very paletable and involve querying GetTickCount
at every time step.
Using rdtsc is not a good option on multi-core systems.
For now we just use QueryPerformanceCounter(). It's good, most of the time.
*/
QueryPerformanceCounter( &time );
return time.QuadPart * secondsPerTick_;