[Stk] Bug in RtAudio or base class?

[John Heenan]

Hi Gary

First thanks for your reply.

I have sent on a 100K sound sample to you to avoid raising list bandwidth
unnecessarily

The sound sample, recorded by Windows Sound Recorder is courtesy of my wife
and states "John Heenan is mine alone, all mine". This plays back fine in
Windows Media Player, with minor static probably due to a dodgy microphone
connection.

Using STK project example, play.exe on the file, the following error message
results
WvIn: Error reading WAV file (issy.wav).

With the driver upgrade the effects project now does not work at all.

The demo directory samples works fine, as does ragmatic.

Suppose the problem is that my soundcard card lacks 'efficiency's or
'throughput' then there will be many others in the same position as myself.
The soundcard driver reports itself to the system as 'Creative Sound Blaster
AudioPCI (WDM)'. The soundcard (Vibra 128) is cheap and I guess has to
compete for its share of CPU slices to do its work, rather than conducting
on board processing. However it is like a cheap mass produced car that is
fine for everyday use provided nothing special is expected of it.

I have successfully written programs that use this card and engage in heavy
duty processing of the WaveIn data. The way I do this is to split the heavy
duty process into two threads, keeping one thread waiting for data events,
storing data in a rotating buffer and posting a message to the heavy duty
processing thread of the address of new data in the rotating buffer, which
the heavy duty thread can process in its own time. The heavy duty thread can
make up its own mind about what to do if it cannot move fast enough.

In essence I move the problem of the soundcard 'not keeping up' to making
sure the soundcard 'can keep up' with the program  monitoring if it is
'keeping up' and deciding what to do if it is not keeping up. Decisions can
include skipping data and interpolating. However the problem with data loss
for me is dramatically reduced by using threads.

Hence I don't see a driver throughput problem as a problem that will cause a
failure in programming in that the problem can be managed, have resources
applied to solve it and can be reported to the user. An application can also
gracefully refuse to run on the basis it has determined there are
insufficient resources.

I guess we differ on whether poor throughput can be classified as a driver
fault or not. This is largely a matter of semantics and is irrelevant to the
problems at hand!  Throughput may not even be the cause of the problems.

John


----- Original Message -----
From: "Gary Scavone" <gary@ccrma.Stanford.EDU>
To: "John Heenan" <john@auscyber.com>
Cc: <stk@ccrma.Stanford.EDU>
Sent: Friday, November 15, 2002 3:59 AM
Subject: Re: [Stk] Bug in RtAudio or base class?


> Hi John,
>
> >>DirectX 8.1 has been installed and more up to date soundcard drivers
have
> >>been installed. This had no change.
> >>
> >>The soundcard is a Vibra 128.
> >>
> >>play.exe will not playback files recorded in, or converted to, various
wav
> >>formats using Windows Sound Recorder.
>
> What was the error message?  Perhaps you could send me a short example
> audio WAV file that doesn't work?  The WvIn class is intended to
> support all sorts of WAV files, though there is no apparent agreement
> on the normalization of 32-bit integer formats.
>
> >>play.exe will play files recorded by STK record with similar quality as
> >>Windows Sound Recorder.
> >>
> >>Using the various samples of the STK with the Tcl GUI there is static.
This
> >>is made dramatically worse by mouse movement anywhere in the screen.
>
> This is likely a buffer size issue.  The default buffer size is set in
> Stk.h to 512 sample frames (RT_BUFFER_SIZE).  If you are getting
> static (especially with mouse movement), then you need to make that
> bigger and recompile.  You should use power of two values, so try
> 2048, 4096 or higher.  The RtWvOut class also has an "nBuffers"
> parameter similar to RtWvIn.  The default value is 4, but you might
> consider messing with that as well (if changing RT_BUFFER_SIZE doesn't
> totally fix the problem).
>
> >>If there was a problem with soundcards drivers and/or the
> >>DirectSound API I would expect complete failure (not so).
>
> Not really.  A driver could sort of work, but have efficiency and
> throughput problems that prevent it from keeping up under all
> circumstances.  I wasn't necessary expecting the update of DirectX to
> make a difference, but the driver update definitely could.  Don't be
> afraid to set really high buffer sizes and "nBuffer" parameters ...
> the Windows Sound Recorder probably uses a buffer on the order of a
> second ... that's what the DirectX examples do.  That is fine for
> making sure your recorder app works under a wide range of soundcards
> and systems, but it's pretty useless when you're trying to do duplex
> with effects processing.
>
> >>Given you have kept to the DirectSoundCapture API it is puzzling why
some
> >>Windows PCs are fine and mine is not, given this API is supposed to
provide
> >>independence from the Windows platforms.
>
> The common API allows the programs to compile on a variety of systems.
> But the driver is what really controls how well the soundcard works
> within the API.
>
> --gary
>
>
> >>----- Original Message -----
> >>From: "Gary Scavone" <gary@ccrma.Stanford.EDU>
> >>To: "John Heenan" <john@auscyber.com>
> >>Cc: <stk@ccrma.Stanford.EDU>
> >>Sent: Thursday, November 14, 2002 3:53 AM
> >>Subject: Re: [Stk] Bug in RtAudio or base class?
> >>
> >>
> >>Hi John,
> >>
> >>I'm assuming the "play" example works ok?  The playback and record
> >>buffering schemes are exactly the same.  I don't use a multimedia
> >>timer (which is common) because RtAudio implements a blocking
> >>read/write call (and builds callback functionality on top of that).
> >>That said, RtAudio has been working for many Windows users with good,
> >>glitch-free response (Perry reports that he's sometimes left things
> >>running for hours without a problem).
> >>
> >>I'd guess that this is an issue of either 1.) your soundcard driver;
> >>and/or 2.) Your installed version of the DirectSound library.
> >>DirectSound is up to version 8.x or higher.  The DirectSoundCapture
> >>API is what is being used.  Can you check whether your soundcard
> >>manufacturer has an updated driver (I now remember that my Maestro2e
> >>driver initially did not work at all for capture but then did after I
> >>downloaded and installed an update)?
> >>
> >>--gary
> >>
> >>On Thu, 14 Nov 2002, John Heenan wrote:
> >>
> >>>>Processor speed is around 800Mhz.
> >>>>
> >>>>No other recording software I have used has these problem. For example
> >>>>Windows Sound Recorder works fine.
> >>>>
> >>>>It sounds as if the implementation of buffering algorithms have got
their
> >>>>knickers in a twist, such as overlapping data.
> >>>>
> >>>>John
> >>>>
> >>>>----- Original Message -----
> >>>>From: "Perry R Cook" <prc@CS.Princeton.EDU>
> >>>>To: "John Heenan" <john@auscyber.com>
> >>>>Cc: <stk@ccrma.Stanford.EDU>
> >>>>Sent: Thursday, November 14, 2002 2:59 AM
> >>>>Subject: Re: [Stk] Bug in RtAudio or base class?
> >>>>
> >>>>
> >>>>John,
> >>>>
> >>>>What speed is your processor?
> >>>>
> >>>>PRC
> >>>>