IraSeigel wrote:So I understand you to mean that, with your test above, you can pretty much surmise that the SidSpeed entry (entries) alone were enough to cause the increase in speed/bandwidth. The lack of the new DLL is not a cause for your concern. Is that correct?

Cheers,
Ira
PS Because this SP3/Firewire issue is something that I hadn't read about here before, maybe a new thread with a descriptive title would bring attention to this issue?

Ira, I think there's more to the fix than simply the SidSpeed entry, but yes, I did some further tests (with bigger block sizes) and got 32000 KB/s - well up there around 250MB/s, so I'm convinced the patch works.
I might add a link to the earlier SP3 thread, if I can find it, just to direct people to this thread.

Dominic

DominicPerry wrote:Ira,

No sign of that dll or of any dll with 1394 in the title - all the proprietary FW drivers have 1394 in them, so a search for 1394 turns them all up. Basically, no fw dll has been installed with this fix. That doesn't concern me - the SidSpeed entry is not attached to a dll, it's associated with a device. Previously you had to find the device in the registry manually - now the downloadable fix finds it for you.

I guess it should be easy to calculate the speed of FW400 running at 100Mb/s and see if I can transfer data faster than that - to my external harddisk. If I can, the fix has worked.

Dominic

- EDIT I reckon 100Mb/s is 12.5MB/s. Hdspeed.exe gives me 13000KB/s write - marginally faster (perhaps within margin of error) but read is 19000KB/s - so it's working faster than 100Mb/s.

So I understand you to mean that, with your test above, you can pretty much surmise that the SidSpeed entry (entries) alone were enough to cause the increase in speed/bandwidth. The lack of the new DLL is not a cause for your concern. Is that correct?

Cheers,
Ira
PS Because this SP3/Firewire issue is something that I hadn't read about here before, maybe a new thread with a descriptive title would bring attention to this issue?

Ira,

No sign of that dll or of any dll with 1394 in the title - all the proprietary FW drivers have 1394 in them, so a search for 1394 turns them all up. Basically, no fw dll has been installed with this fix. That doesn't concern me - the SidSpeed entry is not attached to a dll, it's associated with a device. Previously you had to find the device in the registry manually - now the downloadable fix finds it for you.

I guess it should be easy to calculate the speed of FW400 running at 100Mb/s and see if I can transfer data faster than that - to my external harddisk. If I can, the fix has worked.

Dominic

- EDIT I reckon 100Mb/s is 12.5MB/s. Hdspeed.exe gives me 13000KB/s write - marginally faster (perhaps within margin of error) but read is 19000KB/s - so it's working faster than 100Mb/s.

DominicPerry wrote:Good find Ira. I've just downloaded the fix (well, requested it and gone into my mail and linked to the embedded web-page and downloaded it and then extracted it and used the password in the email and then applied the fix and then rebooted). Now I have a SidSpeed entry (of 2) in my registry (2 being the setting for 400Mb/s - it needs to be 3 for 800Mb/s).

Of course, I have no idea if it works.

Dominic

Hi Dominic,
According to the KB article, you should also have this new file installed: Cstupd1394sidspeed.dll

I've done a complete search of my HD, and I can't verify it's been installed. What were your results? I would guess that without the updated DLL, the SidSpeed entries (that you could add manually via RegEdit) will not be of any use. Just my guess, tho.

Ira

Good find Ira. I've just downloaded the fix (well, requested it and gone into my mail and linked to the embedded web-page and downloaded it and then extracted it and used the password in the email and then applied the fix and then rebooted). Now I have a SidSpeed entry (of 2) in my registry (2 being the setting for 400Mb/s - it needs to be 3 for 800Mb/s).

Of course, I have no idea if it works.

Dominic

DominicPerry wrote:Ira, the irritation is that you can't really ask/test to find out what speed your FW is running at. The SidSpeed registry entry was a new entry with SP2, - ie it didn't show up with the original XP and SP1. It was introduced with SP2 to 'fix' problems people were having with FW - truly a stupid fix if ever there was one.
So it may be that SP3 removes the SidSpeed entry altogether and that SP3 does, indeed, fix the SP2 issue and bring FW back up to 400Mb/s. I don't know and you can't test it. I suggest doing some searches on the MS site.
One thing I can say for sure is that this IS an issue with FW400, not just FW800. So it is worth pursuing. I'll look into it tomorrow, if that helps.

Dominic

Here's how our friends at Microsoft are supporting the audio community:
http://support.microsoft.com/kb/955408/en-us

Ira

Ira, the irritation is that you can't really ask/test to find out what speed your FW is running at. The SidSpeed registry entry was a new entry with SP2, - ie it didn't show up with the original XP and SP1. It was introduced with SP2 to 'fix' problems people were having with FW - truly a stupid fix if ever there was one.
So it may be that SP3 removes the SidSpeed entry altogether and that SP3 does, indeed, fix the SP2 issue and bring FW back up to 400Mb/s. I don't know and you can't test it. I suggest doing some searches on the MS site.
One thing I can say for sure is that this IS an issue with FW400, not just FW800. So it is worth pursuing. I'll look into it tomorrow, if that helps.

Dominic

IraSeigel wrote:>snip<
I'm curious as to your comment that you are working at 4x32 with RME equipment. My up-to-date driver for the Fireface 800 and 400 gives me an option as low as 48 samples. I know others here are operating at lower sample settings with RME, but with a FF800 or 400? If so, please tell me what I'm missing. (I'm using a LaCie FW Cardbus adapter - not PCI or PCIe. Maybe that's the difference?)

