help on realitime sound IO

Michel Jullian mj at exbang.com
Mon Oct 25 12:49:44 EDT 1999


Richard Hoffmann wrote:

> > Seer's Reality seems to do quite a good job on Windows with DirectSound
> > drivers : sound output (they have no sound input) has very short latency
> (a
> > few ms) and no dropouts even on a stressed system.
> >
> > Unlike e.g. Generator or Reaktor who, on the same system with the same
> > DirectSound driver, get their sound output perturbated not only if you
> > simultaneously run a defragmentor, but also if your mouse pointer simply
> > wanders over the resize, restore or close boxes of the app's window. And
> these
> > perturbations can only be cured by increasing the app's adjustable output
> > latency beyond the unacceptable for RT work (>120 ms).
> >
> > Anyone has any idea what Reality is doing right or what others are doing
> wrong ?
> 
> now Generator etc...they've got countless bugs in their program anyways, but
> not
> all audio apps under Windows do. There's a lot of programs that work
> properly with
> lower latencies.

Names, pointers would be welcome.

> Also there's different ways to realize an audio stream under
> Windows/DirectSound.
> NI possibly picked the worst

Well, I have personally tried two methods with DirectSound :

1) DS position notification events (awfully unreliable, notif events can be
hundreds of ms late)
2) in a thread periodically woken up by a multimedia timer (say every 5 or
10ms), get "playing head" position in DS buffer, compute and write accordingly
: much better than notifications, around 10 ms latency on an unperturbated
system, but still prone to the perturbations mentioned above, even when
working on the primary buffer (10ms better than secondary though).

Concerning Reality, there are some hints on Seer's site (thanks Stefan) but as
far as I can see these are mainly related to how they get a reliable timer by
working at the kernel level (working at the kernel level is not an option for
many apps including our sequencer BTW as it wouldn't allow hosting VST plugins
among other things). However, those dropout problems NI, ourselves and others
have experienced (when wandering over close etc buttons, when defragging or
recording audio to disk) do seem to occur even when the MM timer itself is not perturbated.

So I have the feeling there is more than reliable timing that needs to be done
for low-latency no-dropout with DX (as opposed to ASIO, for which not that
many drivers have been written), unfortunately Microsoft's DX SDK
documentation doesn't say what AFAIK.

If Richard or others who might have solved the above problems care to share
their own experiences with the list, I for one will certainly appreciate. If
others have unsuccessfully tried other methods, it may help the community too.
Phil, how is your portaudio/DX project going ?

-- 
Greetings,
Michel
.........................................................................
  Michel Jullian   Directeur General             email mj at exbang.com
  Exbang Industries S.A.
  Mas Chauvain   route de Villeneuve             tel +33(0) 499 529 878
  Maurin     34970 Lattes     France             fax +33(0) 499 529 879
.........................................................................

dupswapdrop -- the music-dsp mailing list and website: subscription info,
FAQ, source code archive, list archive, book reviews, dsp links
http://shoko.calarts.edu/musicdsp/




More information about the music-dsp mailing list