Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[HiFiTubes]

This one has me stumped. Thanks for listening and the suggestions.

Installed new router and finally get some antennas to get it to 300Mbps rate and tests show about 27,000Kbps throughput.

I can play a 10,000Kbps MKV w/ 48kHz soundtrack with no problem over LS, but once I try to stream high resolution FLAC (worse at 192 than 96kHz), I get pops and clicks, especially when I hover over MC buttons.

I have tried removing paging files from client. Both master and client have SSDs, and the master is using a USB > Sata adapter. Both machines are Windows 7 x64 with 4GB RAM.

Kind of at a loss of what to try next, other than moving my Addonics box back into the listening room, which I would like to avoid as this setup was to get excess stuff (router, modem, storage enclosure) out of there.

Audio hardware and settings:

Lynx ASIO (also tested WASAPI)
toggled dsp 24bit/32bit etc.
tried 2-20 second pre-buffering
tried toggling play from memory
tried .5-5 second buffer
drives have no fragmentation

MKV - CoreAVC 2.0

I do see that MC has about 5% deferred procedure calls on the cpu usage as opposed to .5% for Foobar which has the same problem, but not as bad. Buffers don't help.

Why is streaming audio a problem whereas video at twice the bandwidth is not? Speculation: possibly something to do with the robust buffer for video and the fact that most audio streams are 44-48kHz, so maybe some lost frames aren't as noticeable?

My cpu usage goes from MC 2% to 20% when I hover over buttons and menus, but I have the newest ION drivers which actually work very well for browsing covers in MC and the web (and 1080P playback). No IRQ conflicts than I can see either, and the system latency (DPC checker) looks fine.

I doubt this is an MC problem as local disk playback sounds great....just stumped.
thanks!

[HiFiTubes]

I have been reading some stuff on the D-Link forums. I think I'll try a Linksys router tonight.

One thought: could this have anything to do with CoreAVC and gpu with MKV. Still strange how I'm using 50% less data and 75% less cpu.

[JimH]

That you have troubles when your mouse hovers in a certain location suggests a hardware issue on the client PC.

What happens if you try a wired mouse, for instance?

Did you try running the benchmark feature under help?

[HiFiTubes]

I did run the Bench and will post it here.

I get intermittent pops & clicks that are exacerbated by gui activity in MC; when I leave MC and do other things like web browsing I just get the intermittent artifacts.

I will also email Zotac tech support and try to replace the router. Local file playback at 192kHz seems solid and I will test again tonight to make sure none of the artifacts which were to be fixed in .48+ "Fixed: ASIO playback for 32-bit integer style cards had a possible overflow (only applies to last few builds)." are gone.

Lynx tech support stated "that change should apply to our cards - sounds worthwhile".

thanks

[Matt]

Does the Lynx offer a hardware buffer size setting in its control panel?  If so, increase it.

Lots of cards default to something like 256 samples, and it's not really enough on a slower machine with a huge sample rate. (higher sample rates mean a fixed number of samples last less time)

[HiFiTubes]

Thanks Matt and Jim. Lynx has a type 18 buffer set which equals 1024, and it is set to double buffer.

I have figured out quite a bit just now, and I would love to hear your thoughts on this.

Fact 1

There is enough bandwidth for uncorrupted high resolution audio (e.g. 5000kbps).

Evidence

Playing the same file back from the client SSD to master SSD results in perfect playback

Fact 2

It is not audio hardware or playback software related.

Evidence

I then took the EMU 0202 to the client and re-created the same dropouts, albeit they were silent dropouts, and not digital clicks/scratches; large puffy gaps in playback.

Appendix

Here's where it gets interesting. The master is connected by wire to the D-Link 825, and the client via an Intel 5300 wi-fi minin-PCI-E card. Connection of this 5gHz n channel is 300Mbps.

What I then did was to put both PCs on the G-band, and the result was the same (good one way>back to master, bad the other>to the client.... with even less bandwidth), EXCEPT that the playback and artifacts to the client when the EMU 0202 was brought over, changed to match the type of distortion I was hearing when the master had been previously hardwired.

 ???What I'm wondering is if this is OS, motherboard chipset, or router related. Would the next step be a re-install of Windows 7 on the client, another router, or RMA the Zotac board on the client.

