- THREAD STUCK IN DEVICE DRIVER RANDOMLY THROUGHOUT THE DAY SOFTWARE
- THREAD STUCK IN DEVICE DRIVER RANDOMLY THROUGHOUT THE DAY CODE
For this ‘thread local singleton’ pattern of sorts the TLSObject class is used.
As each driver/device creates its own thread in which the buffer switch callbacks run, the usual and obvious method is to use thread local storage to store a this pointer (to an ASIO device instance).
The first problem is not directly solvable as it is part of the binary specification of the API so a workaround must be used. The first one being the buffer switch callbacks that typically lack the ‘ void * pUserData’ ‘emulation’ of the this pointer and the other one being the implementation of the SDK itself that, in typical C fashion, uses a global variable to store the pointer to the active driver’s COM interface. Looking closely two culprits are identified. Give me my this.Īs mentioned in the introduction, one of the first things that I noticed in the SDK documentation was the one about the ‘unfortunate’ support for only a single active device/driver. This article supposes that the reader already has some knowledge of the API and the terms connected to it.
THREAD STUCK IN DEVICE DRIVER RANDOMLY THROUGHOUT THE DAY SOFTWARE
In short, ASIO is an acronym for Audio Stream Input Output and is a technology developed and publicly released by Steinberg Media Technologies GmbH that tries to overcome inherent flaws in previous APIs for audio streaming that prevented the creation of low latency, sample accurate software applications for the personal computer (the sample accurate part of course being more important for simple playback applications like this one). But before we dive into it all, a ‘little’ background is in order. For the said reason you’ll see me ignoring Knuth, Hoare and Sutter and doing the ‘root of all evil’, with pleasure.
THREAD STUCK IN DEVICE DRIVER RANDOMLY THROUGHOUT THE DAY CODE
I tried to test and prove that the two poles are not the only available approaches and that code that is both efficient AND follows modern design patterns and idioms, or in other words, that is relatively easy to read and handle for both the developer AND the hardware, is actually possible. The second, or better, a ‘parallel’ one, is the ugliness and the bad/outdated/’typical C-style’ design of most APIs ‘out there’ or, on the other hand, the bloatiness of many, more modernly designed, libraries that usually reek of the ‘oh who cares, today’s computers are fast enough’ mentality. The most important ‘flaw’, which inspired this project and the wish to overcome it, was the official statement of the ASIO SDK that it does not support multiple (active) ASIO drivers. The sad reality of most libraries, that there is always 'something wrong with them' (be it a matter of objective flaws or subjective preferences), can actually turn out to be a 'positive' driving force in learning projects like this one. Achieving that goal while trying not to just reinvent the wheel or repeat existing solutions but to do it better and/or differently makes the meat of this article and the source code behind it. As this is not a purely theoretical article, there is an actual binary product of the following story, a working ASIO output plugin for WinAMP. Having a passion for demanding low-level C++ programming and high fidelity digital audio, fiddling with ASIO seemed like a good idea to test and improve my skills. Should one wonder, from the number of acronyms/technologies mentioned in this article, there actually is a core theme from which the others sprang and this is ASIO (the audio related one from Steinberg, not the network related Boost library).
0 kommentar(er)
