Horrendous latency

Hi all
Im getting massive latency in world of warcraft and have been for some time.At times this makes the game completly unplayable.It appears to get better during off peak hours(after around 1 am)but even then im suffering disconnects.
I came across the following thread that appears to be the exact same cause as my issue here.http://community.bt.com/t5/BB-in-Home/World-of-Warcraft-high-latency/m-p/39323
I never used to suffer with connection problems until the latest expansion was released for wow around october.From what i've read on both the wow forums and the forums here it would appear that wow has changed the way the game communicates with the wow servers.Thay have apparently moved this to p2p in order to try and lighten thier loads i would assume.This would appear then to be picked up by bt as p2p traffic and then appears to be restricted and slowed.It seems that neither party here wants to accept responsibility for resolving the issue.Blizzard say it is the fault of the isp and from what i've read here it looks like BT dont want to accept responsibility either
I took a speed test from speedtest.net this evening when suffering from an in game latency of around 3k and my speed test showed i had a 15meg connection.When running a trace to the wow servers i dont have any indvidual response times from any node above 55ms.Most are below 30ms
I would like to point the following thread and statements from virgin media in BT's direction
http://community.virginmedia.com/t5/Broadband-down-your-phone-line/World-of-Warcraft-Issues-Updated-... .Is there any plans on BT's behalf to look into this issue and resolve it like VM have?
Having phoned tech support india regarding this matter numerous times only to have some one who speaks to me nicely but seems to have absoultly no idea what im talking about is frustrating to say the least.The ammount of times i've been told it is either my computer or there is nothing they could do is unreal.Tech support have now agreed to try turning my interleeving off after informing me it was turned on which somewhat surprised me as i thought it was off at my request from a few years ago.In order to actually get someone from tech support india to look at this and take it seriously has been nothing short of a mare.
I cant for the life of me fathom why im still with bt.They continually seem to ignore what customers are saying about one of the most fundamental parts of thier service(support).I've had the unfortunate luck of having to deal with them on numerous occasions since joining bt around 5 years ago.I personally have made several complaints and seen a lot of complaints posted here regarding them.It really appears to me that bt's customers view tech support india as a complete joke.What i find even more astouding is that BT dont appear to care at the perception it's customer base have of them.Tech suppot in my opinoin was a mare when i joined BT 5 years ago and nothing has improved.It still takes a lot of jumoing through hoops and getting angry to the point where only a manager will do to get somebody to even take issues seriously.
When are BT going to learn that support and how it is handled MATTERS!!
Sorry for my little rant at the end there but im a little peeved at having paid a subscription for bband and a game that i cant use very frustrating.Espically as it is the main reason i have bband

2 Gigs of RAM isn't really a lot for your system. Could be a potential source of your slowdown.
Using plugs with inherent latency while recording isn't a good idea (especially on busses or outputs) unless you have plugin comp turned on. But still, when tracking, it's not an idea situation. Instead, you should freeze whatever tracks absolutely have to have the sound of your plugs and that will free up computer resources.
Depending on what you're doing, you should be able to get away with a buffer size of 128 or maybe even 64. You might also have to experiment with the size of the process buffer and so on.
Anyway you slice it, though, if you're trying to use the computer alone for recording and monitoring the overdubs live, you're going to experience some latency.

Similar Messages

TTL signal vs TCP-IP, parctical and timing considerations

We have just purchased a BioPac MP1 50 physiological recording system (www.biopac.com). We would like to start/stop an acquisition from another computer system and/or to add annotations and markers.
To this end it seems there are two routes to consider. We could either use the built-in Trigger in/out capability with TTL signal of (0 and +5V square pulse) or use TCP-IP client-server to control it remotely (i.e. using VIs such as TCP-IP Listen). In the later case, I�d use the Beta LabView API libraries that BioPac is about to release for the MP150, instead of the dedicated AcqKnowledge 3.8.1 software, which is really good.
Because we need to correlate event during the physiological recording of our experim
ent, it would be ideal if the resolution were of ms accuracy (i.e. latency less than 1ms) and we need to manage up to 16 trigger channels.
I have very little technical background knowledge on this. Thus, in order to help me evaluate a solution, I would appreciate any comments and suggestions.
1) I would like to know first if anyone could recommend an easy solution to generate TTL signal (0 � 5V logical pulse) on both Windows and LINUX PC?
For instance I read about using the 25-pin parallel port, but I am curious to learn about other possible alternative such as USB, USB2 with or without adapter but also a very cheap card (a couple $100 max). I am already ruling out serial connection, because I am told it is very slow and has horrendous latency.
2) What are the latencies in read and writing/issuing TTL signals com? How does it compare with a dedicated byte stream through TCP-IP, on a dedicated cable and on a network cable?
3) Are they any VI application that you c
ould share to show how LabView 7.0 can talk through the respective ports to generate a pulse forming the trigger information being written or read in?
I look forward to hearing your feedback and suggestions. Many thanks in advance.
Donat-Pierre LUIGI

