Problems with Presonus Firebox in Windows
If you happen to be looking for an affordable multi-channel firewire interface, and you want to work with FFT in Max on Windows, DO NOT BUY THE PRESONUS FIREBOX. All around it's a great device, EXCEPT!!! -- on Windows you have very little control over the io and signal vector sizes. The Firebox only allows you to change these in its control panel software and then only by the millisecond. The largest signal vector size that I've been able to use is 64 with an i/o vector size or 448 (when I set the Firebox to a 10 msec. latency). This is a big limitation when doing certain types of processing.
Anyone find a way to get around this issue - a driver hack perhaps?
I called Presonus and was told, basically, "yeah, that sucks. sorry". "and no, this issue won't be resolved - ever".
Fortunately, there are no such issues on Max in MacOSX.
Zachary
Yes, this is a problem - and it affects the Presonus Firepod also.
Their dismissive response is certainly not a way to win repeat
customers. Nonetheless - and this is not an ideal solution (they should
fix their driver!) - but in situations where I have needed a larger io
vector I have used the DirectX driver instead.
Yours truly,
David
formant wrote:
> If you happen to be looking for an affordable multi-channel firewire
> interface, and you want to work with FFT in Max on Windows, DO NOT
> BUY THE PRESONUS FIREBOX. All around it's a great device, EXCEPT!!!
> -- on Windows you have very little control over the io and signal
> vector sizes. The Firebox only allows you to change these in its
> control panel software and then only by the millisecond. The largest
> signal vector size that I've been able to use is 64 with an i/o
> vector size or 448 (when I set the Firebox to a 10 msec. latency).
> This is a big limitation when doing certain types of processing.
>
> Anyone find a way to get around this issue - a driver hack perhaps?
>
> I called Presonus and was told, basically, "yeah, that sucks. sorry".
> "and no, this issue won't be resolved - ever".
>
> Fortunately, there are no such issues on Max in MacOSX.
>
> Zachary -- http://www.zacharyseldess.com
> http://www.newmedialab.cuny.edu/projects
> http://www.intermediaartsgroup.com
P.S. - a related thought, and without at all retracting that Presonus
should allow more flexibility on the buffer sizes - why does Max not
allow the "weird" buffer sizes insisted upon by the Presonus driver?
(i.e. 529 samples, 441 samples, etc)
Yours truly,
David
David Ogborn wrote:
> Yes, this is a problem - and it affects the Presonus Firepod also.
> Their dismissive response is certainly not a way to win repeat
> customers. Nonetheless - and this is not an ideal solution (they should
> fix their driver!) - but in situations where I have needed a larger io
> vector I have used the DirectX driver instead.
>
> Yours truly,
> David
>
> formant wrote:
>> If you happen to be looking for an affordable multi-channel firewire
>> interface, and you want to work with FFT in Max on Windows, DO NOT
>> BUY THE PRESONUS FIREBOX. All around it's a great device, EXCEPT!!!
>> -- on Windows you have very little control over the io and signal
>> vector sizes. The Firebox only allows you to change these in its
>> control panel software and then only by the millisecond. The largest
>> signal vector size that I've been able to use is 64 with an i/o
>> vector size or 448 (when I set the Firebox to a 10 msec. latency).
>> This is a big limitation when doing certain types of processing.
>>
>> Anyone find a way to get around this issue - a driver hack perhaps?
>>
>> I called Presonus and was told, basically, "yeah, that sucks. sorry".
>> "and no, this issue won't be resolved - ever".
>>
>> Fortunately, there are no such issues on Max in MacOSX.
>>
>> Zachary -- http://www.zacharyseldess.com
>> http://www.newmedialab.cuny.edu/projects
>> http://www.intermediaartsgroup.com
Your typical 32-bit computer does not actually read memory one byte at a
time, but rather it reads four, so an accumulator down in the bowels
will actually grab four bytes from memory, even if you're asking for
only one byte (a 64-bit computer would grab 8 bytes as its minimum
atomic access). So anyone writing something as memory-access intensive
as a DSP app would ensure that every byte accessed under the covers is
actually needed and thus invite the compiler to fill data structures
with alignment to those bigger memory boundaries. That's why we avoid
vectors that are not mod-4 or mod-8. It's been nearly forever since I've
written a driver (or any other low-level code for that matter), and
those I did write were not memory-access intensive, but I'm pretty sure
it's still true that your answer is: efficiency.
I have no idea about the Presonus (maybe these sizes are not actually
happening in the context of their drivers, but are external (?)
--Bob Falesch
David Ogborn wrote:
> ...why does Max not
> allow the "weird" buffer sizes insisted upon by the Presonus driver?
> (i.e. 529 samples, 441 samples, etc)
try the asio4all driver.
www.asio4all.com
At 00.40 16/12/2006, you wrote:
>P.S. - a related thought, and without at all retracting that Presonus
>should allow more flexibility on the buffer sizes - why does Max not
>allow the "weird" buffer sizes insisted upon by the Presonus driver?
>(i.e. 529 samples, 441 samples, etc)
>
>Yours truly,
>David
>
>David Ogborn wrote:
> > Yes, this is a problem - and it affects the Presonus Firepod also.
> > Their dismissive response is certainly not a way to win repeat
> > customers. Nonetheless - and this is not an ideal solution (they should
> > fix their driver!) - but in situations where I have needed a larger io
> > vector I have used the DirectX driver instead.
> >
> > Yours truly,
> > David
> >
> > formant wrote:
> >> If you happen to be looking for an affordable multi-channel firewire
> >> interface, and you want to work with FFT in Max on Windows, DO NOT
> >> BUY THE PRESONUS FIREBOX. All around it's a great device, EXCEPT!!!
> >> -- on Windows you have very little control over the io and signal
> >> vector sizes. The Firebox only allows you to change these in its
> >> control panel software and then only by the millisecond. The largest
> >> signal vector size that I've been able to use is 64 with an i/o
> >> vector size or 448 (when I set the Firebox to a 10 msec. latency).
> >> This is a big limitation when doing certain types of processing.
> >>
> >> Anyone find a way to get around this issue - a driver hack perhaps?
> >>
> >> I called Presonus and was told, basically, "yeah, that sucks. sorry".
> >> "and no, this issue won't be resolved - ever".
> >>
> >> Fortunately, there are no such issues on Max in MacOSX.
> >>
> >> Zachary -- http://www.zacharyseldess.com
> >> http://www.newmedialab.cuny.edu/projects
> >> http://www.intermediaartsgroup.com
Thanks for the link bedosti.
Regardless of what the i/o vector size is, Max only allows you to select a power-of-two signal vector size that fits within the i/o vector size. It's strange though that when my i/o vector is 448 (with the Presonus), the largest signal vector available is 64 samples. I would expect the highest power-of-two that could fit inside 448 - that is, 256. But in fact, the highest signal vector available, under any setting in the Firebox, is 64 samples.
Besides, sig AND i/o size flexibility is needed for FFT.
And to follow up with the efficiency answer, having a power of two is what allows the first "F" in FFT (fast fourier transform) - from what I've read.
Zachary
On 18 Dec 2006, at 15:18, Zachary Seldess wrote:
>
> Thanks for the link bedosti.
>
> Regardless of what the i/o vector size is, Max only allows you to
> select a power-of-two signal vector size that fits within the i/o
> vector size. It's strange though that when my i/o vector is 448
> (with the Presonus), the largest signal vector available is 64
> samples. I would expect the highest power-of-two that could fit
> inside 448 - that is, 256. But in fact, the highest signal vector
> available, under any setting in the Firebox, is 64 samples.
448/64 = 7
448/128 = 3.5
448/256 = 1.75
That last figure _must_ be an integer - ergo 64 is the largest vector
size available.
>
> Besides, sig AND i/o size flexibility is needed for FFT.
>
> And to follow up with the efficiency answer, having a power of two
> is what allows the first "F" in FFT (fast fourier transform) - from
> what I've read.
That is indeed the case.
Best
L
Lawrence Casserley - lawrence@lcasserley.co.uk
Lawrence Electronic Operations - www.lcasserley.co.uk
Colourscape Music Festivals - www.colourscape.org.uk