[sdiy] Help. S/PDIF -->hoontech ADSP24s and Yamaha O1Vs (non analog content)

[Magnus Danielson]

From: "Batz Goodfortune" <batzmanx at all-electric.com>
Subject: [sdiy] Help. S/PDIF -->hoontech ADSP24s and Yamaha O1Vs (non analog content)
Date: Thu, 03 Jul 2003 22:27:26 +0930

> Y-ellow all.

Hi Batz,

>          This is more a scream of desperation than anything so anyone who 
> knows not of these things or has no interest, you may graciously tune out 
> now.

For some odd-ball reason I didn't stop reading. I guess I disqualified myself
from stop reading by actually being interested in S/P-DIF and AES/EBU and have
actively stocked up on material related, so I guess we have to go pass this
checkpoint. (An infinit number of Synth-DIY members is knocking on my door to
tell me I disqualified from being uninterested about this _many_ years ago.)

> Right. Here's the problem. I've licked the physical layer problem. For 
> those who haven't heard it confirmed yet, OLD network card pulse 
> transformers make excellent S/PDIF or AES/EBU transformers...

They should.

> The problem is with the hoontech cards (so far I've only been testing with 
> the hoontechs) and the O1V. So if anyone has experience with either or both 
> then I'm in need of your experience. If not, and someone knows of a list or 
> newsgroup (That isn't Yahoo bassed because I can't use Yahoo for some 
> reason. that's a whole other story) where people who know specifically 
> about this stuff might congregate, I'd be interested.
> 
> I'm no techno-gymp. I've just designed a S/PDIF - AES/EBU network and got 
> it working, so I'm no stranger to these things, however there seems to be a 
> problem with one or both of the above items. Either the option I/O of the 
> O1V or the behavior of the Hoontech ST A-DSP24 card(s).
> 
> I've been using my DAT machine just to test links. When I feed it from any 
> of the Option I/Os (Yamaha YM8-AE AES/EBU I/O card) it tells me that it's 
> spitting out 48K sample rate and that it's copy protected. Say what? The 
> O1V's internal clock isn't spoze to be able to even do that.

I guess it is beleiving the subcode. See below.

> The history of this digital audio problem goes back two years as some here 
> already know so I'll skip the details, but essentially the game plan is to 
> distribute word clock from the option I/Os to cards such as the Hoontechs 
> and get them to lock to it. Then mix them all back digitally into the O1V. 
> Fair enough. You're supposed to be able to do this. (Apparently)

It can only do this "right" if the devices follow AES11.

> Assuming that what the DAT machine is telling me is some aberration, I 
> proceeded to test the hoontech card. The card appears to lock to the 
> incoming word-clock however there are those tell tail pops and clicks of a 
> slipping synch. Which means it's not really locking at all.
> 
> What it's doing is anyone's guess and that's where I am right now.
> 
> The O1V is NOT supposed to be able to do anything else but 44.1 from it's 
> internal clock so how could it be sending 48K and where did the copy 
> protect bit come from? I realize the latter could be the fact that the 
> subcodes for AES/EBU are different from that of S/PDIF but from memory, 
> they don't coincide with any of the lock bits. And since the basic data is 
> the exact same, then where's it getting it's 48K idea from?

The sub-code of AES/EBU and S/P-DIF is so grossly incompatible that even the
sample rate info is stuck in different places!

While the S/P-DIF receiver locks onto the bit-clock (they usually can anyway,
even if they are only supposed to do one rate) it then chews on the sub-code
and believes in what's in there instead of actually _MEASURE_ the bit-clock,
which is a bit messy in comparision to read it out of the sub-code.

Assuming that your 01V is tossing correct AES/EBU code for it's 44.1 kHz
stereo transmission, then it sets bit 6 and 7 of Octet 0 to 01. These same bits
is the mode bits for a S/P-DIF receiver. Looking in the IEC 60958-3 (which
covers the consumer version of IEC 60958, i.e. S/P-DIF) you see that the mode
bits (bit 6 and 7 in Octet 0) must be 00 and all other uses (i.e. 01, 10 and
11) is off-limits (for the consumer interface).

A propper way to handle this situation is to think that the interface receives
an un-defined sub-code. This is reflected by this sentences:

"The contents of bits 8 to 191 depend on the mode as indicated by bits 6 and 7.
 If not defined otherwise, the default value is "0"".

However, let's assume for a minute that it is not checked... that would mean
that the AES/EBU sub-code is being interprented as being propper S/P-DIF sub-
code.

Let's see now... the S/P-DIF interface beleives it's 48 kHz sampling. For it
to beleive that Octet 3 bit 0-3 (IEC 60958-3 names these bit 24-27) has the
binary value of "0100". In the AES/EBU subcode these same bits is used to
convey multichannel aspects, and then give the channel number (minus 1), so
it's basically saying channel 5 (and 6). This assuming that I got the bits
"right". Now, this assuming that bit 7 is right, i.e. is a 1, or else it is
all crap.

As for AES11 will two bits be used to convey the quality of the reference
signal. These two measly bits isn't in the same spot either. For an AES/EBU
sub-code, they are in octet 4 bit 0 and 1 where as for S/P-DIF they are in
Octet 3 bit 4 and 5. AES11 explains all the magic there is to that.

Anyway, I am not making propper sense on all this, but it might be a good idea
to have a more propper AES/EBU <-> S/P-DIF converter there, to deal with stuff
like sub-code as well.

> As for the hoontech, I have no idea. It must be locking at some level if 
> only for the fact that it DOES actually spit out audio, but what's 
> slipping? Worse still is the problem with the Hoontech Digital XG card. 
> Turns out that has an AC97 codec which means it rate converts anything it 
> receives up to 48K. Which means I can't daisy chain thru it to try and lock 
> those cards together.

You could have a signal integrity problem so that it looses sync every now
and then, most probably due to certain patterns.

If the Hoontech card spits out 48k I guess you are toast.

> Things would be so much easier with a 5 channel rate converter on the O1V's 
> option I/O, something that was assured me when I bought it but was lied to. 
> It's a long story and I've not made any sound in so long I think I may as 
> well just give up.
> 
> What I'm getting at is, was I also lied to about this stuff as well? Does 
> the Hoontech card actually lock or is it just flakey hardware like 
> everything else these days. Does the Yamaha desk have a bug in it? Is there 
> something peculiar about it's AES subcodes? It takes me so long to change 
> the network topology that to try anything else is just too daunting and 
> before I do, I'd like to know that I'm not just assuming this stuff works 
> but that it actually will. Or more to the point that it won't and not to 
> bother.

Please make a sub-code dump if you can. Dump the sub-code of your 01V, your
DAT and your Hoontech card and toss them over (with the intended type of
interface, sample rate at the time, other related settings, just to make sure
it makes sense). I should be able to interprent them. At least that should
help to possibly remove that as a reason for upset.

When they cooked up the S/P-DIF they fluked big-time IMHO.

Cheers,
Magnus