Firewire driver issues

[manisandher]

With the new version of XX (0.9y-6), I'm realising that my Weiss firewire drivers are not up to the job of providing really low latency. As soon as I switch the Weiss AFI1 unit on, the latency increases from around 50us to 200us and my CPU activity shoots up.

With Engine#4 and Special Mode, I'm at 75 samples with 16/44.1 and 300 samples with QAP. I've 'tweaked W7 to death' and even shut down ACPI. Using the legacy firewire driver helps, but not a lot.

Any other ideas?

Mani.

[earflappin]

Mani, if your firewire interface is async that wouldn't the Weiss be buffering samples so that latency on the PC side would not be a factor?  Or is your firewire interface synchronous?

[PeterSt]

FYI : Assuming a driver won't go as low as the software can go now, the driver will always be "buffering". Asynch may (or should) matter, but I don't think it does. Even in that case latency can be low, and I know of asynch Firewire drivers which allow "infintely" low (with micro sec sliders, but then they are cr*ppy at the same time, so what to do with it really).

I know this isn't very helpful.

Mani, I said it before : don't depend on the latency checker all that much. Mine still shows a consistent 1000 us ...
The cpu going up at switching on the Weiss actually is a (to me) familiar behaviour, and it will even change depending on the latency setting in the driver, and you don't need to play a thing in order to see the cpu behaviour change. This is also a W7 thing, or the combination. Look at Resource Monitor and learn about Deferred Procedure Calls ... not good.

Peter

[manisandher]

Perhaps not related to Firewire driver issues, but I cannot play music for more than 4-5 minutes (at 176.4K) before some sort of interuption. With Engine#3, there is simply a gap, and then the music resumes. With Engine#4, it's a disaster - the dreaded distortion and half-speed!

Mani.

[PeterSt]

Can't this be related to your Split File size setting ?

[manisandher]

Oh yeah, it definitely is. But I have a problem.

You may or may not know that I've just put together a music PC based on the C.A.P.S. server on the computeraudiophile.com site. This uses an Atom chipset, which in itself I don't think is an issue here (though I might get lower latency with a more powerful processor and I think the integrated video really struggles, even when switching to the SVGA driver). The real issue is the 2GB max RAM. The highest that I can then set the split file size is 500MB - worth around 5 minutes of music at 176.4K. So, I get 5 minutes of really, really great sound... and as soon as pretty much anything happens, it goes to pot.

[EDIT: 500MB should really be worth around 10 minutes of 24/176.4 music, no? I'm not sure what's causing the glitch at around 4 minutes then.]

Of course, I could select a much higher buffer for the Weiss. It also has 3 levels of what it calls 'Safe Mode'. I think this is related to the amount of bandwidth that is reserved for the firewire interface, level 3 being the highest.

From the Weiss website:

"But the real reason Firewire is more reliable than USB is more fundamental than that. It's because Firewire allows two operating modes. One is asynchronous, similar to what USB uses. The other is isochronous mode, and it lets a device carve out a certain dedicated amount of bandwidth that other devices can't touch. It gets a certain number of time slices each second all its own. The advantages for audio should be obvious: that stream of data can just keep on flowing, and as long as there isn't more bandwidth demand than the wire can handle (not very likely) nothing will interfere with it. No collisions, no glitches."

I'll play around with all this. But from what you say Peter, it seems that the lower the latency the better, right?

Mani.

[PeterSt]

The highest that I can then set the split file size is 500MB - worth around 5 minutes of music at 176.4K. So, I get 5 minutes of really, really great sound... and as soon as pretty much anything happens, it goes to pot.

Actually I meant it the other way around (*if* the Split File thing is doing to you) : set it lower. So ... setting so high that a complete album will fit into mamory (indeed, upsampled and all) isn't the idea anyway (because that can't work). Having as less I/O as possible is though, so, setting it as high as your memory allows is a good thing, generally.

Now, the loading of a file (part) uses resources of course, and the cpu is the most important here. On that matter an Atom isn't the best thing to choose, but if it has two cores you can always try (completely forget about one core). This was before Special Mode ...
What I didn't realize, is that no matter what Appointment Scheme you select, the track load has to go within a certain amount of time, and this means it takes away cycles from the playback thread. I did *not* provide a scheme or setting which prevents that (although I theoretically could). Now the hard part : normally this is no problem because of the priority settings and the playback thread will be scheduled more often than the "load thread" anyway, however, this is not about "more often" but merely "with superspeed at the same time" because otherwise it just will be too late. And now it just comes down to sheer processor speed (which an Atom has not).

The scheme which gives you the best chances on this is Scheme-1. If that seems to help, next try Scheme-2. The others are worse for you.
In the mean time set the Split File part to 30. You can always higher it later when it helps.

In either case, keep in mind that you need the *lowest* latency from the Weiss, not the highest. This is similar to the File Part thing : when the chunk gets too large, it will take a too long time in a row before something else (like playback) gets a sufficient amount of cycles again.

HTH !
Peter

[manisandher]

Thanks Peter - definitely helpful. Hopefully I'll have a chance to play around with buffers and split file sizes later today. But I believe these will just help me determine the lowest latency that I can go for. For now, I'm pretty certain it's around 75 samples.

I'm not sure what's causing the glitch at around 4 minutes then.

Correction: I don't get a glitch around 4 minutes. Actually, I get a glitch around 10 seconds before the end of a track. The track that I was using just happened to be around 4 minutes long.

Peter, what's happening just before the end of a track to send my modest music PC into a spin? Is there anything that you or I could do about it, other than what you already posted in your previous thread?

Mani.

[manisandher]

...completely forget about one core.

OK, so here it is. The Atom N270 is one core... but it has two threads - any good?

It looks like my search for the perfect music server for XXHE continues...

Mani.

[PeterSt]

Mani,

If your Split File size is large enough to cover for one track, then you would always have the "next track load". This is unavoidable because of the reason I gave before : no sense to expect anyone to load a complete album in memory. Now, it *still* applies that the larger setting may not be the best, because it still will be so that the complete track is loaded while the burden on the resources are too high (too long actually !).

I never understood hyperthreading very much because a couple of guys out on the internet are persistent in telling (me) that one thread is for special activities only (like what a "co-processor" used to do in the early days). Together with that, those having it shut off (which has to be in the HAL (Hardware Abstraction Layer) have the least stuttering movies. I'm amongst those for my HTPC.
The story is ages longer, but my conclusion of it all is that hyperthreading is too much of fake to be real. And indeed, why would we have processors with two real cores nowadays otherwise ?

But don't blame me if I'm wrong on it !
Peter

[manisandher]

Could this be a coincidence?

I've just tried 0.9y-6 on my laptop feeding the Weiss AFI1 interface. And the exact same thing happens. In Engine#4 'special mode', I have to set Q1 to the exact same level (569) in order to get glitch-free sound.

In 'normal mode' I can play at Q1=-1 no problem. I know that there is no correlation between the Q1 settings in 'normal' and 'special' modes. But I can't help thinking that my Weiss firewire drivers like 'normal mode' but don't like 'special mode' very much...

In any event, it looks like my new single core PC is at least as capable as my dual core laptop

Mani.

[manisandher]

In Engine#4 'special mode', I have to set Q1 to the exact same level (569) in order to get glitch-free sound.

CORRECTION:

To get totally glitch-free sound playing a number of tracks on my new Atom-based PC, I have to set Q1 to around 2000. So, it may not be the firewire drivers afterall all!

In any event, I've ordered a new motherboard with 4GB RAM and an E8600 processor.

Mani.