No, its cheaper just figure out what broken device you have that is blocking inside an ISR (!!!) and throw it out a window.
Actually, it would be a crappy driver to be thrown out. The device itself is innocent
That is not always the case
Quote from: Arnold B. Krueger on 04 August, 2012, 06:43:50 PMOn paper, many look like they should be abundantly fast and never lose a sample. But in the real world, stuff breaks and other tasks interfere.Like ISRs/DPCs? You don't have to try to teach anything here, just tell me what you mean.
On paper, many look like they should be abundantly fast and never lose a sample. But in the real world, stuff breaks and other tasks interfere.
When defining the buffer in an application, you're defining the buffers that it gives to the driver. With ASIO (and real drivers, not API emulators like ASIO4All), the same buffers are then sent to the soundcard, but with other APIs, that's not necessarily the case.
Now, don't forget that the meaning of multithreading is, in fact, slice tasks of different threads/programs in time fractions determined by the Operating System, and then run each one sequentially, determined by task priority and other order mechanisms. And here is where the DPC latency plays a role. Basically, the problem is that once the soundcard driver needs audio, it schedules a callback that will provide this data, and this acts as a queue. (separated from user programs and with higher priority).The latency of the DPC queue is determined by the different drivers that run, and the code it executes. It is expected that these calls are fast, but when they are not, the scheduled callback might not return in time to avoid audio skips.
(Better explained in http://www.thesycon.de/deu/latency_check.shtml#background )
DPC is in single milliseconds at worst, while soundcards easily handle DMA buffers of hundreds of millisecs, some even seconds. The trick (unless low latency required) is to raise the buffer sufficiently.
REPORTED DPCs_________________________________________________________________________________________________________Highest DPC routine execution time (µs): 19488,501337Driver with highest DPC routine execution time: ACPI.sys - Controlador ACPI para NT, Microsoft CorporationHighest reported total DPC routine time (%): 2,344699Driver with highest DPC total execution time: ACPI.sys - Controlador ACPI para NT, Microsoft CorporationTotal time spent in DPCs (%) 3,438667DPC count (execution time <250 µs): 381482DPC count (execution time 250-500 µs): 0DPC count (execution time 500-999 µs): 1334DPC count (execution time 1000-1999 µs): 6675DPC count (execution time 2000-3999 µs): 887DPC count (execution time >=4000 µs): 0
Yes, that says the maximum has been 19 milliseconds.
DPC count (execution time >=4000 µs): 0
Just playing a song with directsound set at 5 buffers of 1576 samples (176ms of audio latency, 44Khz).And obviously, i had audio skips.
I can get as low as 59ms with directsound and 25ms with WASAPI (And even less with ASIO and Asio4all). It really depends if the system wants to lag or not.
I was going to ask why you talk about DMA buffers...
So, now that we're on linux... What problems have you experienced with USB Audio over it? It's just so that we can conclude that Windows is more prone to the problem, and as such, it's audio stack, and not the USB protocol.