Use TTL. It is likely that the TCP/IP messages will get there fast enough
and that the software will respond in a timely manner but there is no way to
be sure. It is the fastest way to get from your LV application to your
other device. You may need to check the response time that the BioPac will
give to the TTL input verses a TCP/IP message.
You should also consider the level of programming needed to accomplish your
tasks. I would strongly suggest that you get a seasoned LV programmer on
the job or you will be wasting a lot of time and enduring needless
frustration.
The parallel port will respond is sub-millisecond. You should be able to
toggle it several hundred times in a millisecond. I've had LV applications
use the printer port for this type of communications before. I don't
remember the bandwidth but it's more than adequate for this application.
TCP/IP will sometimes get delayed by the OS (either Windows or Linux) due to
other things that are happening at the time which you don't have control of.
The message should go out in very short order (again sub-millisecond) but
there is no control over this.
Good luck,
Chuck
"Donat-Pierre" wrote in message
news:[email protected]...
We have just purchased a BioPac MP1 50 physiological recording system
(www.biopac.com). We would like to start/stop an acquisition from
another computer system and/or to add annotations and markers.
To this end it seems there are two routes to consider. We could
either use the built-in Trigger in/out capability with TTL signal of
(0 and +5V square pulse) or use TCP-IP client-server to control it
remotely (i.e. using VIs such as TCP-IP Listen). In the later case,
I'd use the Beta LabView API libraries that BioPac is about to release
for the MP150, instead of the dedicated AcqKnowledge 3.8.1 software,
which is really good.
Because we need to correlate event during the physiological recording
of our experiment, it would be ideal if the resolution were of ms
accuracy (i.e. latency less than 1ms) and we need to manage up to 16
trigger channels.
I have very little technical background knowledge on this. Thus, in
order to help me evaluate a solution, I would appreciate any comments
and suggestions.
1) I would like to know first if anyone could recommend an easy
solution to generate TTL signal (0 - 5V logical pulse) on both Windows
and LINUX PC?
For instance I read about using the 25-pin parallel port, but I am
curious to learn about other possible alternative such as USB, USB2
with or without adapter but also a very cheap card (a couple $100
max). I am already ruling out serial connection, because I am told it
is very slow and has horrendous latency.
2) What are the latencies in read and writing/issuing TTL signals
com? How does it compare with a dedicated byte stream through TCP-IP,
on a dedicated cable and on a network cable?
3) Are they any VI application that you could share to show how
LabView 7.0 can talk through the respective ports to generate a pulse
forming the trigger information being written or read in?
I look forward to hearing your feedback and suggestions. Many thanks
in advance.
Donat-Pierre LUIGI

IOS-XRv and HSRP: Supported?

Hey gang -
I'm building a virtual lab within a KVM hypervisor, and it includes 2 XRv images tied together across a VM switch image (Arista vEOS, but that's unimportant). The L2 connectivity is clearly there between the two routers:
RP/0/0/CPU0:r2#show cdp neighbors gigabitEthernet 0/0/0/6
Fri Apr 17 10:49:07.505 UTC
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater
Device ID       Local Intrfce    Holdtme Capability Platform Port ID
r1    Gi0/0/0/6        149     R          IOS XRv S Gi0/0/0/6
And HSRP is able to sync up appropriately between the two of them:
RP/0/0/CPU0:r2#show hsrp br
Fri Apr 17 10:46:32.806 UTC
IPv4 Groups:
                        P indicates configured to preempt.
                        |
