not worth £2000

@Paco (and/or others), I tried to search at google about device/host clock you mentioned regarding win/mac USB devices but I didn´t find anything. Where can I find any info to read up on it? Thanks in advance!

Sure, you're welcome! Here are some infos regarding the topic:

http://www.audioresearch.com/downloads/DAC8_white_paper.pdf

The AxeFx II features USB audio class 2.0 HS (HS means high speed, full 480Mbit bandwith) but....don't use local fixed master clock (aka device clock) - they use PC clock - at least on apple plattform. 2nd - there is no real driver for mac and since they use a bootloading usb controller, it's not a real class compliant compatible interface (real class compliant doesn't need any drivers!!!)

As mentioned before - I work for one of the biggest distributors in switzerland, as their tech. support, repair service and know approx. 95% of all the gear we sell. We're supporting Blue Microphones as part of the TC-Group product lineup from 2010 to 2011 - they had many audio class 2.0 compliant products in their portfolio - best known product I often use for a good example is the YETI PRO Mic.

Check the specs: Blue Microphones | Yeti Pro - The Ultimate Professional USB Microphone w/ Built-In XLR Output

there is no apple driver needed - it works with 10.6.4 - up to 10.8.4 and higher. On the other hand - you need a WIN driver! Why? Because there is no audio class 2.0 support on win-based systems yet!

So instead of given a bad solution to 70% of the axefx II users who using WIN-machines , FAS decided to provide a good quality WIN-solution, a real ASIO driver. ASIO is a audio stream protocol introduced by Steinberg technologies. Apple did something similar whit their OSX operation system - they put some very powerful API in their OS, one thing called Core Audio, which is directly connected to their hardware abstraction layer. This allows high performance realtime audio functionality, directly implemented in the OS.
Here is some more info for you regarding core audio:
https://developer.apple.com/library....html#//apple_ref/doc/uid/TP40003577-CH10-SW1

FAS using audio class 2.0 compliant technique, they not providing a specific "core audio driver" which would be equal to the ASIO driver for WIN...but as I mentioned above - they did class compliant without an permanent installed usb controller ( somewhere Cliff mentioned that this would be far superior - but I can't remember to see any other company who did this on a class compliant device), so you still need to bootload the controller. They also not using "device clock" aka "local fixed DAC master clock" aka "sample clock by the audio interface" etc.....they use core audio host clock instead , which "nobody really wants to use" according to this quick google find:

coreaudio-api - Re: Has nobody used CoreAudio Clock? - msg#00018 - Recent Discussion OSDir.com

most (all?) hosts use the sample clock of the
audio interface they are using and derive timecode and the rest
internally

So what? ;)

@ Shadoe: Because I'm contribute even more information to it! Enjoy!
 
Last edited:
Class Compliant does not infer that a USB controller can't load it's firmware upon power-on from the host. This is a superior solution in that upgrades merely require a new firmware image on the host. MANY devices use this technique. It is called renumeration. It eliminates having to upgrade the device's EPROM or FLASH and the attendant problems associated with that, with the most serious issue being possible corruption of the FLASH and resulting failure of the device (IOW borked). A simple product like a microphone rarely, if ever, requires a firmware upgrade. A highly complex device like the Axe-Fx II will likely require multiple upgrades over it's product life-cycle and this has proven true already.

The Axe-Fx II uses it's own local clock. This is known as an asynchronous, isochronous interface. This is the SUPERIOR technique although it is more difficult to implement. Inexpensive devices like microphones typically use a synchronous interface and derive their clock from the host clock. This is an INFERIOR solution since a PLL is required in the device which creates clock jitter. Any "serious" pro audio device would NEVER use a PLL for clock generation. Synchronous clock generation is typically reserved for things like mics and cheap powered speakers. Furthermore synchronous devices must always be connected to a computer to operate. Obviously this is impractical for something like the Axe-Fx.
 

Nope ;)

Since half of all "likers" don't understand the topic at all (incl. cliff's statement) and there are things said, that I NEVER stated or told, we have to go a little bit further...

We're mainly talking about apple based performance here, here are some pictures....

axefx-clock.jpg


AxeFx II clock source! Set to "standard" which is host based clock -

Mac-host-clock.jpg


same settings shown if you're using apples internal hardware which has to be use apples host clock ;)

Blue-Clock.jpg


The so called "INFERIOR" usb microphone, which turns out to support 2 channels of 24bit /192kHz by it's own "internal" clock - not bad for an USB microphone, huh? ;)
Maybe because it's not so inexpensive ;)

normal-audio-interface-clock.jpg


Here is a normal audio interface, as an example - a TC Impact Twin interface, also using INTERNAL clock

https://developer.apple.com/library...#//apple_ref/doc/uid/DTS40010116-CH1-TNTAG8_3

So, if the axefx used asynchronous synchronisation , why FAS is so keen about apples poor clock adoption? Asynchronous means not synced to host, data rate is locked to a free-running internal clock on the device itself. Apples host clock dosen't matter here! It would if you use a PLL - and as Cliff said, a serious pro audio device would never use it. So my question still remains the same ;)
Isochronous transfer means, the transfer rate is more important than the data intergrity.....just for those among you, need to know what Cliff was talking about!

