SOtM tX-USB Sound Dropouts

[adams1416]

Just installed a SOtM tX-USB card and am experiencing intermittent random sound dropouts. Did not have this issue while using MB USB. Windows 7 64bit, JRiver 17, headless server. Any ideas where to start tracking this issue down?

thanks...

 

 

[ecwl]

Have you tried downloading DPC latency checker to see if there is latency in your system? Perhaps the addition of the card plus additional Windows reconfiguration tipped your system.

 

What DAC do you use? What's the USB power setting of the SOtM tX-USB?

 

[89reksal]

You could try a different USB cable. I had a problem like this (internittently sounded like scratched/dirty vinyl playback) that was solved by switching USB cable.

 

Good luck.

 

Bill

 

[ecwl]

Lasker98's comment reminded me that somebody who switched to SOtM tX-USB noticed that they had to increase their WASAPI hardware buffer size in J River to prevent clicks and pops. Not sure why. Also worth a try.

 

[adams1416]

Yes, had bumped the hardware buffer to 250 milliseconds and was able to play 16/44 without problem. However 24/96 was a no-go.

 

ran DPC and averaging somewhere around 35 microseconds with absolute max of 174....watched this over a 15 minute time frame.

 

running the Sotm at 5v

 

DAC is DACit

 

googled around for documentation on the Sotm card...only able to find conflicting setup options/suggestions

 

Using a very stripped down pc/os...

 

what's the proper setup, jumper wise for this card?

 

thanks so much for all your suggestions!

 

[ecwl]

Since Chris Connaker reviewed your DAC with his CAPSv2, the SOtM card should work properly. And you shouldn't have to increase the buffer to 250ms since Chris usually sets his to 100ms. But then you have a different a CPU/MB.

 

I don't own the card but was reading about it. Now I think I'll likely buy a stock CAPSv2 from Small Green Computer rather than build my own.

 

I'm guessing there must be something interfering with your SOtM card. Maybe BIOS setup issues? Maybe other USB devices? Maybe you need to turn off other USB ports on your motherboard?

 

The only other thing I can think of is to make sure Windows 7 power management is set to Maximum Performance. That may help.

 

[vortecjr]

what do you mean by your, "running the Sotm at 5v"?

 

Jesus R

 

[phofman]

What DAC do you use?

 

[PeterSt]

Lasker98's comment reminded me that somebody who switched to SOtM tX-USB noticed that they had to increase their WASAPI hardware buffer size in J River to prevent clicks and pops

 

At least I said to in the "more original" SOtM thread.

Nothing WASAPI related. It just doesn't behave as a normal USB port and a higher "latency" is needed to avoid the dropouts, which are just measureable hardware errors in my system (which consumes 480mbs).

 

Peter

 

[phofman]

It just doesn't behave as a normal USB port

 

Well, then it would not be what it claims to be ("compliant with USB 2.0") and could be a subject to return. Plus it does not seem to come with its own drivers which means it should comply with OHCI/UHCI/EHCI specifications. How does it differ from other PCI USB controllers?

 

which are just measureable hardware errors in my system (which consumes 480mbs).

 

Sorry, I do not understand what you mean.

 

[PeterSt]

It just doesn't behave as a normal USB port

 

You could interpret this as "thus it is outside standards" but this is not what I'm saying;

USB timing is the most critical at the speed of 480mb/s, when it is about asynchronous operation *and* providing the data in time. So, pump through that 480 is one thing, but to provide it at the desired latency is another. In this SOtM case, the latency has to be 4ms or larger or otherwise the data arrives too late. Whether this means that the inherent speed spec isn't met - don't ask me (but it could be the culprit);

The reactance of the system (think OS) can just as well be the culprit. So, ask each ms for something to be there, but when some task switching takes more to begin with - there you go.

 

Btw, this is the very thing which goes wrong in OS/X today; the timing spec (the service of it) isn't met anymore by the OS.

 

For the SOtM it can just as well be that all needs to go through too much (slow) hardware.

 

which are just measureable hardware errors in my system (which consumes 480mbs).

 

I just meant that when the 480Mb/s is actually used, the lower latency can not be met by the card. At 4ms it starts to work okay.

USB ports do 1ms, which is the spec of service.

 

[phofman]

Well, 480Mbps at 1ms latency, PCI card... this just does not make sense together. Your built-in USB controllers are hooked to PCI-e internal bus in the chipset, IMO much faster than a PCI slot. But vast majority of users will not ever need full 480Mbps at 1ms latency. It is IMO your choice to use such large load.

 

[PeterSt]

And that is was I indirectly tried to say.

Still it will (or may) be so that users notice a difference against a direct USB port.

That is really all.

 

[phofman]

OK, it may not provide 480Mbps at 1ms latency, but it is a regular usb port. Before PCI-e era all your USB2 ports would have this performance. In fact I used such USB2 add-on cards a few years ago and still have a couple of them in the old-stuff box.

 

IMO expecting full 480Mbps performance is not a robust design. It may work for you, but may not for others with weaker gear.

 

[The Computer Audiophile]

I'm using the SOtM card right now with the Alpha USB, JRiver, and WASAPI - Event Style set to 10ms and it works flawlessly.

 

As ecwl said I usually run it at 100ms as that's the default recommended by JRiver, but I've been experimenting a bit lately.

 

The SOtM card has always worked wonderfully in the C.A.P.S. v2.0 server.

 

[adams1416]

5v output...switch set to "On"

 

[vortecjr]

have you tried Event Style set to 10ms per Chris's comments above?

 

Also, take a look at your motherboard's manual and inventory any device you have connected to the motherboard and what ports they connected to. Your looking for two IRQ dependent devices that are in slots that share IRQs. The motherboard's manual should specify which slots share IRQs and usually recommends which slots to use for devices such as audio cards to avoid IRQ issues. You might the option to set the IRQs in the bios or you could consider move components around or removing components with issues......

 

Jesus R

 

[obt_man]

I may not be well proficient in computer technical matters, but I would agree with Jesus - the problem may be caused by interaction between the SOTM card and the motherboard. You should check the interrupt request for your specific PC. As I understand your card should not share its IRQ line with any other hardware. If it does then disable that other hardware in Windows (or remove it completely as Jesus suggested) and see if the card now works as it should be.

 

[JonL]

Just got a tX-USB card, and I'm experiencing some issues playing 192/24 material.

 

I'm using a Linux based system connected to an Ayre Qb-9 dac, and every once in a while there'll be a sound dropout, forcing me to unplug/replug the USB cable to the DAC.

 

This is only happening with 192/24 files. With 44.1/16 mateial everything's fine.

 

Anybody familiar with this kind of situation?

 

Thanks in advance.