Actually, it would be a crappy driver to be thrown out. The device itself is innocent

That is not always the case Remember the Creative Soundblaster Live! , it had a design that was using the PCI bus in excess and caused problems with some chipsets. ( I've quickly searched for a link about it and found this: http://www.tomshardware.co.uk/forum/37211-...opping-crakling . Guess i could find a better source with a better searching)

Yeah but if you can fix all the glitches by reducing the DPC latency then the sound card is not broken, regardless if somebody is absolutely convinced of that. As absurd as it sounds, DPC latency can be (temporarily) reduced even by just restarting/disabling certain Windows services.

saratoga, you don't know what laptop I have, what sound card I use or anything else yet you're absolutely convinced my hardware is broken. I'm sorry if I offended you but imho it's exactly what I said it is. Same goes for your "throw it out a window" statement.

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.

Like ISRs/DPCs? You don't have to try to teach anything here, just tell me what you mean.

Like ISRs, DPCs, and every data bus, register, and byte of memory inside the PC.

I don't have to diagnose the problems, all I have to know is that the problems still happen.

It is a simple fact that people still have tics and pops in PCs that don't route audio through USB. Therefore it is abundantly clear to anybody with an ounce of brains that you can systematically fix USB all you want, and those kinds of problems will still exist, and there will be tics and pops.

If you raise playback buffer/playback latency, will it cure the pops and clicks? The clicks in most cases are simple late delivery of samples to RAM for the soundcard to read via DMA. If you keep the playback process more ahead of the reading pointer, you get more time headroom for the playback chain.

With windows Vista and upwards, microsoft changed the way the audio stack worked inside the OS. With windows XP, I can almost halt the PC if I run an audio thread at high priority and uses all the cpu (ok, one core), but with Vista, you get audio skips.They moved the audio stack out of the kernel, and that way it lost part of the "privileges" that it had until then.

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.

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.

I am talking about the direct DMA buffer, not a buffer which gets redefined by the mixing layer.

QUOTE ([JAZ] @ Aug 6 2012, 20:00)

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.

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.

Well, that document does not mention the DMA buffer at all. Raising the buffer fixes any DPC problems (unless a really buggy driver hogs the CPU), provided one does not need to keep latency low for recording/authoring work. That is a situation very different to pure playback scenario.

I am aware of the fact that raising the buffer is often not an option on windows. That is why I use linux for audio. But the hardware itself is OK, fault of the rigid software stack. I have not heard of the SB Live problem in linux - every PCI card communicates over PCI constantly, reading the sound samples via DMA. IMO the cause is a too low DMA buffer chosen by the proprietary driver, causing underruns for slower PCI hardware.

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.

Yes, that says the maximum has been 19 milliseconds. 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, but I guess this sentence of yours is the key "I am aware of the fact that raising the buffer is often not an option on windows. That is why I use linux for audio."

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.

Well, I do not know what that number means, since the output also says:

CODE

DPC count (execution time >=4000 Ás): 0

It could as well be a total time spent in DPCs of ACPI.sys during the test period. No source code available to find out, but you can try to ask the developer.

QUOTE

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 do not know if these are DMA buffers the soundcard is using, or some intermediate buffer for the windows audio subsystem which allocates a different size buffer for the actual transfer to the soundcard. My knowledge of windows audio is almost zero

QUOTE

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.

For pure playback the figures do not have to be so low. E.g. MPD uses 500 ms buffer by default.

QUOTE

I was going to ask why you talk about DMA buffers...

Because that is the buffer which counts when dealing with audio nondelivery to the soundcard. For PCI/e devices (not USB) the ASIO buffer is the direct DMA buffer, buffer allocated by linux alsa for raw hw:X device (e.g. used by MPD playing to hw:X device) is the direct DMA buffer too. This is to show that the DMA buffer is accessible, it does not have to be something hidden deep in the driver layer. I have no idea about other windows sound systems. In fact there are developers of some commercial closed-source audio players (I will not name, it is googleable ) who have no idea about the DMA transfer and believe the CPU sends data directly to the soundcard.

USB devices work a bit differently, the audio buffer is used by the USB driver to prepare/mix final USB frames for all current USB streams to the actual DMA buffer for the USB controller to read.

QUOTE

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.

In the end every OS communicates with the hardware in basically the same manner, unless one features a bug in the driver. Linux offers access to even the lowest software layers which means an advanced user can tweak the params at will. I have tried to torture the USB audio stack and it proved to be surprisingly resilient - http://www.diyaudio.com/forums/pc-based/93...tml#post1719044