About USB, Drivers, OS-X, etc.

Just curious . . . how did that advertising read? Did you infer something, or did it spell it out?

I didn't infer anything. One of the features that has been touted since day one is the ability to use the II as an audio interface on a Mac & PC. Every ad mentions this and it's clearly spelled out directly on the Fractal site:

"The Axe-Fx II has a host of USB connectivity features. Connected to your Mac or PC, it becomes a 2x4 Audio Interface with 1x1 high speed MIDI. This allows you to record the main processed outputs and simultaneously capture a "dry" track for re-amping later. You can also monitor or process computer audio tracks with the Axe-Fx II. 1x1 high speed MIDI-over-USB eliminates the need for a separate MIDI interface and makes editing with Axe-Edit, our free editor librarian software easier than ever before."
 
Regarding the word buffer. This seems to have been confused in other threads and so on as adjusting latency. It has nothing to do with adjusting latency.

Latency is the delay of a communication for example.

A buffer is an area of memory for temporary storage of data. Think of water running into a bath at a constant rate and running out at the same rate. If the flow of water increases going in or the ability of the water to leave the bath slows down, the bath itself will act as a buffer to the water until the flow regulates again. If the water filled the buffer and the buffer is full you then have a flood or an overrun.

A buffer may be used as a way of overcoming temporarily latency or synchronisation issues.

For more on buffers see Data buffer - Wikipedia, the free encyclopedia especially the section telecommunication buffers.

So the larger buffer size is, the better?
Right?
 
I didn't infer anything. One of the features that has been touted since day one is the ability to use the II as an audio interface on a Mac & PC. Every ad mentions this and it's clearly spelled out directly on the Fractal site:

"The Axe-Fx II has a host of USB connectivity features. Connected to your Mac or PC, it becomes a 2x4 Audio Interface with 1x1 high speed MIDI. This allows you to record the main processed outputs and simultaneously capture a "dry" track for re-amping later. You can also monitor or process computer audio tracks with the Axe-Fx II. 1x1 high speed MIDI-over-USB eliminates the need for a separate MIDI interface and makes editing with Axe-Edit, our free editor librarian software easier than ever before."

Try this.

Agregate device solution (I hope)
-------------------------------------------------

Also I found that marking "RESAMPLE THIS SUBDEVICE" in AUDIO-MIDI setup utility by right button (or ctrl+click) mouse clicking (don't be confuse with format menu in right side) solved the problem! The black quadrate with wave image will appear in the right of AXE-FX II Audio after marking. For the moment (about a week) I didn't noticed ANY crashes with this configuration. But this ("RESAMPLE THIS SUBDEVICE") works only with aggregate device mode. So aggregate device must be created for this function. There is any combinations of devises you can create and it's very easy and you don't need second Audio Interface. You can combine AXE with internal MAC's sound card, but the goal is to mark "RESAMPLE THIS SUBDEVICE".
 
So the larger buffer size is, the better?
Right?

On the surface yes. But that isn't the whole story. Its about finding an optimum buffer size, one large enough to do the job but not large enough to consume too much memory for no real purpose.

The general approach to take would be to increase buffer size to where clocking problems are not seen, then reduce that figure until the clocking problem reappears, then increase to a point mid way between the previous two values, and repeat this process as needed to get rid of clocking issues but not using more resources than needed.
 
On the surface yes. But that isn't the whole story. Its about finding an optimum buffer size, one large enough to do the job but not large enough to consume too much memory for no real purpose.

The general approach to take would be to increase buffer size to where clocking problems are not seen, then reduce that figure until the clocking problem reappears, then increase to a point mid way between the previous two values, and repeat this process as needed to get rid of clocking issues but not using more resources than needed.

Thank you! Now it's clear for me!
 
Still having big problems with VLC on Mac 10.8.4. Playing music or watching movies via Axe FX II is going to be distorted after a few minutes. Not that drastic like before and it's more a top end distortion but still annoying. No problem with iTunes or other programs.

I've to add that the the VLC is on about 60% Volume so there is no clipping because of too high output volume.
 
The firmware updates and overall performance via USB is very much improved on my Win7 64 PC, but since upgrading to drivers 1.67 and v10.09 firmware I've had two freezes requiring an Axe reboot. Both times the USB was connected but no programs (AxeEdit, Fractal Bot, Midi OX, etc.) were running. I've not had these types of lockups before. MFC-101 v2.18 connected. I was just playing thru new presets freshly created for 10.06.

The first crash was when the analog audio output just died and the units controls were frozen. No lights on the input LEDs. A reboot fixed this.

Earlier tonight I was selecting blocks via the front panel and the audio again died, unit frozen, no input LED's lighting. After a few seconds the front panel when blank. Reboot fixed the issue.
 
I don't believe this to be true. In audio applications the buffer is related to latency. This is why DAW software generally allows you to set the buffer size. These buffers are FIFO, so the more samples being held in the buffer, the higher the time between the signal coming into the device and being passed to the next stage (such as your ears). This is what causes the latency, a delay between signal input and output.

Correct, the larger the buffer, the more latency.
 
There's seems to be some confusion so this an attempt to clear things up.

1. The Axe-Fx II is an Audio Class 2.0 compliant device. A class-compliant device requires no drivers. The drivers are provided by the OS manufacturer. Audio Class 2.0 also encompasses MIDI-over-USB.

2. HOWEVER... Microsoft does not support Audio Class 2.0. Therefore we provide a driver for Windows systems. It works great (flawlessly in my experience).

So FAS set their focus on a standard, not supported by the WIN plattform from the beginning (and not used by many pro audio companies because of not so far superior audio performance) , and now grumble on Apples poor clock adaption instead of providing a "real" driver for MAC too until Apple supports AC 2.0 as they should? ;) No offense to FAS, to their staff, to you Cliff - sorry - but I'm not buying it. ;)