Now I'm in a bit over my head. I do have another computer I could connect which can only be hard-wired to the router. Then, I could test with that one playing to and from the other two one wireless vs. wire.

The only other thing I can think of is that when I had FIOS I used a utility to "optimize" my system" Anyone know a good tool to reset this, or if that's even a possable cause of this problem, which seems to be in steadily receiving streaming data.

[HiFiTubes]

I forgot to mention one thing.

When I run audio on the Lynx card on the client, I see about 3% cpu usage from deferred procedure calls. This is on the ATOm 330 1.6gHz dual-core.

When I run the same 192kHz file on the master with EMU 0202, I see about to 50% cpu usage as DPC........ BUT NO DROPOUTS IN AUDIO. This PC has a 2.4 dual AMD cpu.

This DPC usage only shows up in Process Explorer and only seems to occur when MC uses Library Server.

[Matt]

It kind of sounds like your wireless network is swamping your computer (shown as DPC CPU usage) pushing that much data.

Could you run a wire?

[HiFiTubes]

I just talked with a few folks here in networking. The plan is to try the last firmware as I'm getting 3MB/s with a 300Mbps connection at 91% signal strength. Seems there may be a problem with the current version for the DIR-825. One guy said he had an old enterprise router that does a solid 11Mb/s whereas stuff like the consumer routers have a big rate but no throughput.

If that doesn't work I will open this Linksys E3000 and try that.

Final plan would be to sell all the wi-fi I just bought, and run a ** wire.

[HiFiTubes]

Okay, I did some testing with a direct connection and now have 700Mbps (93MB/s) wired transfer rate vs. 27Mbps transfer rate.

I also hooked up my laptop to wireless N but at 144Mbps rate (throughput is more like 11MB/s) and can stream 192kHz audio to it. I'm curious if audio on master library PCs' mapped drives is handled differently by the client depending on whether "play back local file" is checked or not. I have tried both and it seems to buffer just slightly when I play through LS.

Matt has mentioned that JR uses a sophisticated video buffer for url loading video files and I can't see why I can play 10,000kbps audio/video but not a 5,000kbps audio stream. It just seems that the buffer is not as robust when pushing larger audio-based data streams.

Good news is the problem must be on the either the client OS or wi-fi card as it consistently gets only 4-5MB/s transfer and this is somehow too little, why I'm not sure. It's not like a dropout here and there; a lot of buffer overruns.

I can stream 192kHz to the laptop on the 2.4gHz N-network (144Mbps) and the 5gHz N-network (245Mbps) - and the wired client, but not the the client when on wifi at 300Mbps...go figure.

Bad news is that all 3 PCs, and 3 sound cards cause glitches to high bitrate audio playback. I tested local file playback for this, not library server; 2 PCs have SSDs. It's hard to reproduce but all three machines did it using Lynx AES-15 PCI-Express, onboard soundmax (192kHz capable), and the EMU 0404 USB. WASAPI was the best but not perfect.

I could not hear glitches with low bitrate mp3, or FLAC, but at 96kHz (native) 192kHz (native)

There are test 192kHz files online for free which I can provide links to.

This was running .58 on all versions.

[HiFiTubes]

INCREDIBLE!

I re-installed Windows 7.

While grabbing drivers on my mapped drive, I noticed the DPC Latency check tool.

When copying files from the server I had noticed my mouse getting "stuck", and the progress bar gui was locking up.

System latency is through the ROOF, in the red.

So, I copied over a 192kHz file quickly, and disabled the wifi device. A brand new Intel 5300, with 2nd newest driver (wanted to test this one first).

Then I copied and pasted this file a number of times until I had a quick 2GB chunk to copy to the local SSD OS drive.

Guess what, it barely spiked into the yellow, and DPC tool reported the same as when it stays in the green.

So this problem is semi-solved as with the ethernet device enabled during this test means I can run a wire. I hope this test is valid at least.