Thanks all,
Regards,
Ira

Yes Ira - my RME setup runs from PCI (desktop) and PCIe (laptop).
4x32 is on my desktop Asus P5KPro.
Laptop runs 6x64.

cheers

mako

Bob L wrote:Still sounds like something is interfering with your low latency stability... something is stepping on the main engine threads and allowing Windows to go off and process something other than your soundcard for too long of a time, causing dropped buffers.

Are you setting SAC to the RealTime Priority option... sometimes, that is enough to get its threrads ontop of whatever is stealing the cpu.

I notice also you are using firewire... be very aware of the XP SP2 firewire issues. Search the threads here for setails on fixing the Microsoft firewire issue... which is very real.

Bob L

I've searched the threads, as suggested, and found OT: Firewire 400/800, with the last entry from April, 2008: http://www.sawstudiouser.com/forums/sho ... rewire+fix

The Knowledge Base article in the Microsoft archive - KB885222 - says that their fix is designed to be installed on a machine running XP SP2: http://support.microsoft.com/kb/885222/en-us.

Would anyone know if this also applies to SP3?

And - rhetorical question - why wasn't this fixed with the release of SP3? I can assume it wasn't, since there was no SidSpeed entry in the 1394 section of my registry.

Besides the SidSpeed entry as noted in the SAW thread above, are there any other driver or file changes to make? RME has a very in-depth - i.e., confusing - article on the subject: http://www.rme-audio.de/old/english/tec ... 800sp2.htm - but it refers to FW800, I believe, and doesn't indicate the problem also exists with FW400.

Thanks,
Ira

XP SP2 and higher have been known to force the firewire performance down to 100 mps... you must use the firewire fix methods to get it back to 400 mps.

Bob L

Hi. Thanks guys. Here's a few things I learned after reading your posts:

Chris - I had MANY processes running in the background, according to Task Manager. But prior to the start of my session, I had stopped and exited from my anti-virus program and a service that syncs my cellphone with my laptop (ActiveSync). However, some of these programs - AntiVirus in particular - and McAfee is the worst, IMO -still keep searching the internet periodically for updates, so I should have shut these down in Task Manager, as well.

Scott - I did have onboard audio working. My Windows Media Player was being used to play walk-in music. I think when I turned off WMP, my dropped buffer problem was solved. Also, I think I might have had my wireless on, searching for an available network. Oops, and thanks for the tip.

Bob - I had forgotten to set SAC for Real-Time Priority. I will next time. Thanks for the reminder. Also, I'm using Firewire 400, as I could never get FW800 to work properly and I really don't need the extra bandwidth anyway. I wasn't aware of a FW400 problem with WinXP SP2 (now SP3). Is there an issue that needs a Knowledge Base fix for FW400?

Mako - yes, I found the same to be true in regards to not hearing the effect of the dropped buffers. I'm assuming I'd hear very clearly any dropped input buffers, but these were happening on the output buffers and not audible to me in the circumstances I was in. I'm curious as to your comment that you are working at 4x32 with RME equipment. My up-to-date driver for the Fireface 800 and 400 gives me an option as low as 48 samples. I know others here are operating at lower sample settings with RME, but with a FF800 or 400? If so, please tell me what I'm missing. (I'm using a LaCie FW Cardbus adapter - not PCI or PCIe. Maybe that's the difference?)

Thanks all,
Regards,
Ira

G'day Ira - if I use my standard XP installation - my laptop also drops buffers like crazy.

If I use my dual boot system that has standard XP Pro on it, I still get a few dropped buffers, but over a recent 2 day festival, I didn't hear anything bad at all.

Something else to think about (as Bob has obviously found out), my home PC (Asus P5K Pro) will run 4X32 with no dropped buffers.

All on RME

good luck

mako

Still sounds like something is interfering with your low latency stability... something is stepping on the main engine threads and allowing Windows to go off and process something other than your soundcard for too long of a time, causing dropped buffers.

Are you setting SAC to the RealTime Priority option... sometimes, that is enough to get its threrads ontop of whatever is stealing the cpu.

I notice also you are using firewire... be very aware of the XP SP2 firewire issues. Search the threads here for setails on fixing the Microsoft firewire issue... which is very real.

Bob L

Use the utility here:

http://www.thesycon.de/deu/latency_check.shtml

to check to see if you're getting deferred procedure calls that are delaying audio driver processing (DPC latency).

If you are, then it's time to start disabling onboard audio, network interfaces, wireless, etc.

Scott.

Hi Ira:

You might check to see if any services are runnung in Task Manager that are sucking up CPU cycles If so kill them and check with SAC again.

Hope it get strightened out!

Chris

I am dropping output buffers like crazy, an average of maybe 1/second, although I'm not exact on that. According to the indicator, they are being repaired. I am not dropping any input buffers.

What do dropped output buffers sound like? What kinds of things can I do to reduce the problem? Is it a problem?!?

I am working with an older Thinkpad and a Fireface 800 and ADA8000. CPU load is between 2 and 3 percent. No plugins, just SAC EQ and dynamics.

My ASIO and SAC are set to 64 samples and 4 buffers (crackling at 48 samples).

Thanks,
Ira