> This is a very very very good idea! I have tested on my Windows2000
> system (with SoundBlaster 16 WDM driver), and both versions work.
Thanks for the information -- there's been a few testers reporting
back to me directly too, thanks to everyone for helping out! The
conclusions I can draw are
[1] Getting the command-lind linking pa_win_wmme can be tricky, but
once that is solved the wmme.c example seems to work. Looks like
cl wmme.c winmm.lib -o wmme.exe
is known to work for MSVC++, and I'm guessing:
gcc -O3 wmme.c -lm -lwinmm -o wmme.exe
will do the trick for gcc, if someone has gcc handy and can test
this out let me know ...
[2] Getting DirectSound is compile and link is very version-dependent;
it looks like the PortAudio folks are expecting a relatively recent
version of DirectSound to be available. So, some people get it to
work, but others find that compilation or linking errors pointing to
unknown identifiers that have the feel of features added later in
DirectSound development.
> I notice a very short delay before sound output starts, in both cases.
Sfront guessed that the application was "streaming" and not "real-time",
and used a default latency value of a few hundred milliseconds -- the
driver used this default value to choose big buffer sizes, to reduce the
chance of a dropout during playback. Note by the way you can override
this default latency value with the -latency flag, so you aren't trapped
by sfront's guess. So, hopefully this delay will reduce to the intrinsic
latency once we try real-time examples ...
> 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.
This looks like its on the drawing board for Portaudio:
Note under the table:
"We would like to add support for VST, ALSA, WDM, Solaris, and other
platforms. Please let us know if you wish to help with these projects."
As I have sfront set up now, the audio driver is just making PortAudio
calls, and doesn't know about the specific platform chosen -- sfront
itself inserts in the platform-specific portaudio code as it makes
the sa.c file. So, adding new platforms as the new PortAudio drivers
stablize should be easy.
However, note that sfront itself isn't quite compatible with some of
the architectures in the table of current PortAudio projects -- the
"Classic Mac" would run the callback routine in an interrupt driver,
and sfront probably makes ANSI C calls which aren't allowed in that
context.
Also, I'm still planning to write a native Mac OS X driver, so that I
can optimize buffer management for latency instead of going through
the PortAudio layer ...
> 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.
It's true that implementing a feature like this, showing a speedup
advantage, and then taking it to MPEG for consideration is a path for
adding new things to SAOL ...
Personally, though, I'm won't be able to allocate significant time to
helping with these sort of extensions, my focus these days is on the
networking stuff, and on sfront support to make networking experiments
practical (thus the renewed focus on making Windows and Macs work
better, so that we can get more people using sfront networking and
thereby run experiments and get data ...).
So, the effort to modify sfront would be going on without my direct
involvement, and would require:
-- Updating the parser to know about the new data type, and update the
rest of sfront to appropriately ignore fsigs, in many different ways.
-- Update all of the reference counting and optimization code for fsigs.
-- Update the data-structure generation system to generate space for fsigs,
in many different contexts -- instrs, instances, opcodes, etc.
-- Update the actual code-generation to do the right math on fsigs.
This is a lot of work. Here's an easier alternative route that might
get you most of what you want, and stay normative too:
-- Ditch fft() and ifft(), and write replacements which have the
desirable properties you mention, but
-- Do it using pure aopcodes(), without your new data type. Note that
you can track where you are in time using standard names, so there's
nothing stopping you from writing fully blocked code manually in SAOL
at the arate. You can use tricks like:
ksig k[1];
asig dummy;
ksig[0] = 0; // runs at k-rate
ksig[dummy] = 1; // runs at a-rate
to communicate backwards from a-rate to k-rate, so you don't really
need the specialop semantics to do what you want.
-- To get performance, modify sfront to do pattern-matching -- to
detect aopcodes you write (perhaps smaller aopcodes that perform
pairwise math on the elements of fsigs) and replace it with
custom-written C code optimized to go fast. This way, decoders that
know about your code goes fast, decoders that don't still execute
correctly but go slower.
--jl
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:11:09 EST