I would say that many "soft controlled" hardware audio USB interfaces on the market were Class Compliant Audio 2.0 compatible , because this should become that leading standard for the next years. So basically, most of those sophisticated audio interfaces from other brands were class compatible, even if they provided custom made core audio drivers for the apple plattform.

3. Apple DOES support Audio Class 2.0, but poorly at this time. Their driver is prone to clock drift. In an effort to mitigate this we now offer the user the ability to increase the buffer size ON THE AXE-FX II END OF THE CONNECTION. This is NOT the same as the buffer size you set in your computer. All peripheral devices also contain buffers to smooth the bursty nature of data transfers from the host computer. Normally this buffer size is fixed but we didn't want to make it unnecessarily large just to satisfy the needs of a poorly designed host driver as we hope the host driver will eventually be fixed.

So that means we using a synchronous operation mode, were the host and device use implicit feedback. Clock is locked to USB SOF. I'm not an expert, but I would using a PLL here to adjust the internal oscillator to possible clock drift from the host, if using synchronous mode.

as I said - no offense, just some thoughts.

sincerely
Paco
 
Last edited:
I don't believe this to be true. In audio applications the buffer is related to latency. This is why DAW software generally allows you to set the buffer size. These buffers are FIFO, so the more samples being held in the buffer, the higher the time between the signal coming into the device and being passed to the next stage (such as your ears). This is what causes the latency, a delay between signal input and output.

I didn't see your reply earlier. So let me clarify. I am related to my brother but I am not my brother, similarly there may be relationships between buffers and latency but a buffer is still what it is a buffer. But if it is set too large it may contribute to more latency than desired, but it is not latency itself.

If a buffer is set optimally to meet its intended purpose, in this case dealing with a clocking issue then it does what it does. If a buffer is set too large it will consume more memory than needed.
 
Correct, the larger the buffer, the more latency.

Potentially but not necessarily. It's a buffer so if a flow cannot pass at the proper speed it can temporarily store a flow. If there is no hold up then there is no need for the buffer to store data that is able to pass at normal speed.
 
Potentially but not necessarily. It's a buffer so if a flow cannot pass at the proper speed it can temporarily store a flow. If there is no hold up then there is no need for the buffer to store data that is able to pass at normal speed.

