Re: [QLab] O1V96i via USB

[Thomas Vecchione]

For basic shows yes.  I haven't taken true advantage of the multichannel capabilities yet though as I was just doing basic 2 channel playback on it.  Worked fine for me.

   Thomas

On Tue, Jul 3, 2012 at 6:37 PM, Robert Kaplowitz <robka...@gmail.com> wrote:

Has anyone taken the O1V96i for a test drive with QLab? Seems like 16 channels of USB audio into the console at 96k24 without an interface would be lovely... On paper, it still leaves you 24 channels of analogue (or ADAT) audio beyond the USB, making it quite competitive with the LS9...

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab

Follow Figure 53 on Twitter: http://twitter.com/Figure53

[Dave Tosti-Lane]

Hmm - I've had excellent performance from DANTE on the original 01V96 - 16
Dante with 16 USB could be very nice. The only concern is I presume you
have to use a Yamaha USB driver - I hope they do better with the audio
drivers than they've done with the MIDI over USB drivers.

Dave Tosti-Lane


On Tuesday7/3,Tuesday7/3:337 PM 3:37 PM, "Robert Kaplowitz"

[ra byn (robin)]

On Tue, July 3, 2012 5:37 pm, Robert Kaplowitz wrote:
> Has anyone taken the O1V96i for a test drive with QLab? Seems like 16
> channels of USB audio into the console at 96k24 without an interface would
> be lovely... On paper, it still leaves you 24 channels of analogue (or
> ADAT) audio beyond the USB, making it quite competitive with the LS9...

I literally purchased an 0/1V96i today for a local theater that will be
using it just as you describe.

In reading the manual for the 96cvm (older model) I don't see how you can
get a more flexible board for $2200. Add a $400 MY16AT card & some
external A/D/D/A adat boxes & it just gets stupid.

Once I have the system set up, I'd be glad to test certain Qlab / mixer
via USB situations as time allows for those interested.

More soon,

ra byn

[Andrew Harper]

I just did a production of Our Town with 15 channels of playback from Qlab using the USB audio on the O1v96i. It was flawless for me over the 3 week show. It showed up in Qlab as expected and never gave me an issue. I did not try 96k though--stayed in 48k.

Andrew Harper

On Jul 3, 2012, at 5:37 PM, Robert Kaplowitz wrote:

> Has anyone taken the O1V96i for a test drive with QLab? Seems like 16 channels of USB audio into the console at 96k24 without an interface would be lovely... On paper, it still leaves you 24 channels of analogue (or ADAT) audio beyond the USB, making it quite competitive with the LS9...
>

[Robert Kaplowitz]

Thanks for the answers! I think I'll give it a go...

<><><><><><><><><><><>
Thumb-typed without autocorrect... Sorry in advance.
-Rob Kaplowitz

[E Riley Casey]

A small gotcha, using the ADAT I/O limits you to 48k for all 16 channels.

Sent from my really handy glass and plastic Apple gizmo

[Chris Ashworth]

On Jul 3, 2012, at 8:25 PM, Andrew Harper wrote:

> I did not try 96k though--stayed in 48k.

We have speculated that the recently fixed bug in QLab (regarding honoring the sample rate of the audio device) may have some small place in history as the longest running real-world test of the Nyquist theorem. To our knowledge, although people (us included) believed they could set playback to something above 44.1K, no one ever noticed that in fact, they couldn't.

Kind of fascinating, I thought.

-C

[ra byn (robin)]

On Tue, July 3, 2012 8:21 pm, Chris Ashworth wrote:
> We have speculated that the recently fixed bug in QLab (regarding honoring
> the sample rate of the audio device) may have some small place in history
> as the longest running real-world test of the Nyquist theorem. To our
> knowledge, although people (us included) believed they could set playback
> to something above 44.1K, no one ever noticed that in fact, they couldn't.
>
> Kind of fascinating, I thought.

Are you saying that regardless of the native file sample rate, any audio
passing thru QLab is SRCed back to 44.1K?

If not, can you explain?

ra byn

[Andy Leviss]

On Tue, Jul 3, 2012 at 10:05 PM, ra byn (robin) <ra...@rabyn.com> wrote:
> On Tue, July 3, 2012 8:21 pm, Chris Ashworth wrote:
>> We have speculated that the recently fixed bug in QLab (regarding honoring
>> the sample rate of the audio device) may have some small place in history
>> as the longest running real-world test of the Nyquist theorem. To our
>> knowledge, although people (us included) believed they could set playback
>> to something above 44.1K, no one ever noticed that in fact, they couldn't.

--snip--

>
> Are you saying that regardless of the native file sample rate, any audio
> passing thru QLab is SRCed back to 44.1K?

No, not since the release of 2.3.7. He's saying, as he said here on
the list when announcing that update, that there was a bug in QLab
relating to a wonky quirk in how Core Audio works that, unbeknownst to
either users or devs, resulted in all audio in QLab getting converted
down to 44.1, then back up to the intended output rate. Or, as Chris
much more eloquently and exhaustively explained it at the time of
release:

On Mon, Feb 27, 2012 at 2:17 PM, Christopher Ashworth
<ch...@figure53.com> wrote:
> The sample rate bug deserves a detailed explanation:
>
> In the past we believed that QLab was converting all audio files to match the sample rate of the audio output device. We recently learned this was not true. (Neither for version 1 nor version 2.) It was in fact converting all files to 44.1K, and then converting that to the sample rate of the audio device.
>
>
> How could this error have happened, and how did we finally catch it?
>
> Prior to this update, QLab performed the following steps when initializing the audio signal flow:
>
> 1) Ask the device its current sample rate.
>
> 2) Tell the audio chain to convert file data to that sample rate during playback.
>
> You might imagine this would be the right set of steps. Turns out, it's not. The fixed version released today performs one additional step:
>
> 1) Ask the device its current sample rate.
>
> 1A) Tell the device to run at that sample rate. i.e.: "Yes, please really do run at the sample rate you are running at, and which you just told me you are running at."
>
> 2) (same as before)
>
> This somewhat astonishing revelation was discovered by Sean, while tracking down a small glitch at an audio cue loop point. The glitch appeared to be due to a small amount of aliasing at the loop point. After creating a test WAV file by hand and measuring its output sample by sample, he concluded there was sample rate conversion happening somewhere in the chain and eventually hunted it down to this one line of code.
>
> So, to sum up: until today, no audio from QLab could ever truly play at a resolution higher than 44.1K.
>
> Fixing this bug will address some special cases where the resulting aliasing was noticeable, such as the loop point example mentioned above. It will also (of course) allow QLab to play back audio at a higher sample rate.


--A

[ra byn (robin)]

On Tue, July 3, 2012 9:57 pm, Andy Leviss wrote:
> No, not since the release of 2.3.7. He's saying, as he said here on
> the list when announcing that update, that there was a bug in QLab
> relating to a wonky quirk in how Core Audio works that, unbeknownst to
> either users or devs, resulted in all audio in QLab getting converted
> down to 44.1, then back up to the intended output rate. Or, as Chris
> much more eloquently and exhaustively explained it at the time of
> release:

Thanks Andy,

I must of completely missed Chris' previous post about this matter.

ra byn