When limiting the BW to use only "Analog 1-8 + AES" then 192kHz works. But not 48kHz.

I tried different different Fw driver (normal and "legacy") and now also my VIA Fw chip on board.

While trying/changing different settings inside Cubase (Samplerate) and in the RME Fw Driver now of all sudden I get a different problem. When booting Windows the Firewire driver keeps a clock rate of "0". Even if I do not start cubase in anyway the clockrate stays at "0". Pitch settings are also unusual, and the limitation of BW also turns to "Analog 1-8".

These are my standard settings:

And this I get now on each reboot:

Where does the RME Firewire Driver remember its clock and other settings ... ?
How do I get rid of this, that on each reboot the clock rate now goes to "0" instead "44.1 kHz" ???

Thanks for any help.

Yes I did Timur. 1st I used a Lindy Quality Cable (it was in use since 4y on this particular machine, 1st with the Focusrite LS56 now with the UFX). Then I tried with the RME Firewire Cable that was shipped and these 2 cables made no difference.

Could it perhaps be the case, that the Firewire driver is more picky about the situation, that the connected pre-amp is unable to sync on higher clocks ? Its permanently set to 44.1, as I only want to use the UFX channels at 192kHz ...

The USB driver seem to have absolutely no problems with this, is maybe firewire different "by nature" and has other requirements ?!?!?!

I will perform now a test and disconnect the OctoPre and see whether this makes a difference.

Any idea why now the Fw driver always stays at 0 kHz after a reboot of all devices (including proper power cycle) ???

Ok, I removed now the OctoPre Mk II. Removed TOSlink cables completely. Removed the Wordclock 75Ohm sommer cable and deactivated the internal 75 Ohm termination in the UFX. I configured in the Fw driver 7 WDM devices (no ADAT to be seen there).

Then under Cubase 7.5.20 I removed in the VST connections all ADAT channels in the Inputs and Outputs. Am not shure whether this is required but appears to me cleaner for this test.

Sample Rate / Buffersize:
44.1 - ok with sample sizes >= 48 (48 is the min.), BW: "all channels"
48    - does not work in any way (no sound to be heard at all, no clicks, no pops,..), 7 Errors/sec
          limiting Bandwidth from "all channels" to "Analog 1-8 + AES" doesn't help
          raising buffersize from 48 to at min. 64 samples (up to 2048) fixes the issue here, BW: "all channels"
64 - ok with sample sizes >= 96 (96 is the min.), BW: "all channels"
88.2 - ok with sample sizes >= 96 (96 is the min.), BW: "all channels"
96   - ok with sample sizes >= 96 (96 is the min.), BW: "all channels"
176 - sound from Mic gets interrupted, I hear clicks and "grizzling noise", error counter slowly increasing (~1,8 error/sec), sample size is 192 (min.) and BW "all channels" ....
        limiting the BW to "Analog + AES" fixes the issue, even with lowest buffersize 192 samples.
        raising the buffer size up to 2048 samples and keeping BW to "all channels" doesnt fix the issue
192 - sound from Mic gets interrupted, I hear clicks and "grizzling noise", error counter increasing more rapidly (~2,7 error/sec), sample size is 192 (min.) and BW "all channels" ....
        limiting the BW to "Analog + AES" fixes the issue, even with lowest buffersize 192 samples.
        raising the buffer size up to 2048 samples and keeping BW to "all channels" doesnt fix the issue

Well .. wondering now, whether this might have to deal with cable quality ...

What I do not understand is, why
a) with 48 kHz limiting the BW to "Analog 1-8 + AES" doesn't fix the problem, like it does with 176 and 192.
b) with 176 and 192 kHz raising the ASIO buffer size up to 2048 doesn't fix the issue, but when limiting the BW from "all channels" to "Analog 1-8 + AES" then it fixes the issue even with smallest Buffersize of 192 samples.

@MC: Mathhias .. cable or HW problem  ???

BTW .. I did a check with LatencyMon 4.02, which shows a kernel timer latency of 1.5 - 5 µs with some little peaks up to 14µs. There I am pretty sure that I have no issues...

Today I tried the new Lindy Premium Fw Cable. Same problems.
I also tried the 2nd port of my EYSYS card, no change as well.

Then I also tried a different Windows 7 SP1 machine, 64-bit. Lenovo T540p using a SIIG Fw Express Card with TI chip.

