[PlanetCCRMA] multiple card synching

[Mark Knecht]

On Thu, 24 Feb 2005 16:44:17 +0100, Michele Spinolo
<michele.spinolo@tin.it> wrote:
> Hi Mark,
> 
> > I spotted this text: "In the DVD player you will find a clock line and
> > a data line for every channel pair. Each clock cycle means one bit of
> > audio data." When I first looked at the picture I thought there might
> > only be one clock since there's only one Actel FPGA. However there are
> > three cables driving this chip. (The rainbow cables.) It seems likely
> > to me that each cable carries it's own clock and the Actel chip is
> > operating on each on independently. If true (and I'm only guessing
> > about that) then each channel would be independent and unsynced.
> 
> thank you for the spot!
> I mailed dvdupgrades for more clarifications

To be very clear, I know nothing for certain about that board. I'm
jsut making a couple of guesses from the text and the pictures. It
will be interesting to hear what the designer says.
> 
> 
> > That's disappointing but it may not be his fault. Some of the card
> > manufacturers do not want to release full specs and some fo these
> > features are only available if you have full specs. (Or are willing to
> > use a PCI bus analyzer in a Windows box to find out what's going
> > on...)
> 
> I contacted the ICE1712 mantainer and author, but I had the feeling he was
> not interested adding this capabilities to ICE1712 driver.
> I'll give another try!

Please do. I guess I should write him also since I have an AP2496 and
would like all features to be supported. Also, I have no idea whether
the AP2496 supports spdif sync or not.

> 
> > RME and 'cheap' don't go together very well. The low end HDSP 9652 is
> > still about $600 each and it has three ADAT interfaces you wouldn't be
> > using. That's not the right solution.
> >
> > Actually it may not require an HDSP which is expensive and way more
> > card than you want. Possibly one of the smaller RME cards would work
> > using some sort of control language. Also, there are many well
> > supported 2 or 4 channel cards that have spdif inputs. Possibly one of
> > them would work? I have an AP2496 but I've never investigated whether
> > it can sync to spdif. If it did then 3 of them would be only
> > moderately painful I think.
> 
> Yes, I know RME and cheap don't go together, unluckily!:-)
> I meant cheap regarding RME cards, i.e. the cheaper RME card which could do
> the trick!;-)
> Is your suggestion for HDSP 9652 or HDSP 9632?

Really I cannot recommend either for your needs. The problem with all
currently produced RME cards that I know of is that the spdif input is
on a second card. You have to purchase the HDSP 9652 and use it with a
daughter card. The daughter card takes up a slot, so if you needed 3
spdif inputs you'de pay about $1800, you would use 6 slots inside your
PC, and you'd have no less than 9 ADAT ports supporting 72 channels of
ADAT audio data that you were not using. That seems like a terrible
waste to me!

A more likely scenario that I'd personally check into would be some
sort of exterrnal ADAT to spdif converter box. If you could find one
that meets your needs (3 spdif inputs) and that box did the conversion
of incoming spdif to ADAT then you'd only need a low end RME card with
ADAT. Unfortunately a quick Google only led to spdif to ADAT Optical
(also known as TosLink) which is standard for high end audio receivers
and, imagine, DVD players.
> 
> I was also thinking to build a ASRC (asynchronous sample rate converter)
> based on 3 AD1896 ASRCs, all driven by the same clock: this could be used to
> convert any sample rate coming for dvdupgrades board to a fixed sample rate
> and all 3 s/pdifs signal should then be synched.

That could work if you're up to the task, but in the end it would
likely take months and not save much money.

One last idea that comes to mind is there *may* be some work going on
to allow multiple copies of Jack to run at the same time with each
talkign to a separate sound card. If this was the case then you may be
able to run them unsynced, each handling it's own data, and then
recombine the data using software. In your case I think we know that
all three data channels will produce the correctl amount of data and
that it's just the transmission that is a problem. If this is the case
then there may be some way to handle much of this in software, again
assuming that you can find some low end spgif cards that are supported
under Linux.

Interesting problem... ;-)
> 
> I have many options but all expansive or dangerous for my hardware!:-(
> 

Yep!

Cheers,
Mark