mBlendFrameCount only retrieved from prefs ... not using dialog Only way to change (for windows) is thru registry The values should be figured dynamically ... too many frames could be invalid
revisit this hack which makes adding new colours easier but which prevents a colour of (1,1,1) from being added. find an alternative way to make adding new colours easier. e.g. initialise the background to translucent, perhaps.
Consider whether functions which dither but don't clip should exist, V18 automatically enabled clipping whenever dithering was selected. Perhaps we should do the same.
Dynamically calculate the coefficients used to smooth the CPU Load Measurements over time to provide a uniform characterisation of CPU Load independent of rate at which PaUtil_BeginCpuLoadMeasurement / PaUtil_EndCpuLoadMeasurement are called.
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.
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.
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.
(non-critical optimisation) The conditional below implements the continue/complete/abort mechanism simply by continuing on iterating through the input buffer, but not passing the data to the callback. With care, the outer loop could be terminated earlier, thus some unneeded conversion cycles would be saved.
REVIEW: consider what to do if the input overflows. do we requeue all of the buffers? should we be running a thread to make sure they are always queued?
REVIEW: consider what to do if the output underflows. do we requeue all the existing buffers with zeros? should we run a separate thread to keep the buffers enqueued at all times?
The paInputOverflow flag should be set in the callback containing the first input sample following the overflow. That means the block currently sitting at the fore-front of recording, i.e. typically the one containing the newest (last) sample in the HPI buffer system. This is most likely not the same as the current block of data being passed to the callback. The current overflow should ideally be noted in an overflow list of sorts, with an indication of when it should be reported. The trouble starts if there are several separate overflow incidents, given a big input buffer. Oh well, something to try out later...
work out how to implement stream stoppage from callback and implement IsStreamActive properly. Stream stoppage could be implemented using a high-priority thread blocked on an Event which is signalled by the callback. Or, we could just call ASIO stop from the callback and see what happens.
Different channels of a multichannel stream can have different sample formats, but we assume that all are the same as the first channel for now. Fixing this will require the block processor to maintain per-channel conversion functions - could get nasty.
provide an asio-specific method for setting the systems specific value (aka main window handle) - check that this matches the value passed to PaAsio_ShowControlPanel, or remove it entirely from PaAsio_ShowControlPanel. - this would allow PaAsio_ShowControlPanel to be called for the currently open stream (at present all streams must be closed).
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.
REVIEW: the error checking in this function needs review. the basic idea is to return from this function in a known state - for example there is no point avoiding calling waveInReset just because the thread times out.
if all of the other buffers are also ready then 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.
REVIEW: the error checking in this function needs review. the basic idea is to return from this function in a known state - for example there is no point avoiding calling waveInReset just because the thread times out.