Card description: SIIG N301104X0354 NN-EX2012-SI.
Nearly same problems.
- 44.1, 64, 88.2, 96 kHz all ok with lowest sample frequency of 48/96 buffers and using full Fw Bandwidth (Bw) "All channels"
- With 48 kHz only raising the sample rate from 48 to 64 Buffers helps. Limiting Fw Bw to "Analog+AES" doesnt help alone
- With 176 and 192 kHz I also have problems like on my PC
- 176 kHz, All Channels, 192 Bufsize: Audio ok, no Error counter
- 176 kHz, All Channels, 256 Bufsize: Audio hearable, but clicks, no Error counter
- 176 kHz, All Channels, 384 Bufsize: Audio hearable, but clicks, no Error counter
- 176 kHz, All Channels, 512 Bufsize: Audio Outages, clicks, Some Errors shown (~4 in a minute)
- 176 kHz, All Channels, 1024 Bufsize: Audio Outages, clicks, Some Errors shown (~4 in a minute)
- 176 kHz, All Channels, 2048 Bufsize: Audio Outages, clicks, Some Errors shown (~4 in a minute)
- 176 kHz, Analog+AES, 192 Bufsize: Audio Outages, no Error counter
- 176 kHz, Analog+AES, 256 Bufsize: Audio ok, no Error counter
- 176 kHz, Analog+AES, 384 Bufsize: Audio ok, no Error counter
- 176 kHz, Analog+AES, 512 Bufsize: Audio hearable, but clicks, no Error counter
- 176 kHz, Analog+AES, 1024 Bufsize: Audio ok, no Error counter
- 176 kHz, Analog+AES, 2048 Bufsize: Audio ok, no Error counter
- 192 kHz, All Channels, 192 Bufsize: Audio ok, no Error counter
- 192 kHz, All Channels, 256 Bufsize: Audio Interruptions, Error counter incr rapidly
- 192 kHz, All Channels, 384 Bufsize: Audio ok, no Error counter
- 192 kHz, All Channels, 512 Bufsize: Audio Outages, clicks, some errors counted (2)
- 192 kHz, All Channels, 1024 Bufsize: Audio Outages, clicks, some errors counted (2)
- 192 kHz, All Channels, 2048 Bufsize: Audio Outages, clicks, some errors counted (2)
- 192 kHz, Analog+AES Channels, 192 Bufsize: Audio ok, no Error counter
- 192 kHz, Analog+AES Channels, 256 Bufsize: Audio ok, no Error counter
- 192 kHz, Analog+AES Channels, 384 Bufsize: Audio ok, no Error counter
- 192 kHz, Analog+AES Channels, 512 Bufsize: Audio ok, no Error counter
- 192 kHz, Analog+AES Channels, 1024 Bufsize: Audio ok, no Error counter
- 192 kHz, Analog+AES Channels, 2048 Bufsize: Some oudio Interruptions, 2 errors counted

When trying the USB driver on the Lenovo (on both ports USB2 and USB3),
Then at certain sample frequencies, i.e. 44.1, the changing of ASIO buffer size sometimes causes Audio to hang.
USBB driver from 11.7.14. Driver 1053. HW 357.

