[LAU] Recording from S/PDIF

David Kastrup dak at gnu.org
Thu Nov 23 08:15:25 UTC 2017


Len Ovens <len-ODU3Ot18rIYsV2N9l4h3zg at public.gmane.org> writes:

>  On Wed, Nov 22, 2017 at 1:15 PM, David Kastrup
> <dak-mXXj517/zsQ at public.gmane.org> wrote:
>>
>> ​What could the Jack abstraction be?  Synthetic Midi signals could likely
>> fit pretty well but probably cannot be delivered sample-accurate.
>
> Sample accurate? Channel status is one _bit_ at a time and is 192 bits
> wide. That is, for one User Channel word or Channel status word to be
> derived from incoming data takes 192 samples of time. So jack at 64/2
> has better MIDI timing... (taken from ebu tech3250 and tech3250s1 both
> of which are free to download... unlike AES documents)

Well, perhaps "CDDB accurate" would have been a better moniker.  That's
essentially what it boils down to.

> I was unable to find how dat tape machines encode and send text and
> marker information.

Well, I'm up for experiments here.

> What I could find suggestes spdif is meant to be 20 bit and so it is
> possible the two least significant bits might be used for other
> purposes or that the dat is actually still 16 bit and the whole lower
> 8 bit byte may have information that would allow tighter timing. but
> 192 samples is the frame rate for most things so I expect that is what
> is used.

Sounds likely.  I'll do some 24bit recording and look for suspicious
patterns, but I doubt I'll have much success.

> With regard to more than 2 channels, any format I know of is not open
> or free. Even ADAT requires (does it still?) licencing. Certainly
> anything with the name Dolby attached is closed... that is the only
> reason they exist.

Ok, the format may be closed, but it still may be hand-me-through.
Probably not all that interesting.

-- 
David Kastrup


More information about the Linux-audio-user mailing list