Maybe a glitch with Intel < > Nvidia ION....who knows.

The new install did provide about 8MB/s transfer but it completely frags the system

[HiFiTubes]

Intel needs to get their act together.

http://communities.intel.com/message/94291#94291

[Matt]

Glad you got it figured out.

It's not fun running the wire, but if the computer doesn't have to move, it's pretty hard to beat the speed and reliability it offers.

I suppose you could also add a third-party wireless card to see if you have better luck.  Often cheaper / built-in hardware pushes lots of the processing to the driver / CPU.  This isn't always a problem, but it sounds like it is in this case.

[HiFiTubes]

Thanks Matt. Shouldn't be too bad to run the wire; we just moved to an apt. so it's doable but not great.

Funny thing is, the card that came with the Zotac board didn't work well at all, so I bought a new Intel 5300...top of the line...piece of junk.

Maybe I should put the old card back in and see how it works.

Glad you got it figured out.

It's not fun running the wire, but if the computer doesn't have to move, it's pretty hard to beat the speed and reliability it offers.

I suppose you could also add a third-party wireless card to see if you have better luck.  Often cheaper / built-in hardware pushes lots of the processing to the driver / CPU.  This isn't always a problem, but it sounds like it is in this case.

[HiFiTubes]

Plot thickens. I added a Cisco USB draft-n adapter, AE1000, and I have the same problem, but not as bad. I can now hear only subtle but constant digital artifacts. The DPC tool is half in the red as opposed to max red with the Intel 5300.

Things are pointing at the motherboard. Matt, I know you are well-versed in this stuff so what do you think about the fact that my master desktop was showing 40-50% cpu as DPCs and no skipping, but my client never shows more than 3%?

From DPC Site:

Background information: Why drop-outs occur
 
Processing of streaming data in real-time is a very challenging task for Windows based applications and device drivers. This is because by design Windows is not a real-time operating system. There is no guarantee that certain (periodic) actions can be executed in a timely manner.
 
Audio or video data streams transferred from or to an external device are typically handled by a kernel-mode device driver. Data processing in such device drivers is interrupt-driven. Typically, the external hardware periodically issues interrupts to request the driver to transfer the next block of data. In Windows NT based systems (Windows 2000 and better) there is a specific interrupt handling mechanism. A device driver cannot process data immediately in its interrupt routine. It has to schedule a Deferred Procedure Call (DPC) which basically is a callback routine that will be called by the operating system as soon as possible. Any data transfer performed by the device driver takes place in the context of this callback routine, named DPC for short.
 
The operating system maintains DPCs scheduled by device drivers in a queue. There is one DPC queue per CPU available in the system. At certain points the kernel checks the DPC queue and if no interrupt is to be processed and no DPC is currently running the first DPC will be un-queued and executed. DPC queue processing happens before the dispatcher selects a thread and assigns the CPU to it. So, a Deferred Procedure Call has a higher priority than any thread in the system.
 
Note that the Deferred Procedure Call concept exists in kernel mode only. Any user-mode code (Windows applications) runs in the context of a thread. Threads are managed and scheduled for execution by the dispatcher.
 
While there is a pre-emptive multitasking for threads, DPCs are executed sequentially according to the first in, first out nature of a DPC queue. Thus, a sort of cooperative multitasking scheme exists for Deferred Procedure Calls. If any DPC runs for an excessive amount of time then other DPCs will be delayed by that amount of time. Consequently, the latency of a particular DPC is defined as the sum of the execution time of all DPCs queued in front of that DPC. In order to achieve reasonable DPC latencies, in the Windows Device Driver Kit (DDK) documentation Microsoft recommends to return from a DPC routine as quick as possible. Any lengthy operation and specifically loops that wait for a hardware state change (polling) are strongly discouraged.
 
Unfortunately, many existing device drivers do not conform to this advice. Such drivers spend an excessive amount of time in their DPC routines, causing an exceptional large latency for any other driver's DPCs. For a device driver that handles data streams in real-time it is crucial that a DPC scheduled from its interrupt routine is executed before the hardware issues the next interrupt. If the DPC is delayed and runs after the next interrupt occurred, typically a hardware buffer overrun occurs and the flow of data is interrupted. A drop-out occurs.