Necessarily. It's not just related in a familial sense, there is a mathematical relation between buffer size, sampling rate, and latency.

Latency (seconds) = Buffer samples (samples) / sample rate (samples / sec).

Here is a calculation, 128 samples at 48kHz -> Latency = 128 / 48000 = 0.0029 s = 2.9 ms

Therefore if a device holds 128 samples at that sampling rate before sending to the next stage, the sound will be delayed by 2.9 ms.

Memory isn't an issue here, we're talking about a few hundred samples at 16 bits, 128 samples = 16 bytes.
 
Necessarily. It's not just related in a familial sense, there is a mathematical relation between buffer size, sampling rate, and latency.

Latency (seconds) = Buffer samples (samples) / sample rate (samples / sec).

Here is a calculation, 128 samples at 48kHz -> Latency = 128 / 48000 = 0.0029 s = 2.9 ms

Therefore if a device holds 128 samples at that sampling rate before sending to the next stage, the sound will be delayed by 2.9 ms.

Memory isn't an issue here, we're talking about a few hundred samples at 16 bits, 128 samples = 16 bytes.


The statement I have put in bold in the quote is if the device holds in its buffer a certain amount of data that will be delayed a certain amount of time. Per the maths provided. However a device doesn't have to hold things in its buffer (although it has the potential to do so), if the data is able to pass through unhindered there will be less delay. If for some reason a buffer has to be used ( up to the potential that it is possible to use it ) then necessarily there will be latency.

A buffer does consume a certain amount of memory, but it is memory. I didn't say that it was an issue but a buffer uses memory to do its job.
 
Last edited:
careful - 128Samples per Buffer. Normally in a typical signal chain there is a input- AND an output buffer plus processing time. So in reality 128 Samples will make around 8 - 9 ms roundtrip latency
 
If a buffer is needed as a workaround to the OSX clocking USB issue then its needed. What it does or how it works for most people should not matter. Better it works than it does not work at all. 8)
 
I'm a chemist by training and a musician at heart. I'm no EE and while I've learned a lot about computers and IT I don't know J.S. about writing code. FWIW, I'd like to offer some comments:

* I love my Axe-FX II. It offers excellent guitar tone and is highly versatile.

* I've done exhaustive testing within my DAW (Digital Performer 8.04) and various Mac OS X versions and find it unusable for tracking or reamping via USB. I use a MOTU 828mk3 via FW as my audio interface and currently use the Axe-FX II S/PDIF for recording a processed and DI track. I'm not convinced this is the best way to capture a DI but I could be wrong; maybe it is suitably professional. It seems to works very well to capture the processed track.

* I miss my Radial Reamp kit and wish I still had it. I sold it to help pay for the Axe-FX II. At this point I'm considering buying a new reamp box. I'll be happy to have this capability again but this sucks because I don't have the money and don't want a more complicated set-up, plus I'll feel let down regarding my Axe-FX II.

* As has been mentioned, weaker vendors seem to have developed solutions.

* Regardless of who is "at fault" or the difficulty of solving the problem, "we" can't control Apple and they may never offer a solution.

* I earnestly still wish to avail myself of the advertised capabilities of the Axe-FX II. I hope Fractal can provide a solution. Otherwise I'll pray for the stars to align and Apple will provide a solution.
 
Conversely, I did some tracking via USB with my AxeFXII for the first time this afternoon & evening - first time I've ever tried re-amping too... all worked absolutely flawlessly from start to finish 8)

(2009 iMac 3.06 duo, 4Gb ram, OSX 10.8.4, Logic 9)
 
This is so frustrating. Newest Macbook Pro with Logic X and a new Axe Fx ll and they can't communicate on USB. Seriously? I have to go back to Windows?
 
Sorry to add another new guy into this discussion. I'm so confused by terminology.
I have a MacBook Pro running 10.6.4, that's all I know. I have protools 9 and would kill to have USB audio so I don't need an interface. Will help my ground loop problems a lot.
What does this driver mean for me?
Please help me learn haha

Joe
 
Back
Top Bottom