As we speak - on apple usb performance, there is still the standard clock source available - not device internal! Maybe there is a way to change it by changing the clock domain ID.....sadly I'm not an apple developer! ;)

cheers
Paco
 
We didn't write the driver, Apple did. Take your complaints to them.

Cliff, once again - If you using class compliant drivers, then it's very clear who wrote them - because they were part of the operating system, this was also my statement regarding class compliant interfaces. I'm aware of this..... Blue Microphones were also used apples class compliant driver, using the same majority of functionality provided by the class driver, which is also used by the axefx II after the bootloading usb controller driver talks with the OS, saying "hey my vendor name is Fractal Audio Systems, I'm a audio class 2.0 device etc" , but what it don't says yet is "I use Fractal Audio internal clock source", instead it might saying: "give my your poor audio clock adoption you stupid apple piece of shit" :lol :lol

on windows you were using a vendor specific driver - why not also for apple ;)
 
Last edited:
Cliff, once again - If you using class compliant drivers, then it's very clear who wrote them - because they were part of the operating system, this was also my statement regarding class compliant interfaces. I'm aware of this..... Blue Microphones were also used apples class compliant driver, using the same majority of functionality provided by the class driver, which is also used by the axefx II after the bootloading usb controller driver talks with the OS, saying "hey my vendor name is Fractal Audio Systems, I'm a audio class 2.0 device etc" , but what it don't says yet is "I use Fractal Audio internal clock source", instead it says: "give my your poor audio clock adoption you stupid apple piece of shit" :lol: :lol:

on windows you were using a vendor specific driver - why not also for apple ;)

An asynchronous interface doesn't have control over the clock that the driver uses. The driver must provide rate adaption between the peripheral's clock and the system clock. This is all semantics anyways. It is not the peripheral's responsibility to tell the OS how to do it's job. The peripheral defines its function and the rest is up to the driver.

Your argument makes no sense since obviously the Windows driver works well. Therefore the peripheral has properly defined its functionality. The issue lies with the OS-X driver and its rate adaption. So, ONCE AGAIN, take it up with Apple.
 
An asynchronous interface doesn't have control over the clock that the driver uses. The driver must provide rate adaption between the peripheral's clock and the system clock. This is all semantics anyways. It is not the peripheral's responsibility to tell the OS how to do it's job. The peripheral defines its function and the rest is up to the driver.

So we're talking about a host/device clock mismatch because of a sample buffer over- and underrun, right? Well the device itself can request more or less samples per milisecond from the host so a buffer over- or underrun would not occour.

Sure the windows version works well, because it don't use audio class 2.0 compliant drivers ;) A specific core audio driver would work too....but apple doesn't support a vendor specific driver, not even on requests ;)
 
So we're talking about a host/device clock mismatch because of a sample buffer over- and underrun, right? Well the device itself can request more or less samples per milisecond from the host so a buffer over- or underrun would not occour.

Sure the windows version works well, because it don't use audio class 2.0 compliant drivers ;) A specific core audio driver would work too....but apple doesn't support a vendor specific driver, not even on requests ;)

Yes, sort of. The host and peripheral clocks run at different speeds. For example the Axe-Fx clock might be 48.000001 kHz. The host clock might be 47.99999 kHz. Over time this error builds up. The peripheral cannot alter it's rate of transmission since it's clock is fixed. The host MUST adapt to the peripheral. This is accomplished using rate feedback.

This is very advanced stuff and probably over everyone's heads. I recommend you read the USB 2.0 Specification, specifically Section 5.12.

The Windows version IS class compliant. It uses the exact same descriptor tables. You can plug the Axe-Fx into a Mac and then move the cable to a PC and it will run just the same. The firmware is identical. The only difference is that Microsoft didn't supply the driver (there is no native AC 2.0 driver in Windows because Microsoft doesn't care). It is an AC 2.0 driver written by a third party.
 
Sure, you're welcome! Here are some infos regarding the topic:

http://www.audioresearch.com/downloads/DAC8_white_paper.pdf