Glad you got it figured out.

It's not fun running the wire, but if the computer doesn't have to move, it's pretty hard to beat the speed and reliability it offers.

I suppose you could also add a third-party wireless card to see if you have better luck.  Often cheaper / built-in hardware pushes lots of the processing to the driver / CPU.  This isn't always a problem, but it sounds like it is in this case.

[newsposter]

Other than wishful thinking, I'm not seeing any real evidence to support the 'facts' you posted.

Nor do I see any troubleshooting of the kind usually associated with 802.11 interference/noise problems.

Presumptive judgments like that only get in the way of troubleshooting.

[HiFiTubes]

I posted empirical observations, not 'facts'. You posted opinions about my methodology.

Should I have presumed you had a suggestion? If I had made a judgement, I wouldn't still be posting.

Thanks again though.

[newsposter]

I refer you to your post #5 in this thread and the repeated use of the word 'fact'.  I see no facts in evidence.

Have it your own way.

[HiFiTubes]

I would maybe suggest the word proposition, but actually, I think those two are pretty well substantiated facts.

You are welcome to offer any insight as to why they are not, or you can keep amusing me.

I isolated the problem to one machine by playing the same file back from the client to the master with no corruption, among other tests.

In the end, the system latency issue (it was not the Lynx card - audio hardware, and it was not MC - the playback software) on the client was culprit. It was not network bandwidth related.

[JimH]

I've trimmed a couple of remarks.

Hifitubes, can you summarize whether you fixed the problem and what you think the fix was?

Thanks.

[HiFiTubes]

My friend emailed:

Yeah that's pretty normal. Although I would prefer to use the term "jitter" rather than "latency". It's timing variation which is involved here, not the timing itself. For reasons I do not completely understand, virtually all wireless adapters are murderously hard on interrupt responses, and can/will tie down the system for dozens of ms at a time.

There are a couple other options you might consider. The first is to use a wireless access point instead of a hardline all the way through, so that eg you have a cable to the WAP, and the WAP connects to your router as usual. This basically outsources the wifi to an external device. The second is that, depending on the details of your specific system, you might be able to avoid buffer underruns through a change in audio API (ie using Kernel Streaming or DirectSound instead of ASIO) or through registry hacks (I was able to jack my 1394 buffer sizes high enough for my GO46 that the wireless jitter ceased to be an issue).

[HiFiTubes]

I would Jim, except I'm not done making observations, then I leave it to others who know more than I do about these matters, to draw their own conclusions. If they want to post those conclusions here for the benefit of all MC users, so be it.

When I was getting dropouts playing from my wired server, I simply played back the same 192kHz file from the client to the Master with zero dropouts, and zero "jitter" on the master.

Testing with my laptop, it seems that specific PCs are affected in unique ways. My 2-3 year old Lenovo laptop has DPC "jitter" spikes every 10 seconds all the time. Stays the same streaming 192kHz to it.

The PCs that show more DPCs as cpu usage (using Process Explorer) have less jitter. the laptop spikes to 6%, the server to 40-50% (and never gets in the yellow), and the new PC with ION chipset and 330R ATOM dual-core is the worst. It has a Lynx AES16-E card and shows about 3% cpu as DPCs. This PC gets nasty spikes when I do anything with the gpu whereas I previously reported it was just nailed all the time with spikes when receiving data over wifi.

I'm now on the 2.4gHz of my network with the client and I swear the jitter has lessened on the client; I need to experiment more as I was exhausted laying on the living room floor with headphones staring blurry at the DPC checker tool, in disbelief, after weeks of troubleshooting.

The easiest thing would be to run a ** wire, as the WAP is just more cash I'm leery of spending. I already have a router and usb nic in the car for return to Target (they don't have a re-stocking fee like Office Depot/Staples which is nice).

Tried DirectSound, it DOES seem to have less jitter when used on the client vs. ASIO > Lynx. I am trying ASIO4ALL on my laptop along with WASAPI and jitter is the same, smooth playback even with those spikes into the red every 10 seconds on the dime.

