Zachary Seldess

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.

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. 

problems-with-presonus-firebox-in-windows

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.

> 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.

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.

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?

> 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.

>> 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.

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)

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 (?)

> allow the "weird" buffer sizes insisted upon by the Presonus driver?

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 (?)

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)


>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?

> > 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.

> >> 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.

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


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.

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. 

On 18 Dec 2006, at 15:18, Zachary Seldess wrote:

> 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.

That last figure _must_ be an integer - ergo 64 is the largest vector 

> 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 

Lawrence Casserley - lawrence@lcasserley.co.uk

Lawrence Electronic Operations - www.lcasserley.co.uk

Colourscape Music Festivals - www.colourscape.org.uk

>
> 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.

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.

Lawrence Casserley - lawrence@lcasserley.co.uk
Lawrence Electronic Operations - www.lcasserley.co.uk
Colourscape Music Festivals - www.colourscape.org.uk

Problems with Presonus Firebox in Windows