The AxeFx II features USB audio class 2.0 HS (HS means high speed, full 480Mbit bandwith) but....don't use local fixed master clock (aka device clock) - they use PC clock - at least on apple plattform. 2nd - there is no real driver for mac and since they use a bootloading usb controller, it's not a real class compliant compatible interface (real class compliant doesn't need any drivers!!!)

As mentioned before - I work for one of the biggest distributors in switzerland, as their tech. support, repair service and know approx. 95% of all the gear we sell. We're supporting Blue Microphones as part of the TC-Group product lineup from 2010 to 2011 - they had many audio class 2.0 compliant products in their portfolio - best known product I often use for a good example is the YETI PRO Mic.

Check the specs: Blue Microphones | Yeti Pro - The Ultimate Professional USB Microphone w/ Built-In XLR Output

there is no apple driver needed - it works with 10.6.4 - up to 10.8.4 and higher. On the other hand - you need a WIN driver! Why? Because there is no audio class 2.0 support on win-based systems yet!

So instead of given a bad solution to 70% of the axefx II users who using WIN-machines , FAS decided to provide a good quality WIN-solution, a real ASIO driver. ASIO is a audio stream protocol introduced by Steinberg technologies. Apple did something similar whit their OSX operation system - they put some very powerful API in their OS, one thing called Core Audio, which is directly connected to their hardware abstraction layer. This allows high performance realtime audio functionality, directly implemented in the OS.
Here is some more info for you regarding core audio:
https://developer.apple.com/library....html#//apple_ref/doc/uid/TP40003577-CH10-SW1

FAS using audio class 2.0 compliant technique, they not providing a specific "core audio driver" which would be equal to the ASIO driver for WIN...but as I mentioned above - they did class compliant without an permanent installed usb controller ( somewhere Cliff mentioned that this would be far superior - but I can't remember to see any other company who did this on a class compliant device), so you still need to bootload the controller. They also not using "device clock" aka "local fixed DAC master clock" aka "sample clock by the audio interface" etc.....they use core audio host clock instead , which "nobody really wants to use" according to this quick google find:

coreaudio-api - Re: Has nobody used CoreAudio Clock? - msg#00018 - Recent Discussion OSDir.com



So what? ;)

@ Shadoe: Because I'm contribute even more information to it! Enjoy!
What kinda guitars do you have?
 
What kinda guitars do you have?

Many - and I can on all of play them ;) I guess this is not important regarding this topic.....see my signature below! ;)

@ Gilmourfan1977: From a fanboy point of view - yes. Sorry, I don't wanted to be mean to you.....

A class compliant device on mac remains a class compliant device on Win. That is correct. So both plattforms using the same basic functionality regarding USB Audio Class 2.0 specs, that is correct. But that's not my point when talking about CC vs. 3rd party drivers. A class compliant driver set a majority of functions provided by the operating system regarding to CC specs, but the definitions of data transfer functionality aka endpoints, IDs, max packet size etc. were all set in the USB controller device description of the device itself.
If there is a data buffer under- or over run, due of a host clock drift, there is either a 3rd party software based correction needed or the correction is done by the definitions in the USB controller - premised there is such advanced functionality possible in the hardware usb controller. According to Cliff it's not provided by apples audio class 2.0 drivers.... ;)

@ AAEN: Yes, Mac-users are loosers in this game here. Here, because there are plenty of pro audio devices using USB 2.0 either with specific core audio drivers (equal to 3rd party ASIO drivers) or audio class 2.0 that working perfectly - now have to find out it's impossible to use the built in audio interface functionality by the axefx II.

Mac-users were not loosers on the other hand. There is world class audio performance possible right out of the box, while on windows you need to find the right hardware, dealing with incompatibility issues between different components etc. - but I don't want to start a typical apple vs. win thread. There are both great OS and of corse, there were many world class win-based daw setups around - but they are presetted by specialists, which is a pricy thing too.... There were no loosers and winners....just to ways to work! As a hardware based developer I would work on win-based workstations, just because the majority of all tech-related software runs on WIN only....;)

But that tells nothing regarding an enduser (which I still am)


Cheers
Paco


PS: @ Cliff: Much thanks for your honest and straight feedback to my statements - mostly very high complex stuff. Most other company wouldn't go that far with a so called simple customer.....it's highly appreciated in my book! :D Thank you!
 
Last edited:
@Cliff and Paco (and rest of you people), thanks to you sharing the advanced knowledge you apparently got regarding these things!

It´s highly appreciated from me at least. I try to learn "enough" about these stuff to be able to pin-point (and perhaps someday even solve) any problems I may get whenever it occurs. It´s very good to read about, considering that me and my band are building a studio for ourselves. We haven´t decided on everything regarding DAW and hardware etc, since the building process (walls, acoustic etc) as well as furniture aren´t all set yet. I´ve stated many times towards my mates that for me personally I´d like to avoid computers if I could, since in my experience they´re pretty much struggling or getting issues every now and then. Some of them have kinda replied: "well, we buy a MAC and it will sort out itself"...

Thanks to your conversation in this thread I´ve (unfortunately) realized that THAT doesn´t necessarily need to be the real truth. MAC and WIN both got their pro´s and con´s. For me personally, I want to have it really simple in our studio. A few but GOOD pieces of hardware, and just spend the time recording music (instead of solving computer/technology issues). Kinda like: straight to disk, play it right/capture the (creative) moment, and don´t mess around on screen (I pretty much don´t even want the screens there, I listen with my ears not my eyes).

Once again, I really think that this forum would benefit of a subpage regarding recording (of course with the axe as one but not necessarily the only peripheral piece). I´d love to read about tips and tricks all you people got in your studios regarding both your axe and other gears...

And once again, thanks for sharing your knowledge!

/Mike
 
What kinda guitars do you have?

PS: I feel sorry if I took your post the wrong way - we're supporting Dean, Mayones, Perez, Cole Clark, Merida & Aranjuez - also Luna and Tanglewood. I'm not doing much with the guitars or basses, since there are no big electronic issues....if you need anything, info etc. regarding these, sent a PM - answer will follow quickly :D
 
Last edited:
Back
Top Bottom