I will provide screenshots of each PC receiving a 192kHz audio stream, DPC Check Tool and playback devices/protocol.

[HiFiTubes]

I'm now testing on the 2.4gHz band at 54Mbps.

Playback of a 192kHz over LS to the client. Lynx ASIO. Using USB remote to move up and down through album tiles with built thumbnails.




Playback of a 192kHz over LS to the client. WASAPI to Lynx Speakers. Using USB remote to move up and down through album tiles with built thumbnails.

[JimH]

WASAPI is the best choice if it works, but if you're using the Linx ASIO driver and having trouble, you could try ASIO4ALL.

So, to summarize, WASAPI seems to work, ASIO does not.

And it works in one direction but not in the other.  Correct?

FYI, the term "master" isn't clear.  I believe you mean "server".

[HiFiTubes]

ASIO4ALL didn't work with the Lynx last time I checked, but I can try again. WASAPI seems to result in the lowest system latency. However, I have observed a seperate issue which is either a Lynx or MC bug.

WASAPI playback to "Lynx Speakers" via AES/EBU works for all sample rates except 192kHz, in that 192 is routed not to all mixer strips (it is with all other sample rates), but just to strips 1 and 9 which means I have no way to adjust or monitor playback.

Lynx Speakers work fine via USB to my external DAC with 192kHz, but the same 192kHz file is not routed properly when I use WASAPI to connect to Lynx Speakers for AES/EBU connection.

- The card and external DAC all work properly at 192kHz with MC, just routed in a different way (by MC?) to only a few Lynx mixer strips, none of which I can use. -

Guess it could be a Lynx issue but strange that up to 96kHz works fine in MC (they have been emailed regardless).

FWIW, WASAPI provides some nice low system latency performance and I'd like to keep using it.

Everything set to Exclusive.

[JimH]

WASAPI playback to "Lynx Speakers" via AES/EBU works for all sample rates except 192kHz, in that 192 is routed not to all mixer strips (it is with all other sample rates), but just to strips 1 and 9 which means I have no way to adjust or monitor playback.

What is AES/EBU?  If it's external hardware and everything else works, then the problem is outside the PC.  MC only knows that it's talking to WASAPI.  It doesn't know about anything beyond.

Double check your DSP settings and make sure everything is off.

[Vincent Kars]

AES/EBU is the standard for connecting devices digital in the pro-world.
SPDIF has been derived from it (standard for consumer use)
AES/EBU is balanced 3-conductor, 110-ohm twisted pair cabling with an XLR connector
SPDIF is single 2-conductor, 75-ohm coaxial cable with an RCA connector

http://en.wikipedia.org/wiki/AES/EBU

[JimH]

Thanks.

[HiFiTubes]

Well my point was that it is like changing from DirectSound to Wave output and suddenly a certain sample rate doesn't work even though the device supports it.

Not saying it is MC, it seems like a Windows/Lynx driver compatibility issue since I can use MC + WASAPI + USB DAC but not MC + WASAPI + LYNX PCI-E AES/EBU card.

If I send Windows Test tones at 192kHz they are routed to only certain Lynx mixer strips. This also occurs at 176kHz.

These sample rates playback fine with Lynx and external hardware, it's just the routing that is an issue.

Kernel Streaming options in MC show Lynx 1+2, 3+4, 5+6, and 7+8. WASAPI shows all but 1+2 strangely.

I'll wait to hear from Lynx as to why the driver is routing the audio to these strips with only certain sample rates.

I'm using single wire mode with an auto-sample rate change option on the Lynx; all DSP off in MC.

[HiFiTubes]

So we have seen how ASIO, at least Lynx ASIO, doesn't seem to play nice with incoming data over wifi. Local file playback at 192kHz is okay via ASIO, but I did uncover a bug in .57.

I rolled back to .35 and it's gone.

Oh, and I just decided to run a wire to avoid any more issues with wifi. A nice hard fact that let me drill through two walls today.

I'll report the bug.