Interface      Grp Pri P State   Active addr     Standby addr   Group addr
Gi0/0/0/6         1 100 P Standby 172.17.0.242    local          172.17.0.241
IPv6 Groups:
However, r2 (the secondary) can't ping the HSRP IP at all. It can ping the buddy router's IP address, but not the HSRP one:
RP/0/0/CPU0:r2#ping 172.17.0.242
Fri Apr 17 10:51:30.635 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.0.242, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/17/19 ms
RP/0/0/CPU0:r2#ping 172.17.0.241
Fri Apr 17 10:51:32.595 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.0.241, timeout is 2 seconds:
Success rate is 0 percent (0/5)
The primary router can ping the HSRP IP though:
RP/0/0/CPU0:r1#ping 172.17.0.241
Fri Apr 17 11:32:32.679 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.0.241, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Further, the switch VM that the two XRv routers are connected to can ping both of their IPs on Gig0/0/0/6, but can't ping the HSRP IP:
#ping 172.17.0.242
PING 172.17.0.242 (172.17.0.242) 72(100) bytes of data.
80 bytes from 172.17.0.242: icmp_req=1 ttl=255 time=17.0 ms
80 bytes from 172.17.0.242: icmp_req=2 ttl=255 time=19.0 ms
80 bytes from 172.17.0.242: icmp_req=3 ttl=255 time=21.8 ms
80 bytes from 172.17.0.242: icmp_req=4 ttl=255 time=22.6 ms
80 bytes from 172.17.0.242: icmp_req=5 ttl=255 time=23.3 ms
--- 172.17.0.242 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 71ms
rtt min/avg/max/mdev = 17.024/20.790/23.366/2.406 ms, pipe 2, ipg/ewma 17.794/19.066 ms
#ping 172.17.0.243
PING 172.17.0.243 (172.17.0.243) 72(100) bytes of data.
80 bytes from 172.17.0.243: icmp_req=1 ttl=255 time=17.2 ms
80 bytes from 172.17.0.243: icmp_req=2 ttl=255 time=19.4 ms
80 bytes from 172.17.0.243: icmp_req=3 ttl=255 time=21.4 ms
80 bytes from 172.17.0.243: icmp_req=4 ttl=255 time=22.1 ms
80 bytes from 172.17.0.243: icmp_req=5 ttl=255 time=23.1 ms
--- 172.17.0.243 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 71ms
rtt min/avg/max/mdev = 17.266/20.684/23.157/2.100 ms, pipe 2, ipg/ewma 17.758/19.114 ms
fn1.vpn#ping 172.17.0.241
PING 172.17.0.241 (172.17.0.241) 72(100) bytes of data.
--- 172.17.0.241 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4008ms
(Pay no mind to the horrendous latency; it's due to the way Arista wrote the VM).
So after all of that: should I expect HSRP to be fully supported with XRv? Or, like the L2 interfaces that are fully configurable, is it something that isn't supported? Did I, perhaps, forget to enable some bit within the XRv's config?
Thanks!

In order to get redundancy to run between two SLB switches, you need to configure HSRP between the two VLAN interfaces and then associate the standby name with the Cisco IOS SLB Virtual Server (Vserver). When using IOS SLB in an HSRP environment ensure that the active HSRP router (also active for IOS SLB) is receiving the return traffic for the IOS SLB connections.

Complete Drop Out when online gaming

Recently I have managed to convince my landlord of weekday digs (I work away all week) to sign up for infinity, after having this installed to great effect at my own home residence some months back.
I play an online racing game which uses ports 6654 & 6655 which are configured through the router to allow gaming to be played online with others.
Latency or lag has always been an issue for some users of this game with poor connections, (me included) but when we switched from cable Virgin to Infinity here, i hoped my latency issues would be resolved. Not so, its even worse. Worse to the point where I DC from the game completely, or suffer horrendous latency.
I do run wireless, and the situation is better when hard wired through LAN, but when at home I never experience problems of this magnitude.
I am only 10ft away from router & modem when wireless, with no other users connected when i get the problem.
I have run a Tracert Ping check, and the final 'hops' are above 110...not a good sign.
Upload and download speeds are great and as they should be for this service.
I can not see a DSL filter fitter, but assume its pre-fitted in the juntion box?
Any ideas on this would be most appreciated as its runing my gaming experience, of which I moderate but can not even play!

What are the first couple of tracert hops? They should give an idea of latency due to ping (first hop high; should be <1ms on a wired connection) and latency due to interleaving (second hop significantly higher than first hop, should be around 6ms without interleaving, mine is aroung 15ms with interleaving).
If the remaining hops are high, that is BT routing. I have silly Winchester-London routing via Sheffield that adds and extra 9/10ms with the hop norht and the hop south.
Even with interleaving and routing I still get 29ms typical to BBC. Your talk of 100 sounds horrendous.

Latency using Screen Share

I am experimenting with Screen Share in Lion (did not use in SL) and am having latency issues. MacBook taking control of iMac i7 quad core not too bad but iMac i7 Quad Core controlling MacBook is horrendous. Any ideas to speed things up?
Also trying to connect either way using "Apple ID" not working, only will connect using "Registered User" any thing to help out here would be great. Thanks

Just updated to 10.7.1 and all seems to be working great!

Zoom H4 Latency

Hi - does anyone use the Zoom H4 with GarageBand?
I'm a GB newbie and was getting on well with it until I tried recording using the Zoom H4 as an audio interface.
The latency is horrendous - even though I've set GB to optimise latency (small buffer setting).
Has anyone used the H4 wih GB successfully? ( don't want to buy another audio interface if I can possibly help it!)

Now why didn't I think of that?
Yep, using the Zoom just as a mic into the Apple's line-in works fine - no delay.
Many thanks.

Latency issue in Desktop Sharing

We are planning to develop a conferencing solution using LCCS. I am trying to evaluate the screen/desktop-sharing application. I am experiencing 5-10 seconds latency during the transfer of the screen data to the other end.
I am using the demo application(ScreenShareSubscriber and ScreenSharePublisher), provided in the SDK.
Some more details:
- Current OS is Windows 7 (32 bit).
- I am behind a proxy.
- I am running the applications in India.
- Using Flex builder 4.6 with Flash player 11.1.
- Using the developer account to test the application.
Questions:
- Can the delay be reduced programatically? If yes, then how?
- The final solution may be used by people distributed across the globe. Is there a possibility that, the latency is affected by your location?
- If the above is true, does Adobe provide cloud services (for commercial applications) that are distributed in different location, to reduce the latency?
- Can proxy server be an issue? We have port 443 open on the proxy server for TSL connections.
- If the above is true, then how can we avoid the issue? The final application may be used in a corporate network and we cannot ask everyone to change their network settings to connect LCCS services.
I have checked some posts on the forum, which say that, the performance is faster on Macs. We are currently not targetting the Mac platform.
Thanks,
Subrat

Hi,
Please double check the following firewall port between two subnets.
Front End Servers-Lync Server Application Sharing service 5065 TCP used for incoming SIP listening requests for application sharing.
Front End Servers-Lync Server Application Sharing service 49152-65535 TCP Media port range used for application sharing.
Clients 1024-65535* TCP Application sharing.
If the issue persists, you can use the Lync server logging tool on FE server to test the process of desktop sharing.
Here is the link of using the Lync logging tool:
http://blog.schertz.name/2011/06/using-the-lync-logging-tool/
Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make
sure that you completely understand the risk before retrieving any suggestions from the above link.
Best Regards,
Eason Huang
Eason Huang
TechNet Community Support

A quick primer on audio drivers, devices, and latency

This information has come from Durin, Adobe staffer:
Hi everyone,
A common question that comes up in these forums over and over has to do with recording latency, audio drivers, and device formats. I'm going to provide a brief overview of the different types of devices, how they interface with the computer and Audition, and steps to maximize performance and minimize the latency inherent in computer audio.
First, a few definitions:
Monitoring: listening to existing audio while simultaneously recording new audio.
Sample: The value of each individual bit of audio digitized by the audio device. Typically, the audio device measures the incoming signal 44,100 or 48,000 times every second.
Buffer Size: The "bucket" where samples are placed before being passed to the destination. An audio application will collect a buffers-worth of samples before feeding it to the audio device for playback. An audio device will collect a buffers-worth of samples before feeding it to the audio device when recording. Buffers are typically measured in Samples (command values being 64, 128, 512, 1024, 2048...) or milliseconds which is simply a calculation based on the device sample rate and buffer size.
Latency: The time span that occurs between providing an input signal into an audio device (through a microphone, keyboard, guitar input, etc) and when each buffers-worth of that signal is provided to the audio application. It also refers to the other direction, where the output audio signal is sent from the audio application to the audio device for playback. When recording while monitoring, the overall perceived latency can often be double the device buffer size.
ASIO, MME, CoreAudio: These are audio driver models, which simply specify the manner in which an audio application and audio device communicate. Apple Mac systems use CoreAudio almost exclusively which provides for low buffer sizes and the ability to mix and match different devices (called an Aggregate Device.) MME and ASIO are mostly Windows-exclusive driver models, and provide different methods of communicating between application and device. MME drivers allow the operating system itself to act as a go-between and are generally slower as they rely upon higher buffer sizes and have to pass through multiple processes on the computer before being sent to the audio device. ASIO drivers provide an audio application direct communication with the hardware, bypassing the operating system. This allows for much lower latency while being limited in an applications ability to access multiple devices simultaneously, or share a device channel with another application.
Dropouts: Missing audio data as a result of being unable to process an audio stream fast enough to keep up with the buffer size. Generally, dropouts occur when an audio application cannot process effects and mix tracks together quickly enough to fill the device buffer, or when the audio device is trying to send audio data to the application more quickly than it can handle it. (Remember when Lucy and Ethel were working at the chocolate factory and the machine sped up to the point where they were dropping chocolates all over the place? Pretend the chocolates were samples, Lucy and Ethel were the audio application, and the chocolate machine is the audio device/driver, and you'll have a pretty good visualization of how this works.)
Typically, latency is not a problem if you're simply playing back existing audio (you might experience a very slight delay between pressing PLAY and when audio is heard through your speakers) or recording to disk without monitoring existing audio tracks since precise timing is not crucial in these conditions. However, when trying to play along with a drum track, or sing a harmony to an existing track, or overdub narration to a video, latency becomes a factor since our ears are far more sensitive to timing issues than our other senses.   If a bass guitar track is not precisely aligned with the drums, it quickly sounds sloppy. Therefore, we need to attempt to reduce latency as much as possible for these situations. If we simply set our Buffer Size parameter as low as it will go, we're likely to experience dropouts - especially if we have some tracks configured with audio effects which require additional processing and contribute their own latency to the chain. Dropouts are annoying but not destructive during playback, but if dropouts occur on the recording stream, it means you're losing data and your recording will never sound right - the data is simply lost.   Obviously, this is not good.
Latency under 40ms is generally considered within the range of reasonable for recording. Some folks can hear even this and it affects their ability to play, but most people find this unnoticeable or tolerable. We can calculate our approximate desired buffer size with this formula:
(Sample per second / 1000) * Desired Latency
So, if we are recording at 44,100 Hz and we are aiming for 20ms latency:   44100 / 1000 * 20 = 882 samples. Most audio devices do not allow arbitrary buffer sizes but offer an array of choices, so we would select the closest option. The device I'm using right now offers 512 and 1024 samples as the closest available buffer sizes, so I would select 512 first and see how this performs. If my session has a lot of tracks and/or several effects, I might need to bump this up to 1024 if I experience dropouts.
Now that we hopefully have a pretty firm understanding of what constitutes latency and under what circumstances it is undesirable, let's take a look at how we can reduce it for our needs. You may find that you continue to experience dropouts at a buffer size of 1024 but that raising it to larger options introduces too much latency for your needs. So we need to determine what we can do to reduce our overhead in order to have quality playback and recording at this buffer size.
Effects: A common cause of playback latency is the use of effects. As your audio stream passes through an effect, it takes time for the computer to perform the calculations to modify that signal. Each effect in a chain introduces its own amount of latency before the chunk of audio even reaches the point where the audio application passes it to the audio device and starts to fill up the buffer. Audition and other DAWs attempt to address this through "latency compensation" routines which introduce a bit more latency when you first press play as they process several seconds of audio ahead of time before beginning to stream those chunks to the audio driver. In some cases, however, the effects may be so intensive that the CPU simply isn't processing the math fast enough.   With Audition, you can "freeze" or pre-render these tracks by clicking the small lightning bolt button visible in the Effects Rack with that track selected. This performs a background render of that track, which automatically updates if you make any changes to the track or effect parameters, so that instead of calculating all those changes on-the-fly, it simply needs to stream back a plain old audio file which requires much fewer system resources. You may also choose to disable certain effects, or temporarily replace them with alternatives which may not sound exactly like what you want for your final mix, but which adequately simulate the desired effect for the purpose of recording.   (You might replace the CPU-intensive Full Reverb effect with the lightweight Studio Reverb effect, for example. Full Reverb effect is mathematically far more accurate and realistic, but Studio Reverb can provide that quick "body" you might want when monitoring vocals, for example.) You can also just disable the effects for a track or clip while recording, and turn them on later.
Device and Driver Options: Different devices may have wildly different performance at the same buffer size and with the same session. Audio devices designed primarily for gaming are less likely to perform well at low buffer sizes as those designed for music production, for example. Even if the hardware performs the same, the driver mode may be a source of latency. ASIO is almost always faster than MME, though many device manufacturers do not supply an ASIO driver. The use of third-party, device-agnostic drivers, such as ASIO4ALL (www.asio4all.com) allow you to wrap an MME-only device inside a faux-ASIO shell. The audio application believes it's speaking to an ASIO driver, and ASIO4ALL has been streamlined to work more quickly with the MME device, or even to allow you to use different inputs and outputs on separate devices which ASIO would otherwise prevent.
We also now see more USB microphone devices which are input-only audio devices that generally use a generic Windows driver and, with a few exceptions, rarely offer native ASIO support. USB microphones generally require a higher buffer size as they are primarily designed for recording in cases where monitoring is unimportant. When attempting to record via a USB microphone and monitor via a separate audio device, you're more likely to run into issues where the two devices are not synchronized or drift apart after some time. (The ugly secret of many device manufacturers is that they rarely operate at EXACTLY the sample rate specified. The difference between 44,100 and 44,118 Hz is negligible when listening to audio, but when trying to precisely synchronize to a track recorded AT 44,100, the difference adds up over time and what sounded in sync for the first minute will be wildly off-beat several minutes later.) You are almost always going to have better sync and performance with a standard microphone connected to the same device you're using for playback, and for serious recording, this is the best practice. If USB microphones are your only option, then I would recommend making certain you purchase a high-quality one and have an equally high-quality playback device. Attempt to match the buffer sizes and sample rates as closely as possible, and consider using a higher buffer size and correcting the latency post-recording. (One method of doing this is to have a click or clap at the beginning of your session and make sure this is recorded by your USB microphone. After you finish your recording, you can visually line up the click in the recorded track with the click in the original track by moving your clip backwards in the timeline. This is not the most efficient method, but this alignment is the reason you see the clapboards in behind-the-scenes filmmaking footage.)
Other Hardware: Other hardware in your computer plays a role in the ability to feed or store audio data quickly. CPUs are so fast, and with multiple cores, capable of spreading the load so often the bottleneck for good performance - especially at high sample rates - tends to be your hard drive or storage media. It is highly recommended that you configure your temporary files location, and session/recording location, to a physical drive that is NOT the same as you have your operating system installed. Audition and other DAWs have absolutely no control over what Windows or OS X may decide to do at any given time and if your antivirus software or system file indexer decides it's time to start churning away at your hard drive at the same time that you're recording your magnum opus, you raise the likelihood of losing some of that performance. (In fact, it's a good idea to disable all non-essential applications and internet connections while recording to reduce the likelihood of external interference.) If you're going to be recording multiple tracks at once, it's a good idea to purchase the fastest hard drive your budget allows. Most cheap drives spin around 5400 rpm, which is fine for general use cases but does not allow for the fast read, write, and seek operations the drive needs to do when recording and playing back from multiple files simultaneously. 7200 RPM drives perform much better, and even faster options are available. While fragmentation is less of a problem on OS X systems, you'll want to frequently defragment your drive on Windows frequently - this process realigns all the blocks of your files so they're grouped together. As you write and delete files, pieces of each tend to get placed in the first location that has room. This ends up creating lots of gaps or splitting files up all over the disk. The act of reading or writing to these spread out areas cause the operation to take significantly longer than it needs to and can contribute to glitches in playback or loss of data when recording.

There is one point in the above that needed a little clarification, relating to USB mics:
_durin_ wrote:
If USB microphones are your only option, then I would recommend making certain you purchase a high-quality one and have an equally high-quality playback device.
If you are going to spend that much, then you'd be better off putting a little more money into an external device with a proper mic pre, and a little less money by not bothering with a USB mic at all, and just getting a 'normal' condensor mic. It's true to say that over the years, the USB mic class of recording device has caused more trouble than any other, regardless.
You should also be aware that if you find a USB mic offering ASIO support, then unless it's got a headphone socket on it as well then you aren't going to be able to monitor what you record if you use it in its native ASIO mode. This is because your computer can only cope with one ASIO device in the system - that's all the spec allows. What you can do with most ASIO hardware though is share multiple streams (if the device has multiple inputs and outputs) between different software.
Seriously, USB mics are more trouble than they're worth.

8.0.2 horrendous bug still exists!!!!!!!!!!!!!

The effects and sample caching bug is horrendous in my opinion. It's been there for years. It wastes huge amounts of my time. While there are some things you can do to minimize these glitches, there are NO 100% reliable work arounds. If you work in Logic and want a professional result you absolutely must listen to the finished bounce very carefully for glitches. These glitches come in many forms and will often times only be noticed after you receive the finished product from the mastering house.
The main culprits are:
1. Reverb and delay tails. If you have reverb or delay on a track and you stop playback and move your position, the reverb or delay will begin where it left off.
2. Samples. For example I often replace kicks and snares with samples. When I go to start a bounce random samples will play at the beginning of the track.
3. Clicks from compressor and EQ plug ins. These are less obvious, but generally mastering brings them out loud and clear after it's too late.
Keep in mind that these glitches don't generally happen until a split second before a region starts. That means it is very common for them to happen in the middle of the song. Starting and stopping playback a few times does NOT completely clear the cache.
It's a total craps shoot and the most embarrassing, time wasting aspect of Logic.
I really wish I could trust Logic to give me a bounce that is exactly "as expected."
I just sent a bug report... I encourage you all to do the same. They are obviously working on stuff and I think it's our responsibility to make it a priority for them.
http://www.apple.com/feedback/logicpro.html

Hi Rohan,
I meant to begin my last post "with all due respect". I read you all the time, you are always well informed, plus you came up with the 8.02 key command fix/discovery..
Rohan Stevenson1 wrote:
hi pancentre,
no mate that's not correct re logic flushing the buffer. that is actually my point - it can't, not the way the audio engine is designed - god, but my memory is sketchy on this - i remember getting the ins and outs of this a long time ago...
Right, I understand exactly what you're saying, this is indeed the way Logic works... my point was it's an archaic system that was devised at a time when computers had 1/1000th the processing power we have now. There's no need for such great efficiency, plugins can be kept partially active, this is how 9 out of 10 DAWs flush the buffers, the plugin is always active to some extent.
one of the things that makes logic efficient is the way it handles plugs - it doesn't process them the whole time - only when there is sound to process.
Agreed, see above. I think this is related to a couple of Logic's other quirks.
Efficiency in one area is causing less efficiency in other areas, the overload messages. What happens when a song is playing and it comes upon three regions with a couple of space designers and an instance sculpture? Instead of these plugs being partially active and using a little processor, they all become active at once and often cause a spike... ie; system overload or other kind of glitch.
it is the 3rd party plugs that have to flush its own audio buffer - its not something logic can effect without changing the way it works to become much less efficient.
but if you were to call it a 'logic bug' then i would find it hard to disagree with you:
Well, I guess it's hard to say but it seems like Apple came up with a workaround for Logic's behaviour and then asked everyone else to do the same. Until Apple version 7.xx Logic's plugins used to do the reverb tails and all other manner of little tics & glitches.
There's still a couple of Logic's plugs that aren't all the way compliant.
pancenter-

9.0.0 horrendous bug still exists!!!!!!!!!!!

Just reintroducing my pet peeve with Logic in general. It's the one thing that frustrates me most about Logic and it still persists after many many years. Here's my original post from 8.0.2:
http://discussions.apple.com/thread.jspa?threadID=1531297&start=0&tstart=129
The effects and sample caching bug is horrendous in my opinion. It's been there for years. It wastes huge amounts of my time. While there are some things you can do to minimize these glitches, there are NO 100% reliable work arounds. If you work in Logic and want a professional result you absolutely must listen to the finished bounce very carefully for glitches. These glitches come in many forms and will often times only be noticed after you receive the finished product from the mastering house.
The main culprits are:
1. Reverb and delay tails. If you have reverb or delay on a track and you stop playback and move your position, the reverb or delay will begin where it left off.
2. Samples. For example I often replace kicks and snares with samples. When I go to start a bounce random samples will play at the beginning of the track.
3. Clicks from compressor and EQ plug ins. These are less obvious, but generally mastering brings them out loud and clear after it's too late.
Keep in mind that these glitches don't generally happen until a split second before a region starts. That means it is very common for them to happen in the middle of the song. Starting and stopping playback a few times does NOT completely clear the cache.
It's a total craps shoot and the most embarrassing, time wasting aspect of Logic.
I really wish I could trust Logic to give me a bounce that is exactly "as expected."
I just sent a bug report... I encourage you all to do the same. They are obviously working on stuff and I think it's our responsibility to make it a priority for them.
http://www.apple.com/feedback/logicpro.html

lwilliam wrote:
It's an inexcusable bug. It's one of the few reasons left why I can't use it in front of clients. How embarassing to have to trim the beginning of a bounced file to get rid of a reverb tail!
1. If it were truly an AU-only bug, then wouldn't Cubase also exhibit the same behavior? I've not heard of Cubase users complaining about that.
2. If were really an plugin not following the AU spec, then why do these 3rd party plugins pass the validation test?
Since I go way back with this... I can tell you this behavior started with version 4.xx when Emjk adapted Logic to use VST instruments. At that time all of Logic's plugins (reverbs...internal synths) exhibited these problems as well as 3rd party VST. it was a KNOWN issue and had to do with the manner in which Logic handles buffers and and unhooks plugins/AU from the CPU at stop. Plugins, VST & AU become inactive with data in their buffers. It was never a problem with any other DAW as the plugins are kept active long enough to empty the buffers. The onus being put on the plugins was added to the AU spec at a later date to cover Logic's behavior. (which really P.O.'d some plugin developers, so much so that some won't even fix what to them is not their problem.)
I don't know about the latest version of Garageband but interestingly enough, it doesn't exhibit this problem, or if it does, nowhere near as bad as Logic. It was something that was "fixed" in Garageband.
I dislike when companies try and rewrite history, as mentioned, this was a
-known- issue. It was discussed between users and programmers... (back in the day).
over and out on this.
pancenter-

Windows Server 2012 Hyper-V network latencies

Hi All,
I have an issue with our Windows Server 2012 Hyper-V hosts that I can't seem to figure out. Situation:
2 x Dell PowerEdge R815 servers with AMD opteron 6376 16 core CPU's and 128 GB RAM running Windows Server 2012 with Hyper-V.
2 virtual machines running on the same physical host and connected to the same virtual switch show high TCP connection latencies. One virtual machines runs a SQL Server 2012 database instance and a Dynamics AX 2012 R2 instance. The other machine a
SharePoint 2013 instance and the AX client. We see latencies of 20ms and higher on most of the TCP connections that are made from the sharepoint machine to the sql server machine.
At first I thought it might have something to do with the physical NIC's. It turned out that VMQ wasn't correctly supported by the firmware of the Broadcom BCM5709c cards. By default this setting is enabled. Turning off the VMQ setting somewhat improved
the situation but the latencies are still at 8ms and higher.
What I don't understand is what influence enabling/disabling VMQ should have on network performance. As I understand it now virtual machines connected to the same virtual switch bypass the physical altogether. Another point is that VMQ should actually improve
performance, not decrease it.
Another question I have is about the various tcp offloading settings on the physical NIC's. After installing the new firmware and drivers from Dell most of these settings are set to disabled. The documents I have been able to find talk about Windows Server
2008, any thought how these settings relate to Windows Server 2012 and whether they should be enabled?
Thanks in advance for your time and thoughts
Kind regards,
Dennes Schuitema

Hi Denes,
Please try to update your BroadCom NIC driver version ,the newest version should be 7.8.51
For details please refer to following link :
http://www.broadcom.com/support/ethernet_nic/netxtremeii.php
Best Regards
Elton Ji
If it is not the answer , you can unmark it to continue .
We
are trying to better understand customer views on social support experience, so your participation in this
interview project would be greatly appreciated if you have time.
Thanks for helping make community forums a great place.

Mixing Ram with different CAS latencies in K7n2 Delta-L?

I have been using 512mb Kingston Value Ram in my computer, pc3200, with CAS latency of 3.0. I just purchased some Corsair value select 512mb ram pc3200 with CAS latency of 2.5. I know you are not supposed to mix ram with different speeds (like 400 vs. 333) but does it matter if the CAS latencies are different?
I'm running an AMD XP 1800+, K7n2 delta-L, nforce2 motherboard from MSI. Someone at a computer shop told me they tried mixing Kingston 3.0 CAS with Corsair 2.5 CAS, and said his computer wouldn't even post. So I'm wondering if this is an isolated problem, or you will always run into this problem if you mix ram with different CAS latencies.
If anyone has experience with this issue, please share with the board. Thanks!
Chris

The age old question, will the components I bought be compatible ? There are those that have bought identical matching memory that didn't work. In my case, I had an ECS K7S5A that used PC2100 Crucial memory, the sticks neither matched (at one time they did, but one stick died and they sent me the closest thing they had.). Neither of these Crucial sticks was identified by a configurator as being compatible with the K7N2 Delta L that I decided to buy. In the end, not only did both sticks work, but I put them in as single channel mode (ram slots 1 & 2), but later changed the configuration to dual channel mode (ram slots 1 & 3, even 2 & 3). It worked flawlessly in all three configurations. Sorry for the long answer, but in essence, there are no guarantees and your worries will drive you crazy. When memory is mixed, you reduce the likelihood of compatibility, even when you go beyond the recommended products that were specifically identified.
That guy at the computer shop, did he ever indicate or isolate the true reason why the memory wouldn't work ? Maybe, maybe not. I would think with a disparity in memory, the bios is the key to setting the settings for the worst stick of the bunch. Then again, the products you get might overclock to what the better sticks run at. My assumption is that mixed sticks, the bios retards settings to this in "auto" mode. When you force it manually, it may work or it may fail. One thing you oughta know, each and every stick has the manufacturers id encoded onto them at the very least, just like the firmware on other items indicates a manufacturer code and other data that allows these things to be compatible. So know you face that battle going in with any of them. If the bios programming doesn't allow it to work, from that perspective, there'll be problems.

Home wireless router. Awful latency.

Hello guys.
I have a wireless router at home, as all the cool guys in the block. Recently I am experiance an awful latency. I am sitting next to the router, less then a metter from it. Here is what I have:
[ ~ ] netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.10.1 0.0.0.0 UG 0 0 0 wlan0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
[ ~ ] ping 192.168.10.1 -c 10
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
64 bytes from 192.168.10.1: icmp_req=1 ttl=64 time=67.8 ms
64 bytes from 192.168.10.1: icmp_req=2 ttl=64 time=593 ms
64 bytes from 192.168.10.1: icmp_req=3 ttl=64 time=0.749 ms
64 bytes from 192.168.10.1: icmp_req=4 ttl=64 time=96.1 ms
64 bytes from 192.168.10.1: icmp_req=5 ttl=64 time=474 ms
64 bytes from 192.168.10.1: icmp_req=6 ttl=64 time=379 ms
64 bytes from 192.168.10.1: icmp_req=7 ttl=64 time=94.9 ms
64 bytes from 192.168.10.1: icmp_req=8 ttl=64 time=19.4 ms
64 bytes from 192.168.10.1: icmp_req=9 ttl=64 time=76.4 ms
64 bytes from 192.168.10.1: icmp_req=10 ttl=64 time=0.797 ms
64 bytes from 192.168.10.1: icmp_req=154 ttl=64 time=1366 ms
64 bytes from 192.168.10.1: icmp_req=155 ttl=64 time=404 ms
64 bytes from 192.168.10.1: icmp_req=156 ttl=64 time=139 ms
64 bytes from 192.168.10.1: icmp_req=157 ttl=64 time=1564 ms
64 bytes from 192.168.10.1: icmp_req=158 ttl=64 time=1158 ms
64 bytes from 192.168.10.1: icmp_req=159 ttl=64 time=190 ms
64 bytes from 192.168.10.1: icmp_req=160 ttl=64 time=618 ms
64 bytes from 192.168.10.1: icmp_req=161 ttl=64 time=74.7 ms
64 bytes from 192.168.10.1: icmp_req=162 ttl=64 time=395 ms
64 bytes from 192.168.10.1: icmp_req=163 ttl=64 time=1024 ms
64 bytes from 192.168.10.1: icmp_req=164 ttl=64 time=276 ms
64 bytes from 192.168.10.1: icmp_req=165 ttl=64 time=1049 ms
64 bytes from 192.168.10.1: icmp_req=166 ttl=64 time=589 ms
64 bytes from 192.168.10.1: icmp_req=167 ttl=64 time=644 ms
64 bytes from 192.168.10.1: icmp_req=168 ttl=64 time=979 ms
64 bytes from 192.168.10.1: icmp_req=169 ttl=64 time=779 ms
64 bytes from 192.168.10.1: icmp_req=170 ttl=64 time=623 ms
64 bytes from 192.168.10.1: icmp_req=171 ttl=64 time=3450 ms
64 bytes from 192.168.10.1: icmp_req=172 ttl=64 time=13993 ms
64 bytes from 192.168.10.1: icmp_req=173 ttl=64 time=14286 ms
64 bytes from 192.168.10.1: icmp_req=174 ttl=64 time=13286 ms
64 bytes from 192.168.10.1: icmp_req=175 ttl=64 time=12320 ms
64 bytes from 192.168.10.1: icmp_req=176 ttl=64 time=11430 ms
64 bytes from 192.168.10.1: icmp_req=177 ttl=64 time=10586 ms
64 bytes from 192.168.10.1: icmp_req=178 ttl=64 time=10008 ms
64 bytes from 192.168.10.1: icmp_req=179 ttl=64 time=9684 ms
64 bytes from 192.168.10.1: icmp_req=180 ttl=64 time=8809 ms
64 bytes from 192.168.10.1: icmp_req=181 ttl=64 time=7857 ms
64 bytes from 192.168.10.1: icmp_req=182 ttl=64 time=6992 ms
64 bytes from 192.168.10.1: icmp_req=183 ttl=64 time=6610 ms
64 bytes from 192.168.10.1: icmp_req=184 ttl=64 time=6017 ms
64 bytes from 192.168.10.1: icmp_req=185 ttl=64 time=6606 ms
64 bytes from 192.168.10.1: icmp_req=186 ttl=64 time=8064 ms
64 bytes from 192.168.10.1: icmp_req=187 ttl=64 time=7057 ms
64 bytes from 192.168.10.1: icmp_req=188 ttl=64 time=6056 ms
64 bytes from 192.168.10.1: icmp_req=189 ttl=64 time=5123 ms
64 bytes from 192.168.10.1: icmp_req=190 ttl=64 time=4122 ms
64 bytes from 192.168.10.1: icmp_req=191 ttl=64 time=3131 ms
64 bytes from 192.168.10.1: icmp_req=192 ttl=64 time=2220 ms
64 bytes from 192.168.10.1: icmp_req=193 ttl=64 time=1407 ms
64 bytes from 192.168.10.1: icmp_req=194 ttl=64 time=506 ms
64 bytes from 192.168.10.1: icmp_req=195 ttl=64 time=185 ms
This is my wifi on my laptop:
[ ~ ] lsusb
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)
Bus 004 Device 002: ID 15d9:0a4c Trust International B.V. USB+PS/2 Optical Mouse
Bus 001 Device 003: ID 413c:8157 Dell Computer Corp. Integrated Keyboard
Bus 001 Device 004: ID 413c:8158 Dell Computer Corp. Integrated Touchpad / Trackstick
[ ~ ]
wlan0 IEEE 802.11abg ESSID:"Fanagoria"
Mode:Managed Frequency:2.422 GHz Access Point: D8:5D:4C:F1:D7:02
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
I have the wl driver:
[ ~ ] lsmod | grep wl
wl 2557291 0
cfg80211 176889 1 wl
lib80211 3949 2 wl,lib80211_crypt_tkip
[ ~ ]
Here is my MODULES section in my /etc/rc.conf file:
[ ~ ] cat /etc/rc.conf | grep MODULES
# MODULES: Modules to load at boot-up. Blacklisting is no longer supported.
MODULES=(lib80211 wl fuse cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats cpufreq_ondemand acpi-cpufreq fglrx)
[ ~ ]
My wireless router is that TP-LINK and it`s firmware is updated to the latest version. (I using the stock firmware). There are no wireless network in range, that are using the same channel as mine is. The latency is happening to my friends connected to my router too. I am using wicd for network manager, and wicd-curses for network manager front-end.
I will post more info if needed.
Please advise me what can I do.
Regards
Last edited by Gruntz (2012-05-15 18:46:17)

Okay well I can see nothing that would cause this in anything you've posted. Especially if your friends are experiencing this too.
I would either try downgrading the firmware (If after upgrading this happened). However, I see that your TL-WR1043ND is VERY well supported by Open-WRT. You may want to give it a look.
Remember that the WiFi channels are overlapped. Try getting as far away as possible from other networks.
Ensure you are running WPA-PSK with the AES cipher and a key of 63 pseudorandom characters. This way others are not using your WiFi to torrent and suck bandwidth.
Try to stick to 802.11g but if at all possible go with 802.11n. Also if possible move up to the 5Ghz band to get out of the way of other things using the 2.4Ghz uncontrolled spectrum block.
If your router is running things like DHCP, DNS, FTP, SMB, SSH, NTP, VPN, Etc... Quit it. Your TL-WR1043ND is running a 400Mhz processor with 32Mb of memory.
That's basically all the advice I've got. Hope that get's the ball rolling on fixing this for you.

Safari loading pages slowly / high latency

I have recently been asked by one of my clients to look at a problem with their 3 macs at their place of business. They are an iMac, a macbook and a macbook air. They have all started to exhibit the same problem of being slow to load web pages using safari as their web browser of choice.
Using the broadband speed test at speedtest.net shows that they are getting some extremely high latency (~4000ms) to some sites.
I have tested the broadband connection thoroughly using my own (linux) laptop and everything seems to be in working order. Tests on the macs themselves using a terminal show that latency to the internet and dns response times are all as they should be.
From some limited searching the problem appears to be similar to the problem described in http://discussions.apple.com/thread.jspa?messageID=8799710&#8799710 where safari itself is causing some problems for some reason.
What I'm looking for is some suggestions on how i can go about fixing the problem when i next visit the client

Welcome to the forums!
The following usually works on both Tiger and Leopard:
(First, if yours is an Intel Mac, check that Safari is not running in Rosetta, which is enough to slow it to a crawl.)
Adding DNS codes to your Network Settings, should gives good results in terms of speed-up:
Open System Preferences/Network. Double click on your connection type, or select it in the drop-down menu. Click on TCP/IP and in the box marked 'DNS Servers' enter the following two numbers:
208.67.222.222
208.67.220.220
(An explanation of why that is both safe and a good idea can be read here: http://www.labnol.org/internet/tools/opendsn-what-is-opendns-why-required-2/2587 / )
Whilst in System Preferences/Network you should also turn off 'IPv6' in your preference pane, as otherwise you may not get the full speed benefit (the DNS resolver will default to making SRV queries). If you want to know what IPv6 is:
This is Apple's guidance on iPv6:
http://docs.info.apple.com/article.html?path=Mac/10.5/en/8708.html
Click on Apply Now and close the window.
Restart Safari, and repair permissions.
If that didn't do it, then try this as well:
Empty Safari's cache (from the Safari menu), then close Safari.
Go to Home/Library/Safari and delete the following files:
form values
download.plist
Then go to Home/Library/Preferences and delete
com.apple.Safari.plist
Repair permissions (in Disk Utility).
Start up Safari again, and things should have improved.

Latency issue Logic pro 9.1.3.

Hey,
At the same time as upgrading to Logic from Garageband
I bought a Cakewalk Roland UA25EX ext usb soundcard because i was told
i'd have latency issues if i used the caps lock keyboard for midi
or direct input thru the input jack of
my MacBookPro
(5,3 Intel Core 2 Duo 2.8 GHz)
Sometimes i use the caps lock keyboard to sketch in midi ideas and mostly it's ok.
Other times it's delayed and there's no smile on my face.
When recording with guitars/303/generators DI thru the soundcard
I have latency issues that don't seem to be very regular.
Sometimes it's worse than others.
I make sure i have nothing else running on the computer,
just Logic Pro 9.1.3, so it's not like i'm overloading macbrains.
I have tried all the rebooting, i/o buffer size changing (down to 256), headfones from the mac output/headfones from the soundcard/ etc
but still no luck.
I can record with the low latency button on
and it's kind of better, nearly, but that means i don't get to record with the effects on the channel strip
that affects the recording/playing quite a lot, as i'm used to recording with effects/guitar amps if i go DI.
This was the selling point - that i could record DI wthout disturbing Thee Neighbours.
It seems to have gotten worse recently.
I wonder if it's been corrupted somehow because it also has been acting funny when i bounce down -
the play head is set to 1111 and i save - then in the bounce window
the start position says a silly random number and it takes a few attempts of fiddly changes to get it to stay at 1111...frustration!
Is there something i can do or is this normal? -
it seems weird that a Pro app that cost me so much £s wouldn't work in a simple recording/bounce down set up?
or has anyone else had this problem and fixed it?
If i wipe Logic and install again would i have to go from my Logic Express and then up to my Logic Pro upgrade/extension again?
Any pointers would be greatly appreciated.
Thanks in advance

Hey Fox,
Thanks for that info -well umm, yes i installed the correct drivers.
I use just the AU plugins or the basic logic ones on the channel strip
but even when i was going in dry there was still a delay.
I had experimented with the buffer size, as mentioned, but not gone down that low cus
last time i tried that i had other strange things happen!
But i will try again.
Sample rate was at zero, btw. Always says zero.
But today, when i just opened logic, the sample rate had changed. Strange. I need to understand this side of things so i'm gonna read up.
Also, if plugins are involved, i installed some novation bass station and some freeware TAL bass synth
stuff recently but don't have them up when i'm recording.
Maybe they sit there quietly and interfere just by their facial expressions or sumthing!!
I booted Mr MBP just now and i pulled out the USB and he's shining me a big ole red optical light
out of his output jack!!
In SysPrefs it has only optical digital as an output option.
In the last few days as i was playing around trying to correct the latency issue i noticed that the output options had changed to the UA25 and the 'digital optical' options - rather than the UA25 and 'line out'.
I'm off to go and read up on how to get my line out back, and try this buffer thing again.
Thanks again
Gravity

Horrendous latency

Similar Messages

Maybe you are looking for