A priority problem!

[caoxiang]

Hi,
I'm developing my host with VC6 now.But I have a problem with my host.

When I drag the scroll bar of my host or move the window of my host very quickly and continuously, the CPU Load reached nearly 100%,that's for sure for the cost of redraw.However, with the high CPU usage the sound was going to distort from then.

I tested this situation on several famous hosts or audio applications like reason, live ,SAVIhost and so on. To my surprise, they all don't have this problem although the CPU usage is high too at that time.

Do they use some mechanisms to prevent this situation or there is something wrong with my code.

Thanks.

By the way, does the CPU Limit option do this? Can I boost the priority of the ASIO Driver?

[Borogove]

Presumably, hosts without this problem have one thread at normal priority managing UI, and another thread at high priority managing audio.

[caoxiang]

But the ASIO Callback should works on it's own thread

[texture]

But the ASIO Callback should works on it's own thread

Yes, but you might delegate to another thread - particularly if the callback is actually running off an interupt.

[caoxiang]

But the ASIO Callback should works on it's own thread

Yes, but you might delegate to another thread - particularly if the callback is actually running off an interupt.

could you make it more specific?

[texture]

Do you take any notice of the 'processNow' flag?

It is possible to run another high priority / time critical thread that runs the audio process of your application. the ASIO callback would copy old data from the thread, supply a new block of data, and return immediately.

This obviously is not as trivial as it sounds! You must make sure that whilst you are doing the process, you don't acuire a mutex that the callback attempts to acquire. The thread should operate on iots own data, and transfer it to a buffer (actually, just swap some pointers) that is accessed by both threads, so that the time spent in the mutex is as short as possible.
You also increase the latency. Many drivers actually run in a thread anyway, rather than off an interrupt, so it is probably not worth the effort.

I a not sure if it is possible to get a re-entrant asio callback (get a callback whilst you are still doing the last one).

[texture]

By the way, I have found a nice trick if you need to transfer items to a time critical thread with very short critical sections. Use a std::list, and the 'splice' function. Splice only adjusts a few pointers in the list structure, and doesn't do any allocation. You do have to be very careful about how you use the list though - don't do anything that relies on the structure outside of the mutex. You can also do such things with lock-free fifo's.

Code: Select all

    typedef std::list<QueueItem> Queue;

    Queue to_be_added; // temporarary queue.

    to_be_added.push_back(item); // does a memory alloc

    // acquire mutex
    {
        MutexLocker lock (&mutex_);

        // transfer item to the queue in the time 
        // critical thread, with no memory allocs.
        queue_.splice(queue_.end(), to_be_added);
    } 
    // mutex released

[arakula]

When I drag the scroll bar of my host or move the window of my host very quickly and continuously, the CPU Load reached nearly 100%,that's for sure for the cost of redraw.However, with the high CPU usage the sound was going to distort from then.

I tested this situation on several famous hosts or audio applications like reason, live ,SAVIhost and so on. To my surprise, they all don't have this problem although the CPU usage is high too at that time.

Thanks for the "famous"...

Question is, what DO you do when a WM_MOVE or WM_SIZE comes in? Do you react on WM_SIZING, too? What do you do then?

And, of course, as already pointed out, which priorities did you assign to your various threads?

Do they use some mechanisms to prevent this situation or there is something wrong with my code.

Probably. Moving the window normally requires no complete redraw.

[Alx2Paname]

Hi,
I am currently writing a Borland C++ Builder Component wraper for ASIO. (Same as Tobby Bear Delphi component, but in C++) and I got exactly the same problem as you. However i'm using threads. In the callback function, I just copy the incoming data and resume a thread that deals with it, but it does not fix anything. Did you find out what is the cause of the problem?

[caoxiang]

I haven't yet.
I found it's not a problem of ASIO driver I write because it works the same when I am using ASIO class of someone else.

So the problems lie in our application.