This is a very very very good idea! I have tested on my Windows2000
system (with SoundBlaster 16 WDM driver), and both versions work. I
notice a very short delay before sound output starts, in both cases.
This may be simply down to the time it takes to load the system dlls; it
could be a good idea to support a flag to hold playback until a key is
pressed; so that when you do that, audio starts instantly.
(In fact, in my own play application I do the opposite - by default I
wait for a keypress, but I can give a flag to the program to bypass that
and start as soon as possible.)
Of course, we need a full-duplex example to test, for completeness; this
will also enable fine-tuning for minimum latency. Until I get my new pro
soundcard for Windows2000 (pobably a M-Audio 'Audiophile'), I can still
test for full-duplex under Win95 using the Pulsar.
One thing I could explore, in due course, is adding direct WDM driver
support by using WAVE_FORMAT_EXTENSIBLE rather than plain WAVEFORMATEX.
This would enable orthogonal support for multi-channel output,
regardless of the capacity of the soundcard.
On a separate but not entirely unrelated note: I recently added some
streaming pvoc opcodes to Csound (in v4.14 now) - i.e. doing on the fly
analysis and resynthesis. This uses a new custom signal type (an
"fsig"), which Csound makes it very easy to define. I would like to do
the same in SAOL, as a non-standard extension. This is to:
*- bypass the current fft and ifft opcodes, which are inconvenient for
pvoc work;
*- support non power-of-2 fft sizes (sometimes useful)
*- support analysis windows arbitrarily larger than the fft size (with
sinc window filtering - much better for oscbank resynthesis)
*- speed. The expensive conversion to amplitude and phase can be handled
inside the opcode; it would even be possible to use the FFTW libraries,
for a substantial speed increase. I can process a stereo stream in
real-time on my PII 333MHz machine (four-fold overlap). Real-time PVOC
processing in SAOL would be a very real possibility.
*- convenience: fsigs can be used in expressions (given suitable opcodes
and operator overloading), and they avoid the use of global tables
(though I support them in the Csound opcodes anyway).
So the question is: how easy would it be to define a new block-oriented
signal type for SAOL, and implement it in sfront? The key thing would be
to support fsigs as input and outputs for user-defined opcodes.
Richard Dobson
John Lazzaro wrote:
>
> Hi everyone,
>
> Been working on overhauling the sfront audio driver API, so that
> it can handle callback-style soundcard API's in a graceful way, see:
>
...
> http://www.cs.berkeley.edu/~lazzaro/files/wintest/simple.zip
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:11:08 EST