25 Mar
2009
25 Mar
'09
1:38 p.m.
Hi,
What do you guys think of the RME Digi96/8 PAD pci pro? How is the card
compared to an maudio delta 66 for example?
\r
25 Mar
25 Mar
2:48 p.m.
On Wed, Mar 25, 2009 at 12:34 PM, Grammostola Rosea <
rosea.grammostola(a)gmail.com> wrote:
Hi,
What do you guys think of the RME Digi96/8 PAD pci pro? How is the card
compared to an maudio delta 66 for example?
personally speaking, i would avoid this card. even though the RME products
that came after this are, in my opinion, peerless, this one came before RME
really understood how to do PCI bus-mastering. as a result it is an
inefficient h/w design that requires the device driver to do a bunch of work
that in the digi9652 and everything that followed was done by the hardware.
i am sure that the sound quality is good, probably even a little better than
the m-audio but certainly comparable - its just not up the same internal
design specs as RME's later products.
3:44 p.m.
Paul Davis wrote:
On Wed, Mar 25, 2009 at 12:34 PM, Grammostola Rosea
<rosea.grammostola(a)gmail.com <mailto:rosea.grammostola@gmail.com>> wrote:
Hi,
What do you guys think of the RME Digi96/8 PAD pci pro? How is the card
compared to an maudio delta 66 for example?
personally speaking, i would avoid this card. even though the RME
products that came after this are, in my opinion, peerless, this one
came before RME really understood how to do PCI bus-mastering. as a
result it is an inefficient h/w design that requires the device driver
to do a bunch of work that in the digi9652 and everything that followed
was done by the hardware. i am sure that the sound quality is good,
probably even a little better than the m-audio but certainly comparable
- its just not up the same internal design specs as RME's later products.
And what is actually even more visible to the user are the strange
buffer size constraints: Only the whole memory can be used, thus
nperiods*fragmentsize*samplesize is fixed. Each of those parameters has
only few possible values. For typical settings (32Bit/sample and ADAT
mode) this results in fragment sizes of either 64 or 256 samples (thanks
to the jack developers now at least nperiods can be decreased to values
below the hardware nperiods, though). Synchronizing and hardware routing
is much less flexible than with later RME products.
Personally I would avoid that card (I bought an RME Digi96/8 a few years
ago, everything said here holds for the whole Digi96/8 series).
Giso
10:18 p.m.
On Wednesday 25 March 2009 1:44:18 pm Giso Grimm wrote:
Paul Davis wrote:
I've use one for quite a while now. I have no complaints, but it is an old
design. The upside is that it works. The support for the newer hardware is
sketchy. Just because a driver may "support" it doesn't mean there are any
userspace tools for it. I built a box for a friend using the HDSP AES32 which
is supported by the MADI driver. I was able to get it to work, but barely. The
only software I could find for working with the matrix was a small CLI program
intended to be a demo, (By a guy who hasn't touched the MADI driver in years)
which for some reason got preserved in the SVN for pd of all places and just
happened to work on the AES the same as the MADI. Not exactly the most
intuitive interface for my friend who is totally clueless using a CLI shell.
So just because the design may be kinda poor doesn't mean it's not useful.
-Reuben
On Wed, Mar 25, 2009 at 12:34 PM, Grammostola
Rosea
<rosea.grammostola(a)gmail.com <mailto:rosea.grammostola@gmail.com>> wrote:
Hi,
What do you guys think of the RME Digi96/8 PAD pci pro? How is the
card compared to an maudio delta 66 for example?
personally speaking, i would avoid this card. even though the RME
products that came after this are, in my opinion, peerless, this one
came before RME really understood how to do PCI bus-mastering. as a
result it is an inefficient h/w design that requires the device driver
to do a bunch of work that in the digi9652 and everything that followed
was done by the hardware. i am sure that the sound quality is good,
probably even a little better than the m-audio but certainly comparable
- its just not up the same internal design specs as RME's later products.
And what is actually even more visible to the user are the strange
buffer size constraints: Only the whole memory can be used, thus
nperiods*fragmentsize*samplesize is fixed. Each of those parameters has
only few possible values. For typical settings (32Bit/sample and ADAT
mode) this results in fragment sizes of either 64 or 256 samples (thanks
to the jack developers now at least nperiods can be decreased to values
below the hardware nperiods, though). Synchronizing and hardware routing
is much less flexible than with later RME products.
Personally I would avoid that card (I bought an RME Digi96/8 a few years
ago, everything said here holds for the whole Digi96/8 series).
Giso
26 Mar
26 Mar
12:47 p.m.
On Wed, Mar 25, 2009 at 9:11 PM, Reuben Martin <reuben.m(a)gmail.com> wrote:
I built a box for a friend using the HDSP AES32 which
is supported by the MADI driver. I was able to get it to work, but barely.
The
only software I could find for working with the matrix was a small CLI
program
intended to be a demo,
does hdspmixer not work with this device/driver?
5723
days inactive
5724
days old
linux-audio-user@lists.linuxaudio.org
4 comments
4 participants
participants (4)
-
Giso Grimm -
Grammostola Rosea -
Paul Davis -
Reuben Martin