Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


William Kempf wkempf
  • triple your battery life with sand

    @TheTraveler: Batteries have not been improving, at least not in any significant way. Hardware and software have been improving so they require less energy. Even then, the differences are not as dramatic as 2-3 fold increase, like is claimed for this discovery.

  • VB.NET: you can pass a string instead of an int as a function parameter without compile error...

    Java? Java doesn't do automatic type conversion like this. Did you mean JavaScript?

  • Surface Pro 3 as desktop

    , cheong wrote



    Btw, I'll admit he almost got me when the photo seems to suggest you can directly plug a natrual keyboard to Surface Pro 3. I think it could be the case when docking is available, but we shall wait and see.

    The only photo on there with a keyboard that I see shows no cords. I have to assume that's a BT keyboard. I know the mouse in the same picture is BT, because I own and use that particular mouse with my own Surface Pro. In any case, like magicalclick said, the Surface Pro 3 has a USB 3 port, so you could directly plugin any USB keyboard and it will work. Thing is, though, to use the Surface as a desktop replacement you need more than a keyboard (full sized mouse, Ethernet, multiple monitors, more USB ports), so yeah, the docking station is needed.

  • async and lock

    , BitFlipper wrote


    You comment highlights one of the points I'm trying to make in this thread. Basically everyone is so focused on doing things from the UI or web POV that they can't imagine how any other possible scenario might exist where you would to something different. The fact that you don't understand how low latency audio processing works and its related requirements is clear.

    So let me tell you this, boosting thread priority is a Real Thing. There are audio related APIs dedicated specifically to allow for increasing thread priority. See herehere and here.

    So next time please don't insinuate I'm clueless because I work with threads that have their priority increased. Understand the problem before making blanket statements like that.

    You misunderstood. I wasn't saying you wouldn't know how to do this. I was saying the vast majority of developers I wouldn't trust to. So the fact that it's non-trivial to do it makes sense.


    Of course it is. Once your code gets infected with async, you lose all control related to which thread does what, and you might as well give up on realtime audio processing altogether and deprecate all the APIs I linked to.

    Nope. Not at all true. What is true is you can't control what a library supplied method does, but that's true regardless of async/await.


    I hope you are not talking about this:


    How do you manage thread priority? And then there is the whole issue of the latency async adds to calls. Yea, definitely not even close to a solution for this use case.

    I was. ConsumeItemsFromQueueAsync can be implemented with dedicated threads, which gives you full control over thread priorities. What you don't have control over is the async I/O... which was acknowledged by me several times in this thread. There's little you can do about that, unfortunately.

    EDIT: BTW, your code works the wrong way around. It assumes the thread is waiting for work to do and work shows up from somewhere else and is then fed to the thread. Instead, the processing thread requests work when it gets done with the previous work. Also, you don't put these types of work items into any kind of collection. Audio processing just doesn't work like that.

    You asked a very generalized question with few details, and I answered it based on that. I've already told you I know basically nothing about audio processing.

  • async and lock

    , BitFlipper wrote

    @Richard.Hein: Richard, OK that sounds like something I should look into.

    BTW, I was facetious when I said it is either oriented towards UI or web. What I meant was that these types of frameworks/features etc never consider the type of scenarios required for audio processing. We can see how async/await doesn't even allow you to set thread priority anymore since it is supposed to be a black box that magically never blocks and can't possibly cause performance issues.

    To prove my point, even Lucian said the following (all caps are his):


    Performance tests like to greatly disagree with that statement when it is painfully measurable at 6000 to 16000 times slower.

    Heh. Setting thread priority is almost never the right thing to do, and I can count the number of people I'd trust to muck with thread priorities on my fingers. In any case, async/await do NOT prevent you from doing this or anything else.

    I don't understand why you think my pseudo code wouldn't work with dedicated threads? Heck, you could make this simpler with dedicated threads. Have one thread read the stream and fill the queue. Just have it read to the end and fill it, waiting on nothing. Your dedicated threads then simply pull stuff off the queue and process it. Everything runs as fast as it possibly can. The only concern is that being forced to use async I/O may cause latency issues preventing you form keeping the queue full.

  • async and lock

    Looking at the original post, I don't see how your doing random access? In any case, I don't see how it changes the basic idea much? Nor do I understand how the FileOpenPicker is involved here?

  • async and lock

    You could use ConcurrentQueue for this.

    while (notAtEndOfStream)
       await ReadAndFillQueueAsync();
       var tasks = Enumerable.Range(1, n).Select(async _ => await ConsumeItemsFromQueueAsync());
       await Task.WhenAny(tasks);

    You read and fill the queue and then use N background tasks to consume items out of the queue. Those tasks consume items until there are none, and then exit. When any of them first exit you know the queue is empty, so you loop back and fill the queue again, starting N more tasks to consume items again.

  • async and lock

    @BitFlipper: I didn't change the buffer size.

    I don't think you are, but since so many people do and a couple of things you said made me wonder... don't confuse async with multi-threaded. Async code covers a lot more territory then just multi-threaded. Both the TPL and async/await are explicitly designed to cover any asynchronous scenario, not just multi-threaded scenarios.

  • async and lock

    @BitFlipper: The async/await functionality does far more than the code you showed using ThreadManager. It's an important advancement even in non-UI code.

  • async and lock

    BTW, I just tested with actual file I/O, and at least that simulated test did have horrible performance characteristics.

    Sync: 00:00:00.0157656 which is 0.000016ms per op
    Async: 00:00:22.1649903 which is 0.022165ms per op

    So, I really don't have confidence that any of this is going to work for you, but I'm still not willing to jump to conclusions. You really do have to profile the real code.