Test procedure (I didn't detail it yet, so here what I did)
- Connected Shure SM57 dny Micro to Input 10
- In Totalmix I mute the input of Input 10 and set the Playback channel to 0dB
  to listen DAW output in the Headphone, to get a clue if audio is fine or not when traversing Firewire/USB
- In Cubase 7.5.20 and 30 (I upgraded this weekend to latest version)
  I hit the Speaker Symbol on the audio track to be able to listen back Micro input from DAW
in the headphone connected to Analog 9/10.

To sum up

I tried 3 different Fw cables on my Windows 7 SP1 PC with the EXSYS firewire card and tested 2 different ports on that card.
I also tested the 3 different Firewire OHCI driver possibilities in Windows 7 (TI, legacy, OHCI generic), no change at all.

I also tested with a Lenovo T540p (brand new) using a SIIG Expresscard also with a firewire chip.
Nearly identical behavior with ony few "subtile" changes, but at the end always problems with 48, 174.4 and 192 kHz.
Sometimes raising the Buffersize helps, sometimes only when limiting Firewire bandwidth.

Also the USB driver has some issues when changing the ASIO Buffersize.
At 44.1 and other sample frequencies it tends to hang the playback audio from DAW when changing between ASIO
Buffersizes.

I am really disappointed. 2 weeks I need now my device at home, then I need to send it to repair.
Then I will be approx 3 weeks without any recording device... :-/

Hi,

well, if it breaks for others I put it also into these words tbh .. but it definitively "feels" different if you are affected on your own and if you have no spare part ...

I checked already with Thomann where I bought and have a 3y warranty and I checked with Synthax where I have a 2y "vendor warranty" (dont know they right word).

Thoman and Synthax can't send me a replacement unit. Also not a loan device. So I have to send it now to Thomann and then it will go for repair to Synthax and no matter which way I go it will last around three weeks...

I would be very glad if RME would jump in here in terms of their expense / replacement or loan device.

Thanks Michael for your feedback.

I personally "fear", that the HW replacement potentially won't bring a change, but I need to try it.

Should the HW replacement/repair not be successful, then I think RME needs to investigate on the driver side ..

Hi guys,

1st of all thanks for all of your feedback. Here some new interesting results...

UPDATE: 15.09.14: the results using the on board VIA chip VT6315N are even worse. 174 and 192kHz are impossible regardless which ASIO buffersizes you choose. Limiting Fw Bandwidth doesn't help. Same problems with 32 and 48 kHz, doesn't work with 48 samples, needs at least 64 samples.
Interesting is here, that the Firewire Connectivity completely hangs when choosing 174 and 192 kHz.
The Fw LED on the UFX turns off and everything hangs a bit. A reboot helps.
Sometimes you can revover by powercycling UFX and de- and re-activating the VIA driver in the Windows Device Manager.
Well this I regard as strange, that the communication between UFX and the VIA completely hangs.
Another not so nice symptom is, that the PC can't shutdown cleanly, even after waiting for 10 minutes, I needed to reset 2 times.

Now some additional interesting results with the EXSYS PCIe Card with TI XIO2200A chip:

I placed my EXSYS FW PCIe card from the 2nd last to the last PCIe socket. This made the situation even worse. 172 and 192kHz are not possible anymore, even not by limiting FW BW in the driver from "All channels" to "Analog and AES", which helped when the same card was in the 2nd last slot.

Then I place the EXSYS card to the last remaining/accessible PCIe Slot, which is a x16 Slot.
32 and 48kHz also only work with ASIO Buffer rates >=64.
But now very interesting ... Also 174 and 192kHz run completely flawlessly even with "All Channels".

The bad thing is now, as you might have expected, that my Graphic card is now limited in terms of PCIe bus bandwidth.
Without Fw card in the Slot with x16 now with only x8 ....

Here a graphic to give you an overview what worked better / worse on the MSI P55A GD65.

What do you think from that ? BIOS settings, Mainboard Problem, RME Driver problem or a combination of it ?

Hi MichaG,

with USB I only have the little issue, that changing ASIO Buffer size sometimes results in a little hang in a way that the pulldown menue of the driver for changing for ASIO buffersize doesnt work anymore.

The workaround for me is to change the Samplefrequency to a different one in Cubase and then back to the one that I wanted to use. Then it works again.

Otherwise USB works with all Samplefrequencies and all&lowest ASIO buffersizes.

Synthax and RME are working on it, I am only doing some test on my own, tyring to find something ...

At the moment I think theoretically it can be "anything". Cables and Firewire Interface I would exclude now as I tested several. I think its either: UFX, Driver or "PC" or any combination ...

I just discovered, that I also have a Lindy PCIe card with the same TI XIO2200A chip.
I made the test and its absolutely the same behaviour.

So with USB all samplefrequencies and all buffersizes work reliably.
But not with Firewire.
And as all thre Cards use the same TI chip and have the same problems I assume that this is driver related.
Card 1: Exsys PCIe on PC
Card 2: Expresscard (SIIG) on Laptop
Card 3: Lindy PCIe on PC

As this Chip is being found on many PCIe cards (occasionally I found out now that I own 3 with this chip)
I think it would give an additional benefit to many users not only me.

Hi

with this card its works better: EXSYS EX-16415, Chip: TI XIO2213BZAY

http://www.amazon.de/dp/B0029M9O72/ref= … 61_TE_item

176 and 192 kHz work absolutely reliable now at any Sample Rates in the -x16 and the -x8 Slot on mainboard.

The same problem as before I have with 32 and 48 kHz and a buffersize of 48.

Matthias, you mentioned LSI ... I would give it a last attempt to buy another new card.
What LSI card / chipset could you recommend ?

Best regards

Hi Matthias, thanks for your comment.

Don't get me wrong ;-) I am very glad, that your recommended card fixes nearly everything, especially with the higher sampling frequencies (176+192kHz), even when taking the initial -x1 PCIe slot (makes me glad now my Graphics card again runs with x16 instead of x8).

I simply wonder and do not understand why 32 and 48 kHz doesnt work with 48 samples on a not loaded idle system if even 192kHz works with 48 samples. Is firewire that tricky ? Or could it be that there are rest issues caused by my mainboard ???

With USB every combination of sample frequency and ASIO buffersize works, thats the reason why I wonder that Firewire has these problems. Up to now Firewire was always superior to me in comparison to USB. More intelligence on the devices, less complexity of the driver. But slowly I get the impression that firewire seems to be extremely complicated and requires much more work to get a stable setup.

If you could enlighten me, what makes it that complicated, I would be very glad, as at the moment I do not understand this.

All that I can think of at the moment is, that most Firewire chips seem to be crap. If I look back how many cards I bought in the last 4 years, among them 3 with this XIO2200A, then I surely bought 8 different cards with TI and VIA chipset (PCI and PCIe).

Ok thanks for the feedback, a statement like this I was hunting for.

And yes ofc you are right at 192kHz its 192 buffers (was a typo) .. but I think you know what I meant, at lowest buffer size according to the samplerate.

Ok thanks, then I am fine by this, simply use 64 at minimum, and then I do not have to think about anything ;-)

Many thanks for the kind help from everybody involved !

So I regard this issue now as being solved for me :-)