Re: Convert DirectX secondary buffer contents to floating point

• Previous message: Chris P. [MVP]: "Re: SecondaryBuffer using BufferDescription and Value not in Range err"
• In reply to: Andrew Mayo: "Re: Convert DirectX secondary buffer contents to floating point"
• Messages sorted by: [ date ] [ thread ]

Date: Fri, 16 Jul 2004 16:11:54 -0400

Andrew Mayo wrote:
> Thanks, that's very helpful, because I won't waste time looking for a
> simple 'one line' solution.
>
> I'm working in C/C++ but only for as little code as is required. I
> intend to farm off the UI and state management to an in-process server
> written in VB and communicate via COM with that.
>
> This is much easier than designing UI in C++ - a painful experience,
> IMHO, and also opens up customisation to a much larger audience -
> remember, this is planned to be open source.
>
> It also means that only time-critical sections are written in C++ - a
> language that without considerable care and attention to detail just
> lends itself to subtle programming errors causing memory leaks and
> other bad stuff, whereas VB eliminates all that crap.
>
> (I cannot see the point of using .NET here because intercommunication
> between C++ and .NET is complex and also less efficient, time and
> resource wise. It also requires potential users to download some 20M
> of .NET runtime, so I will stick with dear ole VB6, thanks just the
> same!)

Right. Which is fine if your distributing your app on CD, but in the case
where you're expecting most users to download the software it's a large
burden for dialup users. Although if they have XP or some other software
that uses it there's a good chance it might already been installed.

> In any case, Microsoft seem to be a bit schizophrenic about managed
> code and DirectX. In one article in the SDK they say 'we managed 98%
> of the efficiency of C++.. blah blah' and in another they say
> 'DirectShow is unlikely to be supported in the managed code
> environment because of performance issues'.

Never really quite understood that one either.

> Streaming is the way to go, I agree, but the requirements for soft
> samplers are stringent. Latency of 5ms or less is required and this
> means samples have to be pre-buffered (and proper sound cards or
> external USB devices are also needed, eg the Edirol UA20. Obviously
> internal sound card support is required but latency is then much
> higher; however, the system has to accommodate proper low-latency
> cards as well). Polyphony of up to 40 simultaneous notes is also not
> uncommon, requiring considerable care in disk I/O management, because
> the environment in which the sampler runs may also be using the disk
> for audio recording and playback simultaneously. Since the software
> must also run on a laptop, disk I/O throughput is compromised by the
> lower rotational speed of the drive, as well. So I will start with
> RAM-based playback and then see how I go.

You would have to double buffer your streaming. Basically you use a
circular read-ahead buffer which pre-fetches the data from the file. Your
buffer fill thread or "Process" event handler would then just be grabbing
data from memory. If your samples are mostly small, less than 10 seconds,
you might as well just load the whole sample in memory and be done with it.
Disk latency is a killer for realtime audio, as is GUI. Because all your
GUI is going to be in VB, this should be a good thing as it will force
abstraction of the audio and display layers.

The DSound samples show how to both load and play a file, as well as stream
a file. Just watch out for a couple of mistakes that are in the samples
such as using WaitForMultipleObjectsMsg() and checking the state of an
interface CheckBox in the audio thread.

• Previous message: Chris P. [MVP]: "Re: SecondaryBuffer using BufferDescription and Value not in Range err"
• In reply to: Andrew Mayo: "Re: Convert DirectX secondary buffer contents to floating point"
• Messages sorted by: [ date ] [ thread ]