[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