Re: DICE II Firewire Driver Settings


"Mike Rivers" <mrivers@xxxxxxxxxxx> wrote in message
news:n5qRk.325$mi4.194@xxxxxxxxxxxxxxxxxxxxxxx
philicorda wrote:

The safe modes are to mitigate problems when other drivers (for video,
usb etc) spend too much time in a DPC call, and the kernel cannot run the
soundcard driver in time for it to service the audio buffers.

Misnamed, I think, but that sounds like a reasonable thing to do to help
people like me who don't know what a DPC call is and thinks a kernel is
where popcorn starts.

They solve this by using larger kernel side buffers = increased latency.
The larger buffer size means there can be a longer delay before the
driver runs.
I imagine the latency gets longer with the higher safe modes.

So, some other driver on your system is not real time safe, or else
perhaps a driver has made a non preemptable system call that must be
carried out before another driver can run.

So, is there anything I can do about this that will make it work better
other than to slow it down? I'll check out that Gearslutz reference to see
if there's anything I can use there. I may have actually run across that
in my Googling, but most of what I saw about the DICE was about the Alesis
I/O thing so I passed it up. The Zed is probably too new for anyone to
start talking about it yet.

The difference between the kernel side buffers and the normal audio ones
is that the audio buffers affect how many samples are in each buffer that
is sent to the soundcard, thus a larger buffer means less interrupts so
each interrupt is more likely to be serviced in time. A larger driver
kernel buffer affects how long another driver can spinlock before the
sound card driver must run.

I tried to find some programming information that I could interpret for you,
but I found nothing. I don't think the explanation is completely correct.
All ASIO buffers are in the kernel. "Kernel side buffers" is borrowed
terminology from Linux. The way this field works, people coin and borrow new
terms all the time. There's nothing wrong with this, but I can't find a
correspondence between the term and a programming scenario. However, there
are separate buffers set up by the firewire driver. They're all in the
kernel, along with the ASIO buffers.


I thought that Firewire was supposed to mitigate problems like that
because of its smarts to keep data flowing. At least that's one of the
arguments that people use in the Firewire vs. USB2 wars.

It is supposed to, but we have the Agere chip in the Mac and the DICE chip
in the peripheral as examples of things not working out. USB is software
driven. Firewire chips have substantial firmware. Some versions of the
Prolific chipset, revs B and C, can actually get firmware updates.

I had some initial problems with my DICEII based Presonus Firestudio. Not
working well at low latency and the occasional glitch. Getting a new TI
PCI firewire card improved matters. (And a VIA one too that did not work
so well.)

Yeah, that's one of the standard Firewire audio fix-its.
[snip]
I try to look at the best Firewire can do, not the worst. The fact is, there
is no other even semi generic alternative that provides anywhere near the
performance. Better alternatives exist in proprietary forms. Apogee, Emu,
RME, and Motu all offer proprietary alternatives.

If there is information that allows someone to predict success with
reasonable certainty -- such as using an Echo product instead of this, it's
a plus. If I were you, and had the responsibility of a reviewer, I would
call up Allen and Heath, and find out exactly what adapter chipset they
engineered to. Ifthat chipset is a $50 proposition, it's not a drawback. I
think that they should loan you a card so as to give the product the best
chance, or possibly you might decline to review. If you get "their" card,
and it still doesn't work, serious reservations may be in order.

Bob Morein
(310) 237-65112



.

Loading