Well, the DAC isn't on a USB port, so I can't try another one.😀 There's only one Express Card slot so I can't change that.
As much as I disliked my old computer (a particularly truculent HP), I'm beginning to hate this one more.
As much as I disliked my old computer (a particularly truculent HP), I'm beginning to hate this one more.
ahhh I thought your sound card was USB, oh well! lets hope it isn't an unchangable interrupt problem then! Hang on I remember where the USB came from, your music drive is connected via USB is it not?
Tony.
Tony.
OK, I had a thought I had to throw in here before getting back to work. Doesn't windows treat Firewire like a network connection? I seem to remember seeing IEEE9334 (or whatever the firewire name is) in the network adapters list on some computers. I wonder if this is somehow related (this is just a bit of posturing here).
Yes, my music is kept on a USB drive. I get the same problem when I play stuff from my hard drive.
Pedro, that sounds like something plausible. I will see what the Princess says. 😉
Pedro, that sounds like something plausible. I will see what the Princess says. 😉
i'm talking about the hardware buffer, notice I mention the M-audio control panel? this interfaces with the hardware to change settings. all the same your explanation seems feasible too
Yes, I noticed. I don't call that a hardware buffer - to me a hardware buffer would take one of two forms - a dual port memory with hardware pointers, or a FIFO (which might well be the same internally). Bottom line - if its adjustable its almost certainly not a hardware buffer.
Just a long shot, but...
I don't have a firewire interface installed so I can't go "look", but in reviewing this thread it would seem the issues start and persist some way and are related to the ndis.sys driver in Vista. That driver is part of networking - no doubt.
Soo.. just looking around, seems Vista has a little "feature" to use a firewire interface as if it was a real network interface.
Here's a possible suggestion (heck, if it doesn't do it, no harm, just reverse). Go into your networking settings on the PC and get to where you can see the network adapters. List the window by details and find the one (if it's there) that is showing as the firewire/IEEE1394 adapter. Look for the settings that "bind" it to certain features / protocols / etc (like TCPIP), and uncheck everything there. And then right click and disable it.
Then try audio again. (and heck.. if this was already tried, then
)
I don't have a firewire interface installed so I can't go "look", but in reviewing this thread it would seem the issues start and persist some way and are related to the ndis.sys driver in Vista. That driver is part of networking - no doubt.
Soo.. just looking around, seems Vista has a little "feature" to use a firewire interface as if it was a real network interface.
Here's a possible suggestion (heck, if it doesn't do it, no harm, just reverse). Go into your networking settings on the PC and get to where you can see the network adapters. List the window by details and find the one (if it's there) that is showing as the firewire/IEEE1394 adapter. Look for the settings that "bind" it to certain features / protocols / etc (like TCPIP), and uncheck everything there. And then right click and disable it.
Then try audio again. (and heck.. if this was already tried, then
)
hmm well you really need to come up with another name for it then dont you? because its almost certainly in hardware
If it is the latency setup in M-Audio PCI card control panel, then it is length of a region in RAM allocated for DMA communication with the card. The longer the region, the more data the card reads on itself before throwing the "I am done consuming your data" interrupt. Its length is known to the driver as well as the PCI controller of the card. I would be inclined to call this a hardware buffer.
So that DMA is done as a burst? If so the DMA would grab the bus and stuff the whole contents out into the card in one hit. Then there'd need to be a hardware buffer on the card to accept it and that hardware buffer would need to have a size which corresponded to the RAM buffer. In which case the term 'hardware buffer' for what I'd call then the DMA or RAM buffer would be confusing. Or does the DMA use cycle stealing?
The card reads audio data from the allocated RAM continuously (perhaps cycle stealing? - I am no PCI expert 🙂 ) into a small 12 samples long buffer in the PCI audio chip. See page 46 in http://alsa.cybermirror.org/manuals/icensemble/Envy24HT091DS.pdf (envy24 of M-Audio PCI cards).
OK, that 12 samples long buffer is what I was referring to as a hardware buffer. It seems from section 4.2.2 that each DMA burst is 4 buffer layers deep. This latency setting in the M-audio driver will make no difference to the glitches in playback which result from this on-board buffer under-running. The IRQ/DPC has a maximum allowance of 180uS before under-run occurs. That is assuming the Envy chip requests service when it has 4 layers of buffer empty.
Thanks for providing the link, that's interesting.
Thanks for providing the link, that's interesting.
This 12 samples buffer is for DMA communication, i.e. moving data between envy24 and RAM via the onboard DMA controller. I am no PCI expert but IMO it should be long enough for even a loaded PCI bus.
IRQ/DPC (bottom half called in linux IIUC) is a different mechanism. During initialization of the card, the driver tells the controller among other the lower and upper addresses of the DMA buffer (sort of). When the reading starts, it tells the card another address - interrupt threshhold (I do not know the exact name). When the card passes this address, it throws IRQ to tell the driver/playback software that it has finished reading the previous part of the buffer. I never studied windows, but in linux alsa the DMA buffer is called buffer ( surprisingly 🙂 ) and the shorter segment between interrupts is called period. You can setup both of these to any length supported by the actual hardware (limits are defined by the corresponding driver). There should be at least two periods in the buffer, so that when the card is busy reading one period, the application can store audio data in the other period. Therefore the card will throw two IRQs during reading the whole buffer. For details see TBFKAYIBYNYAAYB by the author of pulseaudio.
I do not know about windows, but in linux I can easily see (watch -n1 cat /proc/interrupts ) the actual IRQs being thrown. To minimize the danger of underruns, it is generally recommended to keep the buffer at maximum value supported by the card (e.g. 2secs for intel HDA, over 1s for Envy24) and to keep periods small (e.g. 1/8th of the buffer size) so that application is well ahead of the card's reading pointer. AFAIR I could setup Envy24 for 48kHz audio to throw about 2 IRQs per second only, with the application being asked to copy bursts of fresh data into already-played RAM location only 4 times/second. Such setup is pretty robust and resistant to underruns, even under large system loads. Of course this adds huge latency, but that is no problem for pure listening to music.
Last edited:
What is interesting and not very well known is that USB sound cards operate in a very similar way. I did some USB audio stress testing with IMO surprising results http://www.diyaudio.com/forums/pc-based/93315-linux-audio-way-go-23.html#post1719044
From what you're writing, it sounds as if the Linux sound architecture is somewhat better optimised than that under Windows. However you're talking about the application interface to the driver only taking 2 IRQs per second. Whereas here we're talking driver to hardware interface which clearly needs a lot more IRQs and hence much better latencies. SY's getting glitches because the OS isn't letting his driver IRQs (done via DPCs) get a look-in until its too late - sometimes 20mS too late. My own suspicion is that this isn't actually the OS, rather its a driver somewhere locking things down until it gets the results it wants. Sometimes this happens with my DVD-ROM (SATA) under Windows - everything pretty much hangs until that completes.
I'm hoping that's right because that could be fixable. I'm hearing pessimistic noises coming from across the table this morning...
I don't know. The hardware works identically regardless of the OS. From what Lennart says in his aformentioned article, modern windows (vista+) use the "glitch-gree" playback technology where the framework ignores actual sound card interrupts and calculates (i.e. estimates) exact position of the card reading pointer in software using high resolution software timers/interrupts. That is more prone to underruns.
The major difference is level of configurability. If you could setup the buffers/periods in windows the same way you can do in linux, those 20ms of IRQ service delay would be negligible if the application had a few hundreds ms of time available. Perhaps this setting is available somewhere deep in the OS, I have no idea though.
Well, if the upper half of the IRQ service (the supposedly short one which cannot be interrupted) is too long, the whole system stalls. Certainly there can be a bug in any of the drivers, quality of drivers is pretty poor in all major OSes. Or a hardware fault should be considered too.
Has anyone seen how IRQs are shared on SY's laptop?
Last edited:
I have no idea what is required to get your audio setup running on linux, but you could try downloading the unbutu live cd, which lets you boot up off the cd without installing anything, great for digging into the hardware too 🙂
Whether you could stream audio to you dac from just the cd boot I don't know, if you can then it would give you a much better idea as to whether your problem is hardware or software/OS based...
Tony.
Whether you could stream audio to you dac from just the cd boot I don't know, if you can then it would give you a much better idea as to whether your problem is hardware or software/OS based...
Tony.
- Status
- Not open for further replies.