F8n test reports:Line input set to -10 will still clip at about -5.5dBFS with a line source; I was using the TRS input but it should make no difference which. I know this because I was running tests with the F8n run in audio interface mode as an aggregate device with a MOTU 16A, feeding the same mono track to both devices to check sync stability. -10 setting gives a level that matches roughly across the 2 devices, and if I turn up the source to that level the F8n goes flatline. You can get more headroom with a phantom powered high output mic switching to line, but you don't get an additional 20dB as implied, this looks like an additional 15dB. Still useful. The quoted +24 dBu (at 0 dBFS, limiter ON) is not true with the limiter off!
the rest of this won't be of interest to most people here:Aggregate Device and audio interface mode: I wrote Zoom and the official response was:
This type of functionality may be possible, but is not officially supported.
Unfortunately, time code input and output are not available in audio interface mode.
I fired back a request to add word clock on the same BNC connectors as an option and/or allow time code in interface mode. I have no idea what practical obstacles exist there.
Lack of time code means it's free-sync, you can use 'drift correction' in the aggregate device, but there are latency differences to correct for AND 'drift correction' is a resampling of the input to compensate for clock drift. I found you could 'sorta' correct it but the top end waves around in the breeze on a phase scope and there's an occasional outright skip in the phase response so it doesn't seem like something you'd want to really run with. What does that all mean? You’d definitely not get away with putting half a stereo image into one device and the other half into another, nor would a pair of stereo captures brought in via different interfaces maintain their relationship to one another.
I ran the same test again without 'drift correction' checked: sounds like a phase shifter as the clocks work against each other. No hiccups, just audible drift.
I ran another dual mono test with the F8n sending time code to the MOTU 16A, and this was worse than I expected with significant drift within minutes, and the whole system had been warmed up several hours. The imported WAV file from the F8n did drop into the correct time spot, but that was the extent of the 'success'. This is a totally common problem with TV/film sync; every device is chasing the same start point from time code but the individual clocks are all doing their own thing and drift. There was also a latency difference to correct.
If a word clock option was added, these drift problems would disappear.
I ran another dual mono test with the F8n and 16A free synced, no time reference connection. Practically the same result, pretty significant drift in about the same amount.
I don't yet have a way to test with the F8n chasing time code from the 16A, and set for 'external audio clock sync' which is supposed to sync clock to time code. This is the closest apparent thing to a word clock sync.
EDIT: see next post for resultsThe auto-mixer function works pretty well, not as well as a Dugan auto-mix, but pretty good. It can be a bit chattery sounding on headphones if several people are between words and breathing loudly. I'd still be fine running a webcast with one.
Related to the above, the slate mic is useful in a pinch for some extra ambience, but ignores any auto-mix setting for the respective channel. Just assign it to a single channel. The only problem is when it's enabled, it ALWAYS goes to the headphones and blows up all monitoring choices. If you monitor off the main or sub outs you get a proper mix, and can set the slate at some lower fade level.