Interfaces audionumriques AES/EBU

par Yves GRENIER

Ingnieur de lcole Centrale, docteur en sciences physiques
Professeur lcole nationale suprieure des tlcommunications (ENST), Paris
Dpartement traitement du signal et des images

1. Interface audionumrique AES3 .......................................................... TE 5 420 - 2

1.1 Terminologie ................................................................................................ 3
1.2 Spcifications logiques ............................................................................... 3
1.3 Reprsentation lectrique ........................................................................... 4
1.4 Donnes auxiliaires ..................................................................................... 4
1.5 Informations portes par le Channel Status Data..................................... 5
1.6 Implantation du statut ................................................................................. 7
2. Standard AES42 ....................................................................................... 8
2.1 Objectifs........................................................................................................ 8
2.2 Alimentation fantme numrique.............................................................. 8
2.3 Commandes ................................................................................................. 8
2.4 Rapport et identification.............................................................................. 10
2.5 volutions..................................................................................................... 10
3. Spcifications lectriques ..................................................................... 11
3.1 Tensions, impdances et connectique ....................................................... 11
3.2 galisation.................................................................................................... 12
4. Synchronisation et horloges ................................................................. 12
4.1 Gigue ............................................................................................................ 12
4.2 Horloges de rfrence ................................................................................. 12
4.3 Synchronisation dhorloge AES42.............................................................. 13
5. Insertion audio en vido ........................................................................ 13
5.1 Interface vido numrique BT.656.............................................................. 13
5.2 Insertion de paquets audio ......................................................................... 14
5.3 Contrle des trames audio et vido ........................................................... 15
5.4 Difficults pratiques : insertion multiple et dsynchronisation ............... 16
6. Conclusion et repres............................................................................. 16
Pour en savoir plus ........................................................................................... Doc. TE 5 420

es signaux audio sous forme numrique, quand ils ne sont pas compresss,
L sont transmis sous forme de flux binaire continu (par opposition une trans-
mission par paquets) entre deux quipements. Afin de faciliter linterconnexion
des quipements, plusieurs organismes de normalisation et de standardisation
ont prconis divers formats de transfert des flux numriques de donnes audio.
Parmi ces organismes de normalisation, on trouve les suivants : Audio Engi-
neering Society (AES), European Broadcasting Union (EBU ou Union euro-
penne de radio-tlvision : UER), International Telecommunication Union (ITU
ou Union internationale des tlcommunications : UIT), Society of Motion
Picture and Television Engineers (SMPTE), International Electrotechnical
Commission (IEC ou Commission lectrotechnique internationale : CEI).
ces organismes, il conviendrait dajouter des organismes nationaux (par
exemple ANSI, DIN). Certaines normes existent sous plusieurs versions
quasiment identiques lorsquelles ont t adoptes simultanment ou succes-
sivement par plusieurs de ces organismes.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur TE 5 420 1
INTERFACES AUDIONUMRIQUES AES/EBU _________________________________________________________________________________________________

En premier lieu, nous nous intressons ici au standard dit AES/EBU qui cor-
respond une interface audionumrique deux canaux. Cette interface est
monodirectionnelle ; elle dfinit une liaison entre un metteur et un rcepteur.
Nous prsentons dabord sa version symtrique (au sens lectrique) utilisant
une paire de conducteurs. Cette version correspond au standard AES3.
Une variante importante de ce standard porte le numro AES-3id ; elle
correspond au mme type de liaison, mais sur cble coaxial, et donc non sym-
trique. Cette variante concerne essentiellement le contexte de la tldiffusion.
Dans le mme contexte, le signal audio est naturellement vhicul conjoin-
tement au signal vido. Nous tudions les standards qui prcisent linsertion du
signal audio AES/EBU dans un flux vido numrique. La norme a t dite par
lUIT-R sous la rfrence BT.1305.
Un troisime type de liaison driv du modle AES/EBU a t rcemment
normalis par lAES sous la rfrence AES42 ; ce standard concerne le transport
dun signal audionumrique issu dun microphone. Par rapport au standard
AES3, le standard AES42 ajoute principalement la possibilit denvoyer depuis
le rcepteur AES/EBU vers lmetteur (cest--dire vers le microphone) une
alimentation lectrique sous forme dune tension continue fantme. Elle ajoute
galement la possibilit denvoyer depuis le rcepteur (qui peut par exemple
tre une table de mixage) des commandes destines modifier le compor-
tement du microphone (ou de toute autre source numrique).
Nous couvrons ainsi les techniques permettant de vhiculer le signal sonore
seul, et celles permettant dassocier le signal audionumrique la vido num-
rique. linverse, nous excluons les techniques de tlcommunications permet-
tant de vhiculer ces signaux sur des rseaux. De mme, nous ne traitons pas
les diffrents formats de fichiers audio utiliss dans le stockage sur support
informatique, ni dans des liaisons avec ordinateurs (par exemple USB, FireWire).
Ce document se veut une introduction aux diverses normes, un panorama donc,
mais pas un rsum de ces normes. Lingnieur ayant les implanter doit se
reporter aux textes originaux des normes (voir [Doc. TE 5 420]).

1. Interface audionumrique (pulse code modulation ), cest--dire une succession dchantillons

AES3
Au dbut des annes 1980, la numrisation est entre de manire
exprimentale dans les studios denregistrement. Une interface
pour lchange de signaux audionumriques entre quipements a
merg. Sous le nom SDIF-2 (Sound Description Interchange
Format), cette interface propose par Sony est reprise par quelques
fabricants. Elle utilise trois cbles coaxiaux pour transmettre respec-
tivement le canal gauche, le canal droit et une horloge de synchroni-
sation (word clock, donc un cycle dhorloge par mot transmis). Cette
interface reste insuffisante sur trois points : les utilisateurs souhai-
taient un cble unique pour cette transmission ; la porte est limite
quelques mtres, alors que les utilisateurs souhaitaient au moins
une centaine de mtres ; et enfin, aucune donne numrique ou
description nest associe au signal.
En rponse ces limitations, lAES a prpar le standard AES3
dont la premire version date de 1985 (le premier brouillon publi
la t lanne prcdente). La version actuelle a t rvise en
1992, 1997 et dernirement en 2003. Entre 1997 et 1999, quatre
amendements ont t adopts. Selon le titre de ce standard, il
sagit dun format de transmission srie pour des donnes audio-
numriques sur deux canaux, codes linairement. Le format a
donc pour objectif de permettre la connexion de deux quipements
audionumriques. Le flux audio est principalement un flux PCM
numriques non compresss, acquis une cadence dchantillon-
nage fixe, et reprsents sur un nombre fixe de bits. Dautres
variantes existent dans le standard.
Le standard AES3 est aussi connu sous le nom dAES/EBU car il
a t publi conjointement par lEBU sous le numro Tech. 3250.
Par ailleurs, il a t normalis dans sa version de 1992 par lUIT
sous le numro UIT-R BS.647-2.
Un des modes de transmission que prvoit ce standard est sou-
vent dsign par SPDIF ou S/PDIF. Cet acronyme, qui signifie Sony/
Philips Digital Interchange Format, est celui que lon rencontre le
plus souvent, car il est suppos dsigner le standard de transmis-
sion audionumrique pour les quipements grand public . Mais
curieusement, il nexiste ma connaissance aucun document
dcrivant ce standard sous ce nom. Aujourdhui, quand un
constructeur fait rfrence au format SPDIF, dans la notice techni-
que dun quipement, il dsigne en fait la partie II du document
CEI 60958-3 (connu avant 1998 sous la rfrence CEI-958 1989-03).
On peut supposer que lappellation SPDIF provienne de documents
techniques propres aux deux constructeurs qui ont labor cette
interface au moment du lancement du disque compact, et que ces
documents, dabord internes, ont ensuite t proposs comme
draft ou brouillon de travail aux organismes de normalisation
concerns.
Nous prenons ici comme rfrence le standard AES/EBU,
cest--dire la version dveloppe conjointement par lAES et lEBU.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 5 420 2 Techniques de lIngnieur
_________________________________________________________________________________________________ INTERFACES AUDIONUMRIQUES AES/EBU
1.1 Terminologie
Commenons par dfinir quelques termes, comme le fait le stan-
dard. Ils concernent la manire dont les chantillons de signal sont
regroups entre eux et celle dont les informations auxiliaires sont
repres. Le flux audio ne prsente aucune interruption, mais il a
t choisi de le dcouper en units dnommes blocs. Cette
segmentation permet de structurer les informations associes au
signal audio. Le signal audio est transmis par trames ; chacune
correspond un instant dchantillonnage, et comme le signal peut
tre strophonique, la trame peut correspondre deux chan-
tillons, chacun correspondant une sous-trame. Nous avons donc
les dfinitions suivantes, en allant du dtail vers lensemble :
sous-trame (sub-frame) : cette structure fixe contient les infor-
mations audio et auxiliaires correspondant un chantillon dun
canal ;
trame (frame ) : cest lassociation de deux sous-trames, pour
constituer un chantillon de signal stro et les informations auxi-
liaires qui lui sont associes ;
bloc (block ) : il sagit dun groupe de 192 trames successives.
Ce groupe structure les donnes auxiliaires, comme nous le ver-
rons plus loin (bit de statut, 1.4.3) ;
prambule (preamble ) : pour distinguer le dbut de chaque
bloc, le standard introduit un prambule constitu de signaux
ayant une forme spcifique, utiliss pour la synchronisation. Ils
permettent aussi de distinguer les deux canaux au sein dune
mme trame.
Si lon interprte lassociation de deux canaux comme la consti-
tution dun signal strophonique, on devrait considrer les chan-
tillons dune trame comme reprsentant le canal gauche et le canal
droit. Cependant, le standard est plus gnral que cela : rien
noblige les deux canaux constituer les voies droite et gauche
dun signal strophonique, aussi les deux canaux prsents dans
une trame seront-ils considrs comme provenant dun canal 1 et
dun canal 2.
1.2 Spcifications logiques
Nous nous intressons dabord la manire dont sont organises
les informations logiques. Nous verrons plus loin ( 1.3) la descrip-
tion de linterface au niveau physique. Nous construisons dabord
la sous-trame, puis la trame, et nous organisons finalement les
blocs.
1.2.1 Sous-trame
Dans chaque sous-trame transite un chantillon de signal audio,
correspondant un canal. Pour la reprsentation de chaque chan-
tillon, 24 bits sont rservs, mais ils peuvent aussi contenir des
donnes auxiliaires. Deux possibilits sont envisages par le
standard :
la donne audio est seule prsente et elle occupe les 24 bits
disponibles ;
la donne audio est accompagne de donnes auxiliaires et
dans ce cas, elle ne peut disposer que de 20 bits, les 4 bits suppl-
mentaires vhiculant les donnes auxiliaires.
La sous-trame est constitue de 32 bits. Elle contient dabord un
prambule de 4 bits successifs (figure 1) en dbut de sous-trame.
Ensuite viennent les 24 bits de donnes, et enfin 4 bits VUCP ( 1.4).
Lors de la configuration de la liaison, si le nombre des bits du
signal est suprieur 20 (donc entre 21 et 24), il ne lui est pas pos-
sible de vhiculer des donnes auxiliaires. En revanche, si le nom-
bre de bits est infrieur ou gal 20, deux possibilits se
prsentent ; soit on incorpore des donnes auxiliaires, et 20 bits
restent disponibles pour le signal audio, soit on prolonge les don-
nes audio par des bits mis zro, concurrence de 24 bits. Dans
un cas comme dans lautre, si lchantillon audio a t cod sur
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur
0 3 4 27 28 31
Prambule LSB MSB V U C P
0 3 4 7 8 27 28 31
Prambule AUX LSB MSB V U C P
Figure 1 Donnes audio et auxiliaires dans une sous-trame
X Canal 1 Y Canal 2 Z Canal 1 Y Canal 2 X Canal 1 Y Canal 2
Sous- Sous-
trame trame
1 2
Trame 191 Trame 0 Trame 1
Dbut de bloc
Figure 2 Blocs, trames et sous-trames AES3
moins de bits que ce dont il dispose dans la liaison AES3, il doit
tre complt par des bits mis zro jusqu remplir les 20 ou
24 bits qui lui sont allous.
ces 24 bits recueillant le signal audio et les ventuelles donnes
auxiliaires, sajoute dans la trame un prambule, qui quivaut en
dure 4 bits ; nous verrons ( 1.3.2) que le codage du signal, qui
est effectivement transmis sous forme lectrique (ou lumineuse), ne
permet pas de considrer ce prambule comme un vritable paquet
de 4 bits. Il en occupe la place, mais joue un rle de synchronisation.
Le prambule est transmis avant les donnes audio de la sous-
trame.
Aprs les donnes audio, se situent 4 bits, dnomms VUCP
( 1.4) : V pour validit, U pour utilisateur, C pour channel status
(qui dsigne donc un bit dtat du canal) et P pour parit.
1.2.2 Trame
Une trame, nous lavons vu ( 1.1), se compose de deux
sous-trames. Le rle du prambule est de distinguer le canal 1 du
canal 2. On parle de prambule X pour le canal 1 et de prambule
Y pour le canal 2. Une trame est donc simplement constitue de
64 bits, par la concatnation de deux sous-trames (figure 2).
1.2.3 Bloc
Le bloc contient 192 trames, chacune comprenant deux
sous-trames. Le concept de bloc permet de regrouper 192 bits dtat
(channel status ) ou 192 bits utilisateurs. Ces bits forment donc
24 octets. Pour connatre le point de dpart du bloc, un troisime
type de prambule est dfini, le prambule Z, qui se substitue au
prambule X du canal 1 pour le premier chantillon du bloc.
Il y a donc dans le flot AES3 deux chelles de temps. Dune part,
on voit alterner les chantillons audio de deux canaux (reprs par
leur prambule X ou Y), la cadence dchantillonnage retenue.
Dautre part, une cadence 192 fois plus basse, le flux transporte
un paquet dinformation par canal. Ce paquet de 192 bits est trans-
mis bit par bit associ un chantillon audio. Le prambule Z
permet de se synchroniser sur ce paquet, afin den extraire les
informations.
TE 5 420 3
INTERFACES AUDIONUMRIQUES AES/EBU _________________________________________________________________________________________________
1.3 Reprsentation lectrique
On aura compris, la lecture de la description succincte qui vient
den tre faite que le flux de donnes AES se prsente comme une
suite de bits sans aucune interruption. Pour transmettre ce flux, il
faut videmment le reprsenter comme un signal lectrique, dont
la transmission doit se faire sur un lien srie. Un tel lien suppose
un unique conducteur pour transmettre le signal : il nest pas
possible de transmettre sparment les donnes, leur horloge, et
les signaux de synchronisation, ce qui supposerait trois
conducteurs, un par signal lectrique.
Comment contourner ce paradoxe ? Une solution astucieuse a t
adopte pour transmettre simultanment les symboles et les
signaux temporels (horloge et synchronisation), sur un seul
conducteur. Cette solution repose sur un codage de type biphase
mark.
1.3.1 Codage biphase mark
Dans ce codage, on convient pour transmettre des bits une
cadence fixe de faire basculer le signal lectrique codant chaque
transition entre bits. Cela permet de rcuprer le signal dhorloge.
Pour transmettre le bit 1, on fait galement basculer le signal cod
au milieu de lintervalle de temps ddi ce bit. En revanche, pour
transmettre un bit 0, on garde le signal constant sur la dure de
transmission du bit.
La figure 3 illustre ce type de codage. On voit de haut en bas
lhorloge dont un cycle reprsente la dure de transmission dun
bit, le signal de donnes ou source quil faut transmettre, et enfin
le signal lectrique transmis sur le canal, qui regroupe les infor-
mations des deux signaux au-dessus. On remarque que ce type de
codage est indpendant de la polarit du signal : le signal audio-
numrique transmis suivant le standard AES3 nest pas perturb
par un changement de polarit que peut provoquer par exemple
une erreur de branchement. Mais ce codage ne permet pas encore
de savoir o se trouve la limite dun mot. On ne peut pas en
extraire les trames ou sous-trames. Il faut pour y parvenir ajouter
une synchronisation, par le biais des prambules.
1.3.2 Prambules
Les bits de prambule portent linformation de synchronisation
et permettent de connatre aussi bien les limites des chantillons
que les limites des blocs. Pour transmettre ces bits de prambule,
le standard AES3 a choisi de violer la rgle associe au codage
biphase mark, et qui veut que le signal subisse une transition
chaque dbut de cycle dhorloge (un bit tant transmis dans un
cycle dhorloge).
On le voit sur la figure 4, le signal ne subit pas de transition la
fin du premier cycle dhorloge du prambule. Il devient donc
erron de parler de bit de prambule, comme nous lavons fait
jusquici. On peut seulement dire que le prambule dure quatre
cycles dhorloge, dure normalement consacre au transfert de
4 bits. Aprs la transmission du bit de parit de la sous-trame
prcdente, le signal subit une transition pour indiquer le dbut du
cycle dhorloge, mais il reste constant sur un cycle et demi, ce qui
indique un prambule. Lvolution du signal permet de dtecter le
type du prambule.
Aprs quatre cycles dhorloge, le prambule se termine par une
transition qui fixe le dbut du premier bit transmis dans le canal
suivant.
1.4 Donnes auxiliaires
La ncessit de transmettre des donnes numriques simulta-
nment au signal audionumrique simpose. Certaines donnes
sont ncessaires au rcepteur pour reconstituer correctement le flux
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 5 420 4 Techniques de lIngnieur
Horloge
1
0
Source
1
Canal
0
Figure 3 Exemple de codage biphase mark
Horloge
Parit LSB
Prambule X
Prambule Y
Prambule Z
Absence de transition
Figure 4 Les trois prambules AES3 violent deux fois
la rgle biphase mark
audio. Par exemple, le rcepteur doit savoir si le signal est mono-
phonique ou strophonique, sil est praccentu, sur combien de
bits il est chantillonn. Dautres donnes, sans tre ncessaires
pour la reconstruction du signal, sont pourtant indispensables
lexploitation du flux de donnes. Par exemple, dans une rgie,
pouvoir extraire du signal une tiquette donnant son origine permet
dviter des erreurs de branchement. Le standard dcrit linsertion
de ces informations sous forme de blocs de 192 bits transmis
raison dun bit par chantillon audio. Quatre bits diffrents, nots
V, U, C et P, doivent tre transmis.
Comment ces bits se situent-ils par rapport aux 4 bits auxiliaires
qui peuvent tre transmis dans chaque sous-trame si le signal audio
est reprsent sur 20 bits au maximum ? Le standard ne dit rien sur
ce point ( part un exemple situ en annexe, dinsertion dun signal
dinterphonie, donc de la parole, chantillonn sur 12 bits une
cadence un tiers de celle du signal audio). La signification de ces
4 bits auxiliaires peut tre librement fixe par lutilisateur. Dans un
contexte de diffusion tlvisuelle, le son tant reprsent sur
20 bits, ces 4 bits auxiliaires sont encore disponibles. En revanche,
dans le contexte de la musique, on peut considrer ces bits auxi-
liaires comme appartenant au pass, car lenregistrement du signal
audio sur 24 bits sest maintenant gnralis en milieu profession-
nel et se rpand rapidement dans le grand public avec des botiers
externes dacquisition ou de restitution du son pour micro-ordina-
teurs, qui travaillent sur 24 bits 96 kHz.
La disparition de ces 4 bits auxiliaires ne sonne pas le glas de la
transmission de donnes numriques au gr de lutilisateur, car
parmi les 4 bits VUCP, lun deux, le bit U, est rserv lutilisateur.
1.4.1 Bit V
Ce bit est dit de validit. Si le bit de validit est zro, il indique
que lchantillon audio est valide, cest--dire quil peut tre converti
_________________________________________________________________________________________________ INTERFACES AUDIONUMRIQUES AES/EBU
en valeur analogique. Ce bit est mis 1 lorsque lchantillon audio
est invalide. Le standard reste muet sur la manire dont le rcepteur
doit traiter un flux audio dans lequel de temps autre se trouvent
des chantillons non valides.
1.4.2 Bit U
Ce bit est laiss la disposition de lutilisateur pour quil y stocke
des informations quil a dfinies.
Nota : par utilisateur, il faut en ralit comprendre lquipement metteur.
Toute libert lui est laisse pour cela. Mais il peut aussi choisir
dadhrer un des deux standards AES qui lui proposent une sp-
cification pour ce bit U. Le standard AES18 dcrit une mthode
pour formater le flux form par la succession des bits de donnes
U, en sinspirant du protocole HDLC (High-level Data Link Control).
Le standard AES42 dcrit une autre utilisation du bit U.
Dans le premier cas (AES18), il sagit dun complment facultatif
au standard AES3, dans lequel le canal fourni par le bit U est utilis
comme un canal srie, sans tenir compte des limites de bloc, car
le standard AES18 dfinit un autre signal de synchronisation
lintrieur du flux de bits transmettre. Le bit U fournit donc un
canal de transmission par paquets, qui est totalement indpendant
du flux audio.
Dans le deuxime cas, on peut considrer le standard AES42
comme une extension du standard AES3, et linformation code
dans le bit U est fortement contrainte par le standard AES42. Elle
se prsente sous forme de blocs de 192 bits (ou 24 octets) synchro-
niss avec le prambule Z. Nous reviendrons sur ces deux implan-
tations au paragraphe 1.5.6.
1.4.3 Bit C
Ce bit permet de constituer un bloc de 192 bits constituant le
channel status. Nous dsignons parfois ce bloc par bloc de
statut , mais cette dnomination nest pas reconnue dans le stan-
dard. Limportance du bloc de statut nous amne lui consacrer le
paragraphe 1.5. Signalons ici que ce bloc vhicule les informations
indispensables au rcepteur pour interprter correctement le flux
de donnes audio. Il permet de coder ces informations, comme le
fait par exemple le bloc den-tte dans un fichier audio. Alors que
dans le fichier, le bloc na pas besoin dtre rpt, dans un flux
audio continu comme le flux AES/EBU, il est ncessaire de rpter
sans cesse linformation, afin que le rcepteur puisse lextraire,
quel que soit linstant o il se branche sur le flux audio.
lintrieur de chaque bloc, le bit de statut de chaque canal
constitue un tableau de 192 bits, ou encore de 24 octets se rpar-
tissant tel que dcrit dans le tableau 1. (0)
Tableau 1 Contenu des 24 octets du canal C
(channel status)
Octets Usage
05 Informations sur le signal
69 Nom du canal dorigine (4 caractres ASCII)
10 13 Nom du canal de destination (4 caractres ASCII)
14 17 Numro dchantillon (32 bits, LSB en tte)
18 21 Code horaire (32 bits, LSB en tte)
22 Bits de validit des octets prcdents
23 Code correcteur derreur (CRCC)
LSB : least significant bit.
CRCC : cyclic redundancy check code.
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur
Les six premiers octets (numrots 0 5) sont consacrs aux
informations relatives au signal lui-mme, tant dans son origine
que dans la manire dont il est reprsent lintrieur du flux
audio AES/EBU ( 1.5).
On trouve ensuite dans les octets 6 9, un code (ASCII ou ISO 446)
de quatre caractres qui permet lutilisateur de prciser lorigine de
ce signal. De la mme manire, les quatre octets suivants (numrots
10 13) permettent de dfinir la destination de ce signal. Le standard
nest pas plus prcis sur ce point et laisse toute latitude lutilisateur
pour choisir ces codes alphanumriques. Les octets 14 17 permettent
de reprsenter la numrotation des chantillons audio. Ils sont
complts par les quatre octets suivants qui permettent de sauve-
garder un code horaire. Lavant-dernier octet indique quels sont les
octets valides dans la description prcdente ; le dernier octet constitue
un code correcteur derreur.
1.4.4 Bit P
Ce bit est un bit de parit. Il est choisi de manire telle quil y ait
un nombre pair de 1 sur les bits 4 31, et par consquent galement
un nombre pair de 0 sur ces mmes bits. Rappelons que les bits
de prambule constituent les bits 0 3. Leur structure particulire
les exclut du contrle de parit.
1.5 Informations portes
par le Channel Status Data
Le standard AES3 dcrit de manire minutieuse la signification de
chaque bit dans les six premiers octets du bloc de statut. La lecture
attentive des nombreux tableaux qui composent cette description
simpose lingnieur charg dimplanter le standard AES3. Mais
cette lecture est aride et fastidieuse. Nous allons essayer ici den
donner une interprtation plus synthtique en discutant les types
dinformations insrs dans le bloc de statut, leur origine et leur
reprsentation.
1.5.1 Mode professionnel ou consommateur
Le standard AES3 implante en ralit deux modes diffrents. Lun
est le mode professionnel, cest lui qui est vritablement dsign
sous le nom de norme AES/EBU. Lautre mode est le mode
consommateur, cest lui qui est dsign sous le nom de SPDIF pour
faire rfrence au format introduit par Sony et Philips, et dont la des-
cription plus complte (en particulier au niveau lectrique) se trouve
dans la norme CEI 60958-3. Un rcepteur au standard AES3 na pas
tre compatible avec un metteur la norme CEI 60958-3, pas plus
quun rcepteur la norme CEI 60958-3 na lobligation dtre
compatible avec un metteur au standard AES3. Le bit qui permet
de choisir le mode de fonctionnement est donc important, car il per-
met au rcepteur de savoir sil doit ou non dcoder les informations
du status bit.
Dans le bloc constitu par le status bit, cest le premier octet qui
porte les informations de format. Le tout premier bit (bit 0 de
loctet 0, qui est associ au prambule Z) dfinit le mode. Si ce bit
est positionn 1, il sagit du format professionnel (AES/EBU) ; en
revanche, si ce bit est positionn 0, tout le bloc est cod confor-
mment au standard dit SPDIF.
1.5.2 Type de donne et taille des mots
Le rcepteur du flux audio doit savoir comment interprter les bits
audio. Le flux peut tre un flux dchantillons PCM, linairement
quantifis, ou bien cela peut constituer un flux compress multi-
canal (dans un codage MPEG, DTS, AC3...). Dans ce dernier cas, il
faut indiquer quel type de compression sapplique. Le bit 1 de loctet
0 permet de savoir si le flux audio est de type PCM ou autre : dans
le cas PCM, le bit vaut 0, mais lorsque le bit est mis 1, le signal
peut avoir toute autre reprsentation (quantification non linaire ou
TE 5 420 5
INTERFACES AUDIONUMRIQUES AES/EBU _________________________________________________________________________________________________
signal compress, par exemple). Le standard AES/EBU nen dit pas
plus, ce qui est conforme sa logique et son orientation vers le
contexte professionnel. En revanche la norme CEI 60958-3 prvoit
plus de dtails sur les signaux compresss.
Quant la taille des mots audio, on aurait pu sattendre ce que
le standard la code dans la reprsentation binaire la plus simple, ce
qui supposerait 5 bits, permettant de spcifier une taille de mots
entre 1 et 32 bits. Mais ce nest pas le choix qui a t retenu. Au
dbut des annes 1980, quand la premire version du standard a
t labore (sa publication en 1985 suppose que le travail de stan-
dardisation ait dbut vers 1982 ou 1983), les meilleurs conver-
tisseurs analogique-numrique se situaient entre 16 et 18 bits. Cest
probablement ce contexte qui a amen prvoir 20 bits pour la don-
ne audio et 4 bits auxiliaires vous devenir ensuite des bits de
faible poids dans une reprsentation tendue 24 bits. Le choix
entre un champ de 20 bits ou un champ de 24 bits pour la donne
audio aurait pu conduire la rservation dun seul bit, mais le stan-
dard a t beaucoup plus gnreux, en allouant 3 bits (bits 0 2 de
loctet 2) ce choix, ltendant du coup au-del de lalternative, en
distinguant quatre cas :
un champ audio de 24 bits (code 001) ;
un champ audio de 20 bits avec 4 bits auxiliaires coordonns
(code 010) ;
un champ audio de 20 bits seul, les 4 bits auxiliaires inutiliss
sont mis zro (code 000) ;
un champ audio dans un format diffrent, que lutilisateur
spcifie et dcode (code 011).
Les quatre autres choix laisss disponibles par lallocation de
3 bits sont rservs pour un hypothtique usage futur.
Et si le signal nest reprsent que par 16 bits, quen est-il ? Le
standard prvoit ce cas dans une logique complmentaire du choix
prcdent : les 16 bits sont vus comme 20 bits dont 4 ne sont pas
utiliss. De mme, 22 bits seraient vus comme 24 dont 2 sont inem-
ploys. On utilise 3 bits (bits 3 5 de loctet 2) pour reprsenter ces
diffrents cas. Par exemple, la valeur 001 indique quun bit de poids
faible est inemploy, et donc une longueur de mot qui est soit 19,
soit 23 bits suivant le choix prcdent. Cette logique est a priori
assez simple, mais comme le standard AES3 prvoit toujours une
valeur par dfaut, la valeur 000 ne signifie pas quaucun bit de poids
faible nest inemploy (ce qui correspond un chantillon sur 20 ou
24 bits), mais plutt que lmetteur a choisi de ne pas spcifier
combien de bits sont employs. cause de cette particularit, pour
indiquer que tous les bits sont employs, il faut spcifier ici le code
binaire 101. Les autres codes binaires (110 et 111) ne doivent pas tre
utiliss, car le standard les rserve pour un usage futur. Comme un
constructeur allemand de consoles de mixage (StageTec) a dj
dpos un brevet et mis sur le march des convertisseurs sur
28 bits, et que par ailleurs les logiciels de mixage prvoient dj des
chantillons sur 32 bits, on peut sattendre des rvisions dchi-
rantes et polmiques du standard AES/EBU dans quelques annes.
1.5.3 Praccentuation et alignement
Mme en transmettant un signal PCM, il peut tre ncessaire de
corriger ce signal au niveau du rcepteur. Le standard AES/EBU
prvoit donc que le signal puisse tre praccentu. Deux types de
praccentuation sont prvus par le standard :
une praccentuation de 50/15 s, dans laquelle on applique
au signal un filtre ayant un ple avec une constante de temps de
50 s et un zro avec une constante de temps de 15 s ;
une praccentuation conforme la recommandation J17 de
lUIT-T.
Le choix du type de praccentuation sinsre dans le bloc de sta-
tut (bits 2 4 de loctet 0) en respectant la logique de la valeur par
dfaut (000) qui signifie que lmetteur ne prcise pas le type de
praccentuation, le rcepteur est alors libre de choisir la dsaccen-
tuation quil applique. Lmetteur indique avec une valeur (100)
quil na appliqu aucune praccentuation, obligeant le rcepteur
ne pas appliquer de dsaccentuation. En plus de ces deux valeurs
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 5 420 6 Techniques de lIngnieur
Amplitude (dB)
20
J 17
15
10
s
15
5 5 0/
0
5
20 50 100 200 500 1000 2000 5000 20 000
f (Hz)
Figure 5 Courbes de praccentuation
et des valeurs spcifiant une praccentuation de 50/15 s (code
110) ou J17 (code 111), quatre valeurs sont rserves pour un usage
futur. La figure 5 montre les deux courbes de praccentuation pr-
dfinies.
Une autre difficult que rencontrent les ingnieurs du son dans
les studios ou les rgies est lalignement des signaux. Lors du
mixage ou de la concatnation de plusieurs programmes, ling-
nieur du son ajuste les niveaux en fonction dun niveau de rf-
rence, le 0 dB. Il est indispensable que tous les signaux adoptent
une rfrence commune. Malheureusement, plusieurs rfrences
existent, et il faut indiquer celle qui est utilise. Il est surprenant de
constater que cest assez tardivement, dans lamendement 4 de
1999, que le standard AES3 prcise comment noter la rfrence qui
a servi dans chaque signal. Deux rfrences peuvent tre codes
dans les bits 6 et 7 de loctet 2 du bloc de statut : lalignement sur
le niveau SMPTE RP155 (qui situe le niveau de rfrence 20 dB
en dessous de lamplitude maximale reprsentable sur chaque mot
chantillonn) ou le niveau EBU R68 (avec une rfrence qui est
18,06 dB en dessous de lamplitude maximale).
1.5.4 Frquence dchantillonnage
Si les signaux sont transmis en temps rel par linterface, on peut
imaginer quil soit inutile de prciser la frquence dchantillon-
nage, puisque celle-ci se dduit aisment de lhorloge insre dans
le flux binaire. Mais il a paru plus simple dinclure cette information
dans le bloc de statut, ce qui permet au rcepteur dafficher cette
frquence, sans avoir la mesurer.
Le standard navait pas prvu dans sa version initiale les vo-
lutions de cette frquence dchantillonnage avec les progrs des
convertisseurs analogique-numrique et numrique-analogique.
Linformation de frquence est donc code dune manire complexe,
par ajouts successifs au fil des mises jour du standard. lorigine,
trois frquences dchantillonnage ont t prvues : 32 kHz,
44,1 KHz et 48 kHz. En ajoutant la valeur par dfaut (qui autorise le
rcepteur fixer la frquence de son choix), on obtient quatre
valeurs codes sur les deux bits 6 et 7 de loctet 0.
Mais la frquence de 96 kHz est depuis apparue dans les studios
denregistrement o la frquence de 48 kHz tait juge insuffisante
pour fournir la qualit de son recherche. Lamendement 3 de 1999
a donc introduit la possibilit de transmettre sur une liaison AES3
un canal unique la frquence double en utilisant les deux canaux
initiaux. Ainsi, une liaison AES3 fonctionnant avec une cadence de
trames de 48 kHz peut aussi bien transmettre un signal stro-
phonique 48 kHz quun signal monophonique 96 kHz. Pour tre
plus prcis, dailleurs, il faut aussi indiquer si ce canal frquence
double est un canal monophonique, ou bien le canal gauche ou
encore le canal droit dun couple strophonique. Les bits 0 3 de
loctet 1 dans le bloc de statut jouent alors un rle un peu hybride.
Initialement prvus pour prciser le type de canal (soit monopho-
_________________________________________________________________________________________________ INTERFACES AUDIONUMRIQUES AES/EBU
nique, soit strophonique, soit encore deux canaux sans relation
entre eux), ces bits se voient ainsi dots dun rle dindicateur de
frquence dchantillonnage double. On peut dire qu ce moment-
l, le standard entrine un usage dj bien rpandu dans les studios
et chez les fabricants.
Mais cela sest avr insatisfaisant. Si une cadence dchantillon-
nage plus leve devenait dusage courant, il fallait que linterface
AES3 change elle aussi de cadence, pour conserver son caractre
strophonique. Dans le mme amendement, lAES a donc anticip
sur les cadences suivantes en prvoyant une cadence qui puisse
tre double, quadruple, mais aussi divise par 2. Ainsi par rapport
au 48 kHz, cela ajoute 24 kHz, 96 kHz et 192 kHz. O loger cette infor-
mation dans le bloc de statut ? Cest loctet 4 qui a t choisi pour
cela, dans les bits 3 6. La cadence de 32 kHz tant tombe en
dsutude, les frquences codes dans ces bits sont 24, 96, 192,
22,05, 88,2 et 176,4 kHz. Le standard prcise dailleurs que ce choix
nest pas incompatible avec le fait de passer un canal mono-
phonique cadence double (est-ce pour prvoir une ventuelle
extension 384 kHz ?).
Ajoutons un mot sur le bit 7 de ce mme octet 4, dont lemploi
peut paratre anecdotique, mais est bien reprsentatif de la comple-
xit des situations que doit prendre en compte un standard. La tl-
vision NTSC utilise une cadence de trames vido qui nest pas de
30 Hz, mais plus prcisment de 30/1,001 Hz. Pour quun signal
audio puisse sinsrer dans un flux vido numrique de type NTSC,
il faut effectuer de savantes dcoupes dans les blocs audio et
vido ( 5.3). Cette dcoupe se simplifie videmment si lon modifie
lgrement la cadence dchantillonnage audio, dans ce mme rap-
port de 1/1,001, et cest pourquoi le standard AES3 a prvu, dans
lamendement 4 de 1999, un bit pour signaler cette situation.
1.5.5 Monophonie, strophonie, multicanal
lorigine, le standard AES3 avait prvu que les deux canaux de
la liaison puissent servir transmettre un canal strophonique,
mais aussi un canal monophonique, ou deux canaux dits primaire
et secondaire (cela peut correspondre par exemple aux signaux M
et S dun couple strophonique M+S). Il a fallu tendre cette
situation la transmission dans les deux canaux dun unique signal
mais cadence double. Et comme le son multicanal (surround, 5.1,
voire plus) se dveloppe, lun des amendements de 1999 a tenu
compte de ces nouveaux dveloppements. Les bits 0 3 de loctet
1 tant saturs, il fallait loger ailleurs les informations de multicanal.
Cest loctet 3 du bloc de statut que revient le rle de prciser
quel canal est transmis. On ne peut pas dire que le standard soit par-
ticulirement simple. Il prvoit en effet deux manires de spcifier le
numro du canal. Si le bit 7 est mis zro, la numrotation est
directe. Les 7 autres bits de loctet permettent de numroter
128 canaux diffrents (entre 1 et 128, ce qui veut dire que lon ajoute
1 la valeur lue dans les 7 bits, qui, sinon, serait entre 0 et 127). Si, en
revanche, le bit 7 est mis 1, on se place dans un mode de numrota-
tion indirect o les 7 autres bits sont dcoups en deux groupes : un
groupe de 3 bits dfinit le mode de numrotation et un groupe de
4 bits dfinit un numro de canal parmi 32. Quand cet amendement a
t adopt en 1999, le standard prcisait que la signification de ces
modes de numrotation tait en cours dlaboration. Mais en 2003,
le standard a t confirm, ce qui signifie dans les procdures de
lAES, entre autres, que les amendements prcdents sont dfinitive-
ment inclus dans le standard ; or la phrase disant que ces modes
sont en cours dlaboration est reste inchange. En ltat, ce mode
de numrotation des canaux nest donc pas encore exploitable.
Pour compliquer encore le tableau, le standard a dcid de tolrer
une pratique de certains constructeurs dont les quipements ne
lisent le numro du canal que dans lun des deux blocs de statut
(rappelons que dans le flux AES, chaque canal vhicule son propre
bit C et a donc un bloc de statut propre). Dans ce cas, il faut mettre
dans les deux canaux du flux AES3, le mme numro de canal, et
implicitement ce numro est celui du premier canal du flux AES,
lautre canal ayant le numro immdiatement suprieur.
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur
1.5.6 Nature des donnes utilisateur
Le standard AES3 prvoit que le bit U de chaque sous-trame
puisse vhiculer une information spcifique au libre choix de luti-
lisateur (ou plutt lquipement metteur). Comme lutilisateur peut
choisir dadhrer certains standards pour exploiter le canal
constitu par la succession de ces bits U, il est souhaitable quil
puisse indiquer son choix. Les possibilits retenues sont :
le canal U est exploit par blocs de 192 bits synchrones du
bloc de statut et donc initialiss par le prambule Z (cest ce type
de codage qui est retenu dans le standard AES42, 2) ;
le canal U forme un flot continu, ayant son propre dispositif
de synchronisation, conformment au standard AES18 ;
le canal U est cod conformment au format de donnes
utilisateur dfini par le standard CEI 60958-3, cest--dire au format
dit SPDIF ;
le canal U est cod suivant un format spcifique lutilisateur.
1.6 Implantation du statut
On a vu que chaque paquet de bits lintrieur du bloc de statut
a une valeur par dfaut. Ce choix dlibr au niveau du standard
rend parfois le dcodage des informations un peu complexe. En
contrepartie, avoir fait ce choix laisse une grande latitude au
fabricant qui implante le standard AES3 dans un produit. Il peut en
effet choisir de sen tenir uniquement aux valeurs par dfaut, ou au
contraire donner une description complte du bloc de statut. Trois
niveaux dimplantation sont prvus par le standard AES3 :
implantation minimum : seul le premier bit (octet 0, bit 0) est
mis 1, ce qui indique le mode professionnel. Tous les autres bits
doivent tre positionns leur valeur par dfaut ;
implantation standard : le premier bit (octet 0, bit 0) est mis
1 (mode professionnel). Lutilisateur (cest--dire en fait lquipe-
ment qui fournit le flux audionumrique sa sortie) encode
obligatoirement les octets 0, 1, 2 et 23 (CRCC) ;
implantation tendue (enhanced ) : les octets dfinis au
niveau prcdent (implantation standard) le sont aussi ce
niveau ; de plus, les autres octets sont laisss au choix de lutilisa-
teur.
Le document dinformation AES-2id discute dans le dtail la
manire dont les quipements traitent les informations situes
dans le status bit. Il prvoit en particulier plusieurs classes dqui-
pement (A, B1, B2, B3, C1 et C2), ce qui permet de savoir comment
lquipement manipule les diffrents flux audio et de donnes :
A : lquipement transmet sans aucun dcodage les flux
audio et de donnes ;
B1 : lquipement dcode les donnes audio, mais pas les don-
nes du channel status quil ne transmet pas (ce type dquipement
nest pas recommand car il perd entre autres les informations rela-
tives la praccentuation) ;
B2 : cet quipement dcode le channel status, le traite si
ncessaire mais ne le transmet pas ;
B3 : cet quipement dcode le channel status, le traite si
ncessaire et le transmet ;
C1 : il sagit dun quipement uniquement rcepteur, sans sortie
numrique (par exemple, un convertisseur numrique
analogique) ; lquipement ne dcode que le flux audio ;
C2 : comme un quipement de classe C1, un quipement de
classe C2 est uniquement rcepteur ; en revanche, il dcode et
traite aussi bien le flux audio que le flux de donnes.
Ce mme document dinformation AES-2id propose un tableau
que chaque constructeur devrait joindre lquipement quil vend,
mais il est regrettable que pratiquement aucun ne le fasse. Ce
tableau indique prcisment les emplois des bits C, V et U, que
lquipement soit metteur ou rcepteur.
Exemple : pour un quipement de type B3, le tableau indique si
lquipement modifie les bits quil transmet.
TE 5 420 7
INTERFACES AUDIONUMRIQUES AES/EBU _________________________________________________________________________________________________
2. Standard AES42
En 2001, lAES a publi un nouveau standard, sous le numro
AES42. Il est intitul Interface numrique pour microphones et a
pour base le standard AES3, quil complte dans le sens remontant.
Il permet en effet lquipement qui reoit le flux AES3 provenant
du microphone numrique, de renvoyer au microphone des
commandes ainsi quune alimentation. Bien que ce standard fasse
rfrence un microphone comme source du flux AES3, il peut
aussi sappliquer dautres quipements qui fournissent une source
AES3 mais doivent dune part tre aliments depuis lautre extr-
mit du cble et dautre part recevoir par ce biais des commandes
(par exemple, pour modifier leur configuration).
2.1 Objectifs
Lemploi typique de ce standard est celui dun microphone
numrique reli une console de mixage. Le microphone joue le
rle de source AES3 et la console joue le rle du rcepteur AES3.
Cette compatibilit avec le standard AES3 a t trs contraignante
dans la conception du standard.
Les objectifs de ce standard sont multiples :
permettre au rcepteur AES3 dalimenter lmetteur AES3 ;
permettre au rcepteur AES3 de fournir des commandes
lmetteur AES3 ;
permettre lmetteur AES3 denvoyer un rapport sur son
tat ou sa configuration ;
permettre lmetteur AES3 de synchroniser son horloge sur
celle du rcepteur.
Nous allons tudier ces quatre fonctions sparment et nous
verrons quelles volutions sont souhaitables pour ce standard
( 2.5).
2.2 Alimentation fantme numrique
Rsoudre le problme de la tension dalimentation ntait pas trs
difficile, car une solution existe dj dans le domaine analogique,
avec lavantage dun consensus trs large parmi les constructeurs
autour de cette solution : aujourdhui, les microphones analogiques
metteur
XLR
110
TXP
TXN
Microphone
Tension DPP
Rgulateur
Commande
Dcodeur
a mission
Figure 6 Envoi de la DPP depuis le rcepteur AES42
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 5 420 8 Techniques de lIngnieur
condensateur sont aliments depuis une console de mixage ou
depuis un enregistreur par une tension fantme de 48 V, qui est
transmise comme une tension de mode commun sur les broches
2 et 3 du connecteur XLR (voir la recommandation EBU R50), la
broche 1 tant relie au blindage.
Lors de llaboration du standard AES42, il a suffi de fournir un
quivalent de cette alimentation fantme pour un microphone
numrique. Applique de la mme manire, il sagit maintenant
dune tension de 10 V, dsigne par le sigle DPP (Digital Phantom
Power). La manire la plus simple dappliquer cette tension, lorsque
la liaison AES3 passe par un transformateur, consiste appliquer
la tension au point milieu de lenroulement faisant face au micro-
phone. La figure 6 montre comment cette tension peut tre envoye
au microphone.
Il y a une diffrence importante entre lalimentation fantme ana-
logique et lalimentation DPP. Alors quun microphone analogique
rclame une tension leve pour polariser le microphone, et une
intensit faible pour alimenter un pramplificateur, la DPP doit ali-
menter des circuits intgrs (convertisseur analogique-numrique,
interface AES3, ventuellement processeur de traitement du
signal). Par consquent, la tension dalimentation est plus basse,
mais lalimentation doit fournir un courant relativement important
au microphone numrique. Selon le standard, ce courant a une
intensit maximale de 250 mA, sous une tension de 10 V.
Ces valeurs pourraient voluer dans le futur. Do viennent-elles ?
Au moment o le standard a t prpar, un seul constructeur,
Beyerdynamic, avait mis sur le march un microphone interface
numrique. Son avance technologique lui a bien entendu permis de
faire adopter ses choix au sein du standard. Lalimentation DPP en
est un exemple. Si lon se met la place des fabricants de console,
on peut tre effray par la valeur de lintensit requise, car au niveau
dune console, il faut multiplier cette intensit par le nombre de
tranches (ou voies) de la console. Pour une console de 64 voies, il
faut fournir 16 A !
2.3 Commandes
Par rapport au standard AES3, le standard AES42 ajoute une
caractristique importante : la console ou lenregistreur envoie des
commandes au microphone, commandes que celui-ci dcode et
excute. Il faut donc dfinir dans le standard la reprsentation
logique de ces commandes et leur mode de transmission lectrique.
Rcepteur
XLR
RXP
110
RXN
Console
DPP Tension
Codeur
Commande
b rception
_________________________________________________________________________________________________ INTERFACES AUDIONUMRIQUES AES/EBU
80
Amplitude (dB)
70
60
50
40
30
20
10
0 pour transmettre les bits de commande
103 104 105 106
Figure 7 Densit spectrale de puissance du signal
sur un lien AES3 48 kHz
2.3.1 Paramtres lectriques de la transmission
Pour concevoir la manire dont les commandes parviennent au
microphone, il aurait t possible de considrer le cble comme un
canal de communication. Le signal AES3 occupant une bande
au-del de 100 kHz (figure 7), la bande infrieure aurait pu tre uti-
lise pour le lien montant, ce qui aurait permis de passer un dbit
dinformation relativement lev.
Une autre solution aurait consist envoyer un second signal
AES3 en sens inverse du premier. La sparation des deux signaux
se serait faite par un circuit adapt, reposant sur un transformateur
trois enroulements, comme cela se faisait en tlphonie analo-
gique dans ce que lon appelait le passage 2 fils-4 fils .
Aucune de ces deux solutions na t retenue. Malgr leurs per-
formances plus leves, cest une solution plus rudimentaire qui a
t retenue. Cela est sans doute en accord avec la culture de lAES
dont les standards ont tendance privilgier des solutions simples
et robustes quitte tre moins performantes. Ici, la solution retenue
est celle que Beyerdynamic avait dj introduite dans son micro-
phone MD100.
La squence des bits de commande est transfre vers le micro-
phone par le biais dune modulation positive de 2 V de la tension
DPP. Paralllement, lalimentation est suppose fournir jusqu
300 mA quand la tension DPP est module (passant de 10 V 12 V).
La figure 8 montre la modulation utilise pour transmettre les infor-
mations vers le microphone. Les bits sont cods par une modulation
de largeur dimpulsion. La dure attribue un bit est de 64 /fs , soit
64 priodes dchantillonnage du signal audio. Cela donne un dbit
thorique de 750 bits/s si la frquence dchantillonnage est de
48 kHz. Un bit 1 est cod par une impulsion qui reste DPP
pendant 8 priodes dchantillonnage puis passe DPP + 2 V
pendant 56 priodes dchantillonnage. Un bit 0 est cod par une
impulsion qui reste DPP pendant 56 priodes dchantillonnage
puis passe DPP + 2 V pendant 8 priodes dchantillonnage.
Les bits sont transmis par paquets de 16 ou 24, chaque paquet
tant dcod comme une commande. Le dbit binaire rel est de
lordre de 500 bits/s car un intervalle de garde au moins gal la
dure dun octet, soit 512 priodes dchantillonnage, est requis
avant la transmission du mot de commande suivant.
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
512 T 512T 512T
64T 64T 64T
56T 8T 8T 56T 8T 56T
0 1 1 0
Figure 8 Modulation de la DPP
107 108
f (Hz)
Ce schma de transmission permet un dcodage trs simple des
commandes au niveau du microphone. Quelques portes logiques
suffisent. En revanche, le dbit utile est faible.
2.3.2 Commandes venant de la console
Sur le plan logique, la conception des commandes na pas
soulev beaucoup de difficults. Deux types de commande sont pr-
vus par le standard. Les commandes simples, au nombre de 3, sont
transmises sur deux octets, le premier tant un octet dadresses et
le second un octet de donnes. Les commandes tendues, au
nombre de 32, sont transmises sur trois octets. La distinction entre
commandes simples et commandes tendues vise amliorer le
dbit, car les commandes simples sont supposes tre expdies
trs souvent et bnficient dun codage plus compact.
Les trois commandes simples permettent de fixer respective-
ment :
la prattnuation qui peut prendre quatre valeurs, la directi-
vit indique par 4 bits, ce qui laisse le choix entre 15 directivits
(dont omnidirectionnel, cardiode, hypercardiode et en figure de
huit) et enfin un filtre coupe-bas qui prend trois valeurs au choix du
constructeur ;
le gain du microphone (sur 6 bits), un limiteur et un signal
mute pour rendre le microphone muet ;
la synchronisation du microphone.
La commande de synchronisation joue un rle particulier. Elle a
vocation tre expdie aussi souvent que possible. Le mot de
donnes qui lui est associ permet de coder, sur 8 bits ou sur
13 bits en utilisant 5 bits du premier octet, une tension applique
un oscillateur command en tension (VCO : voltage controlled
oscillator ). Nous dcrivons plus loin ( 4.3) la manire dont seffec-
tue le pilotage de lhorloge du microphone.
La norme AES42 prvoit en plus des trois commandes simples,
un jeu de trente et une commandes tendues. Pour le moment,
seules les commandes numrotes de 4 7 sont dfinies ainsi que
les commandes 33 et 34. Une rvision de ce standard, paratre
courant 2005, devrait dfinir en plus les commandes 29 32. Les
commandes actuellement dfinies concernent :
le numro de la page que le microphone transmet par le bit
U, la remise zro du microphone, le calibrage du convertisseur,
le test du microphone et un tmoin lumineux sur le corps du
microphone ;
la frquence dchantillonnage des convertisseurs du micro-
phone et un dithering lors de la conversion vers un nombre rduit
de bits ;
Techniques de lIngnieur TE 5 420 9
INTERFACES AUDIONUMRIQUES AES/EBU _________________________________________________________________________________________________
le type de strophonie (X/Y avec canaux gauche et droite, ou
M/S, avec le canal somme puis le canal diffrence), la balance dun
microphone strophonique ;
diverses courbes dgalisation du microphone ;
une commande qui ouvre une squence spcifique chaque
constructeur ;
une commande qui ferme cette squence spcifique.
Les deux dernires commandes montrent la fois la volont
douverture de ce standard, mais aussi le souvenir des rvisions de
la norme AES3, parfois induites par des contraintes imposes par
des fabricants, ou des pratiques adoptes par les utilisateurs.
Il est dailleurs intressant de se pencher sur les commandes
proposes pour la prochaine rvision. Pour la plupart, elles
concernent le rglage dun compresseur. Aujourdhui, aucun micro-
phone nincorpore de compresseur, mais la possibilit dinclure
avec le microphone et son convertisseur analogique-numrique un
processeur de traitement du signal est clairement ouverte par le
standard AES42 (en particulier au niveau de lalimentation
lectrique). Un compresseur peut tre facilement implant sur ce
DSP (digital signal processor ). Le standard tente donc danticiper
cette demande. Mais quand on voit la varit des effets numriques
disponibles dans les logiciels de montage audio, on se dit que rien
nempche de programmer la plupart dentre eux sur un DSP. Quel
est le degr dadaptation du standard AES42 face cette explosion
annonce ?
2.4 Rapport et identification
Aprs lalimentation et lenvoi de commande du rcepteur vers
lmetteur, le troisime ajout du standard AES42 par rapport au
standard AES3 est la fourniture dun rapport sur ltat de fonction-
nement de lmetteur. Contrairement un metteur AES3 qui fonc-
tionne sur un mme mode durant toute une session, un metteur
AES42 change souvent de rglages. Le standard demande donc que
lmetteur fournisse un rapport rgulirement au rcepteur. La
compatibilit avec le standard AES3 ne laisse pratiquement pas
dautre choix que dutiliser le bit U (user bit ). Nous avons vu plus
haut que lon peut utiliser ce bit comme un canal continu
48 000 chantillons par seconde, ou bien comme une succession de
paquets de 192 bits, dont le premier concide avec le prambule Z.
Le standard AES42 a choisi cette dernire possibilit. Nous dis-
posons donc dun bloc dinformation de 24 octets, appel page .
Lors de llaboration du standard, il est apparu quune page ntait
pas suffisante pour rapporter toutes les informations souhaites.
Quatre pages diffrentes ont donc t prvues, mais la quatrime
est pour le moment rserve (tous les bits 0). La page 0 contient
des informations varies et doit tre envoye le plus souvent pos-
sible. Les autres pages doivent tre envoyes au moins une fois par
seconde, ou la demande de la console (qui utilise pour cela la
commande tendue numro 4).
Certaines informations tant juges critiques et ne pouvant souf-
frir de retard dans la transmission du microphone vers la console,
elles ont t regroupes dans loctet 0 de la page 0, et sont aussi
recopies dans le mme octet 0 des autres pages. Ce sont :
lactivit du limiteur ;
la prsence dun crtage au niveau du convertisseur analo-
gique-numrique ;
ltat muet du microphone.
Les informations qui sont vhicules sont pour la premire page :
ltat des rglages du microphone (attnuation, directivit,
filtre coupe-bas, boutons) ;
la liste des fonctions que le microphone sait rgler sur
commande du rcepteur ;
ltat de la liaison radio et de la batterie dans le cas dun
microphone sans fil.
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 5 420 10 Techniques de lIngnieur
cela sajouteront peut-tre, dans une future rvision, les fr-
quences dchantillonnage possibles et la valeur actuelle du gain du
compresseur.
Les autres pages contiennent des informations moins essentielles,
mais permettant de simplifier lemploi des consoles de mixage
lorsquelles affichent ces informations :
identification du fabricant ;
identification du modle de microphone ;
identification du numro de srie ;
numro de version du matriel ;
numro de version du logiciel.
ces informations, il est utile dajouter une estimation du retard
induit par le microphone. En effet, la conversion analogique-num-
rique se fait systmatiquement par convertisseur / , qui comporte
un filtre numrique antirepliement, et donc un certain retard. De
plus, le microphone numrique incorpore divers filtrages, et ceux-ci
ajoutent galement un retard. Une console de mixage doit faire
travailler ensemble des microphones de marques et modles
diffrents, et chacun produit un signal ayant un certain retard. La
console doit en tenir compte pour compenser ces retards. En ana-
logique, cela navait pratiquement pas dincidence, pas plus quavec
les consoles numriques actuelles, dont les entres restent analo-
giques et sont donc toutes soumises au mme type de conver-
tisseur analogique-numrique : les signaux ne sont pas dcals les
uns par rapport aux autres. Avec des sources numriques, il est
indispensable que chacune annonce le retard avec lequel elle dli-
vre les signaux. Sans cette information, le travail de lingnieur du
son devient un immense casse-tte. Le standard AES42, sil incor-
pore cette information, ne peut le faire avant sa rvision en 2005.
Nota : on peut stonner que certains octets de la page 0 soient consacrs un micro-
phone sans fil, alors que la norme AES42 concerne la transmission par cble. Il sagit ici
simplement de prendre en compte le rcepteur dun microphone HF, qui serait vu par la
console comme un microphone numrique.
2.5 volutions
La norme AES42 a t dite en 2001 et pourtant, peu de micro-
phones respectant ce standard sont disponibles en 2005. Quelques
points de la norme posent encore problme et nont reu un
accord ni de la part des fabricants, ni de celle des utilisateurs. On
peut donc sattendre des volutions de cette norme.
Une premire volution concerne les connecteurs. La norme pro-
pose (mais nimpose pas) lemploi dun connecteur nomm XLD
pour remplacer le connecteur XLR dans la transmission de signaux
numriques. Ce connecteur diffre du connecteur XLR par un ergot
amovible qui le rend incompatible avec le connecteur XLR quand
il est prsent, mais compatible quand il est absent. Lobjectif est de
ne pas permettre dappliquer une tension fantme numrique (DPP)
sur un quipement analogique quil pourrait dtruire du fait du
courant quil est capable de fournir (250 mA). En plus de cet ergot,
le connecteur XLD a aussi un anneau cannel et ray (zbr) afin
de permettre au technicien manipulant cette prise de la lire en
lumire faible, ou de la reconnatre en sentant ses cannelures sous
ses doigts.
Une autre volution possible est similaire celle qui a fait
complter la norme AES3 par le document dinformation AES-3id ;
ce document introduit la transmission sur un cble coaxial, avec un
connecteur de type BNC. Les prestataires techniques et les chanes
de tlvision souhaitaient cette compatibilit avec le type de cble
quelles utilisent pour la vido. Aprs la parution de la norme
AES42, la mme demande a ressurgi.
On peut donc sattendre voir apparatre une version de la
norme AES42 qui permette de vhiculer le flux AES3 descendant
et le flux de commande AES42 remontant, ainsi que la tension
DPP, sur un cble coaxial, par le biais de connecteurs BNC.
_________________________________________________________________________________________________ INTERFACES AUDIONUMRIQUES AES/EBU

3. Spcifications lectriques Tableau 2 Comparaison des modes AudioPro,

VidoPro et Conso
Nous tudions ici les couches physiques de la liaison de type AES/
EBU, cest--dire les caractristiques lectriques de lmetteur, du Application AudioPro VidoPro Conso
cble et du rcepteur. Jusqualors, nous avons vu que les diverses
interfaces audio (AES3, SPDIF, CEI 60958, AES42) utilisent finalement Standard AES3 AES-3id CEI 60958-3
le mme protocole logique, avec les mmes blocs, trames et sous- (SPDIF)
trames, la mme modulation biphase mark et les mmes canaux C Symtrique Oui Non Non
(channel status ) dans les deux modes, professionnel et consomma-
teur. En revanche, au niveau lectrique, les spcifications divergent. Connecteur XLR BNC RCA
Trois situations se prsentent. La premire correspond au standard Impdance 110 75 75
AES3, dans une liaison de type professionnel, principalement dans le
contexte purement audio. La seconde est la variante consommateur Tension 27V 0,8 1,2 V 0,4 0,6 V
de ce standard, ce qui correspond une liaison SPDIF ou CEI 60958-3.
La troisime variante est, comme la premire, destine une liaison
en mode professionnel, mais intresse surtout les utilisateurs dans le connecteur trois broches XLR, aussi ce connecteur a t repris, pour
domaine de la tlvision ; elle repose sur la recommandation AES- le moment, dans les standards AES3 comme AES42. Cela na pas vrai-
3id. Convenons dans ce qui suit de dsigner les trois situations res- ment de quoi rjouir les utilisateurs, car le technicien doit chaque
pectivement par AudioPro, Conso et VidoPro (tableau 2). fois tre attentif ne pas insrer un signal analogique sur une entre
numrique, ou linverse. Un connecteur spcifique pour les prises
numriques aurait t prfrable.
3.1 Tensions, impdances et connectique La figure 9 donne un exemple demploi des connecteurs XLR
pour une connexion de type AES3 en mode professionnel. Notons
La tension lectrique du signal numrique varie de 2 7 V dans les rsistances de 110 chargeant lmetteur et le rcepteur. Les
le standard AES3, mais elle est plus basse dans les autres situa- transformateurs sont de rapport 1:1. Il y a galement la possibilit
tions, de lordre du volt en VidoPro et de la moiti dans le disoler le transformateur de lmetteur avec deux condensateurs,
contexte Conso. Ces rapports sont conformes ceux que lon lun plac dans la branche amont du transformateur, lautre situ
observe en moyenne pour les signaux analogiques dans ces dans la branche aval. Ces condensateurs protgent le transfor-
domaines dapplication. mateur dune tension continue qui lui serait applique, tout en
(0)

Les impdances et les types de cbles varient tout autant. Dans
le contexte AudioPro, le signal transite par une paire torsade, de
manire symtrique (si un conducteur transmet un signal +s,
lautre transmet le signal s). Dans les deux autres contextes, le
signal est transmis de manire asymtrique entre un conducteur
la tension nulle et le conducteur vhiculant le signal. Limpdance
est de 110 dans la transmission symtrique, mais de 75 dans
la transmission asymtrique.
La connectique, qui est la partie la plus visible du standard, montre
la plus grande dispersion. Le monde AudioPro est habitu au
amliorant la rjection de mode commun.
La figure 10 donne un exemple de connexion de type AES3 en
mode consommateur, ou plus prcisment de type SPDIF. On a sup-
pos que lmetteur avait des caractristiques lectriques identi-
ques lexemple de la figure 9. Les deux rsistances en sortie de
lmetteur ont pour rle de diviser la tension pour la ramener aux
valeurs souhaitables, mais elles adaptent aussi ltage de sortie
limpdance du cble. Comme dans lexemple de la figure 9, on
peut souligner la possibilit disoler le transformateur avec deux
condensateurs.

metteur Rcepteur
XLR XLR
110
TXP RXP
110
TXN RXN

a mission b rception

Figure 9 Connexion de type professionnel

metteur Rcepteur
374
RCA RCA 0,01 F
TXP RXP
90 75
TXN RXN
0,01 F

a mission b rception

Figure 10 Liaison en mode SPDIF avec metteur au standard AES3

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur TE 5 420 11
INTERFACES AUDIONUMRIQUES AES/EBU _________________________________________________________________________________________________
14
Amplitude (dB)
12
10
8 horloge unique. Cette technique rclame une horloge trs prcise,
6
4 console de mixage.
2
0
0,01 0,02 0,05 0,1 0,2
Figure 11 Fonction de transfert dun galiseur pour 1 000 m
de cble 5C2V
3.2 galisation
Les situations AudioPro et Conso ne rclament pas dgalisation,
les longueurs de cbles tant limites, ou du moins restant
compatibles avec les spcifications du standard. En revanche, dans
la situation VidoPro, les utilisateurs veulent pouvoir utiliser de
grandes longueurs de cbles, au-del de 100 m, limite fixe par
lAES3. Une galisation du signal peut alors tre ncessaire au
niveau du rcepteur ; elle reste interdite par le standard au niveau
du rcepteur. Lattnuation dun cble est domine par un terme en
a f , o le facteur a vaut 0,0085 dB/m pour un cble de type 5C2V
(pour dautres cbles, ce facteur volue entre 0,008 et 0,013). Lga-
liseur idal a une fonction de transfert conforme :


[ 1 + cos ( fT ) ] fT
E ( f ) = a f + 20 ln -----------------------------------------------------
2 sin ( fT )
La figure 11 montre la fonction de transfert obtenue avec cette
formule, pour un cble de 1 000 m de longueur.
4. Synchronisation
et horloges
La numrisation des signaux a entran lapparition dun problme
trs important dans le transfert de signaux entre quipements : la
synchronisation des horloges de chaque quipement. Le standard
AES3 rsout trs lgamment ce problme entre un quipement
metteur et un quipement rcepteur : lmetteur insre son horloge
dans le flux mis et permet au rcepteur de se synchroniser sur elle.
Mais cela ne suffit pas lorsque plusieurs quipements doivent tra-
vailler en parallle ou lorsque lhorloge du rcepteur est impose,
par exemple en fonction dune horloge vido.
La synchronisation suppose deux choses. Tout dabord, les fr-
quences dchantillonnage doivent tre identiques, garantissant le
mme nombre dchantillons chaque seconde. Ensuite, les trames
audio doivent survenir au mme instant, aux tolrances prs. Les
ingnieurs du son portent une trs grande attention la qualit des
signaux dhorloge, car la qualit du signal analogique restitu en
dpend.
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 5 420 12
La synchronisation sur une horloge de rfrence peut se faire de
trois manires. Le schma le plus simple consiste, pour chaque
quipement recevant un flux AES/EBU, utiliser lhorloge inhrente
ce flux comme horloge de synchronisation. Dans ce schma, les
difficults viennent des variations de lhorloge (gigue) ainsi que des
dcalages successifs qui sintroduisent quand de tels quipements
sont mis en cascade. Une seconde technique consiste fabriquer
une horloge de rfrence pour les signaux audio, envoye tous
les quipements du studio. Ceux-ci se synchronisent donc sur cette
que dcrit le standard AES11. La troisime manire consiste uti-
liser un asservissement de lhorloge de lmetteur, une horloge de
rfrence audio ; cest la technique quutilise le standard AES42
pour synchroniser tous les microphones connects une mme
4.1 Gigue
La gigue (jitter ) se dfinit comme les variations des instants de
0,5 1 2 5 10
passage du signal par zro, par rapport lhorloge idale. Deux
f (MHz) types de gigue peuvent tre considrs : le premier est intrinsque,
il est observ quand lmetteur fonctionne de manire autonome ;
le second type sobserve quand lquipement metteur reoit une
rfrence de temps sur laquelle il doit se synchroniser. On mesure
en sortie, dans cette dernire situation, la transmission de la gigue
issue de la rfrence de temps.
La gigue intrinsque doit avoir une amplitude au plus gale
0,025 UI, o UI dsigne le unit interval, cest--dire lunit de temps
la plus petite dans le signal, le temps le plus bref entre deux tran-
sitions dans le signal cod en biphase mark, qui est donc un 128e
de la priode dchantillonnage.
Exemple : 48 kHz, cette unit de temps est de 162 ns et la gigue
ne doit pas dpasser 4 ns.
La gigue transmise se mesure par lamplitude de la fonction de
transfert de la gigue entre la rfrence de temps et le signal AES/
EBU en sortie de lquipement. Cela suppose une analyse en fr-
quence du signal de gigue, considr comme un signal chan-
tillonn. En dessous de 500 Hz, le standard ne spcifie rien. Puis la
fonction de transfert doit rester infrieure un gabarit qui dcrot
dabord de 0 dB pour 500 Hz 6 dB pour 1 000 Hz. Au-del de
 (1) 1 000 Hz, le gabarit reste gal 6 dB. On peut considrer quun
quipement AES qui reoit une horloge doit la transmettre avec
deux fois moins damplitude de gigue que lhorloge reue.
4.2 Horloges de rfrence
Dans le cas o lon fabrique un signal de rfrence audio, le stan-
dard AES11 prcise que cest un signal AES3 particulier, qui respecte
donc les caractristiques lectriques de ce type de signal. On peut
utiliser aussi bien un signal contenant un programme audio ou un
signal simplifi avec prambule seul.
Deux classes dhorloge de rfrence sont considres. Une
horloge de grade 1 a une tolrance (exprime en fraction de la fr-
quence) de 10 6 (ou 1 ppm), alors quune horloge de grade 2 a
une tolrance de 10 5 (soit 10 ppm). Un quipement pouvant se
synchroniser sur une horloge de grade 1 doit tre capable de se ver-
rouiller sur une horloge dont la frquence se situe dans un intervalle
de 2 ppm autour de la valeur nominale, alors quun quipement
recevant une horloge de grade 2 doit se verrouiller sur une horloge se
situant dans un intervalle de 50 ppm autour de la valeur nominale.
La synchronisation, sur le plan temporel, fixe une limite maxi-
male lcart entre le dbut de la trame de la rfrence et le dbut
de la trame AES3 en sortie de lquipement, au niveau du
connecteur. Cette limite est exprime en fraction de la dure de la
trame AES3. Elle est de 5 % (pour un signal audio 48 kHz, cela
Techniques de lIngnieur
_________________________________________________________________________________________________ INTERFACES AUDIONUMRIQUES AES/EBU
110
A/D metteur
Horloge
VCO
Filtre D/A
donne 1 s). Un rcepteur doit pouvoir se synchroniser sur le
signal si lcart entre la rfrence et le signal reu reste infrieur
25 % de la dure de la trame AES3.
Dans le cas o le signal de rfrence audionumrique est
construit partir dune horloge vido, un cart supplmentaire de
5 % de la trame est tolr entre la transition du signal vido
(correspondant au dbut de la ligne 1 de chaque image) et le dbut
du prambule Z du signal de rfrence audionumrique. Les tol-
rances, on le voit, sont assez troites.
4.3 Synchronisation dhorloge AES42
Nous en venons maintenant la trs importante question de la
synchronisation des microphones numriques. Le standard AES42
propose un mode de fonctionnement sans synchronisation
(mode 1), dans lequel le microphone utilise sa propre horloge, ind-
pendamment de celle de la console ou de lenregistreur ; la console
doit donc comporter un convertisseur de frquence dchantil-
lonnage (SRC : sample rate converter ). Les rticences de beaucoup
dutilisateurs face aux convertisseurs SRC ont amen lintroduction
dun second mode de fonctionnement. Ce mode 2 incorpore un dis-
positif de synchronisation de lhorloge du microphone sur lhorloge
de la console. Pour cela, le microphone numrique est pilot par un
oscillateur contrl en tension (VCO) dont la tension est module
en fonction du mot de commande quenvoie la console (figure 12) :
le dcodeur du microphone dtecte la commande de correction
de synchronisation ;
il transmet la valeur de la correction un convertisseur num-
rique-analogique ;
ce convertisseur en dduit une tension analogique qui pilote
un VCO ;
la frquence de lhorloge que fournit ce VCO dpend de la
tension analogique en entre ;
le convertisseur ainsi que lmetteur AES3 se synchronisent
sur cette horloge.
Cela sous-entend que la console dtecte les carts de synchro-
nisation par un comparateur de phase : lensemble de lmetteur et
du rcepteur AES42 fonctionne en boucle ferme. Il constitue une
boucle verrouillage de phase qui est stabilise par un compen-
sateur PID (proportionnel, intgral, diffrentiel) bien connu des
automaticiens. Les paramtres de ce compensateur sont fixs par
le standard AES42.
5. Insertion audio en vido
Lorsque lon souhaite insrer un flux audionumrique dans un
flux vido numrique, la premire difficult qui se prsente est la
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur
Cble
Dcodeur
Figure 12 Contrle de lhorloge locale de
lmetteur AES42
diffrence de structure entre les deux flux. Si tous deux apparais-
sent comme des successions de bits cadence fixe, issus de
lchantillonnage cadence fixe dun signal analogique, la structure
temporelle sous-jacente est trs diffrente. Le signal vido est
constitu de lignes, spares par des intervalles de retour de ligne.
Aprs numrisation, cette structure est respecte, et le flux num-
rique alterne entre le paquet doctets correspondant une ligne
vido et un paquet doctets vides, correspondant aux retours de
ligne. Cest dans ces paquets vides que sinsre le signal audio.
Une deuxime difficult vient des relations entre les trames
vido et les chantillons audio. Le rapport entre nombre de lignes
vido par seconde et nombre dchantillons audio par seconde
nest pas un nombre entier. On ninsre donc pas toujours le mme
nombre dchantillons audio par ligne vido.
Une troisime difficult vient de la prsence de donnes auxiliaires
dans le signal audio, quil faut aussi insrer dans le signal vido. Et
linsertion elle-mme engendre de nouvelles donnes de contrle
dont le rcepteur a besoin pour savoir interprter et extraire les infor-
mations audio du flux vido.
Nous montrons ci-aprs comment sont gres ces trois difficults
dans un flux vido numrique 4:2:2 (norme UIT-R BT.656). Il nous
faut dabord dcrire rapidement la structure du flux vido dans cette
norme. Puis, nous voyons comment les donnes audio et auxiliaires
sont insres dans le flux vido suivant la norme UIT-R BT.1305.
Dans un troisime temps, nous tudions les donnes qui contrlent
cette insertion. Nous concluons cette partie par une rflexion sur les
problmes que pose la synchronisation des divers flux audio avec
le flux vido, en particulier dans le cas des insertions multiples.
5.1 Interface vido numrique BT.656
Dcri vons tout dabord le flux numrique vido dans lequel
sinsrent les informations audio. Dans la norme BT.656-3, o les
signaux vido numriques sont de type 4:2:2 (quatre informations
de luminance pour deux informations dans chacun des deux canaux
de chrominance), les informations vido sont transmises ligne par
ligne, chaque ligne reprsentant 864 chantillons de luminance (858
dans le cas dun programme 525 lignes) et autant de chrominance,
soit 432 chantillons pour CB , et autant pour C R . Les chantillons
sont regroups par paquets de 4, sous la forme {CB , Y, CR , Y} ; les
trois premiers lments de chaque paquet concident dans limage,
et le quatrime est isol.
Chaque chantillon est reprsent par un mot de 10 bits. Les
1 024 valeurs possibles ne sont pas toutes utilisables. En effet, la
norme prvoit que les quatre valeurs les plus faibles et les quatre
les plus leves soient rserves pour des mots didentification des
donnes (ces valeurs se caractrisent par le fait que les 8 bits de
poids fort sont tous 0 ou tous 1). Ne restent donc que
1 016 valeurs possibles pour les chantillons.
TE 5 420 13
INTERFACES AUDIONUMRIQUES AES/EBU _________________________________________________________________________________________________
Squence de rfrence temporelle SAV ou EAV 3FF 000 000 XYZ
C,Y,C,Y... EAV ADP, EDP, ADP, EDP... EAD
000 3FF 3FF 054
Lignes 8 et 320, ACP optionnel
C,Y,C,Y... EAV ACP ADP, EDP, ADP, EDP... EAD
Lintervalle entre lignes vido successives est remplac par des
donnes de suppression numrique. Le dbut et la fin de la ligne
vido sont marqus par deux groupes de quatre mots de donnes
(SAV start of active video au dbut, EAV end of active video
la fin) ; en notation hexadcimale, ces deux blocs sont crits sous
la forme {3FF 000 000 XYZ} o les bits variables XYZ permettent de
reprer le dbut ou la fin de trame et le dbut ou la fin de ligne
active. Entre lEAV qui termine une ligne et le SAV qui commence
la ligne suivante se trouve un bloc de 280 mots qui peut contenir
des donnes appeles ancillaires : ce sont soit des donnes audio,
soit des donnes auxiliaires.
lintrieur du bloc de 280 mots peuvent se situer plusieurs
paquets de donnes ancillaires. On les identifie par les quatre pre-
miers mots : les paquets ancillaires commencent tous par un bloc
du type {000 3FF 3FF XYZ}, o le quatrime mot permet de reprer
le type des donnes.
5.2 Insertion de paquets audio
Rappelons que le flot AES/EBU transporte trois types de donnes :
des donnes audio sur 20 bits ;
des donnes auxiliaires sur 4 bits (qui peuvent tre les 4 bits
de poids faible dun chantillon audio sur 24 bits) ;
des donnes non audio dans les bits V, U et C ;
un bit de parit P ;
un bit Z reprant le dbut des blocs dans le channel status C.
Privilgier linterprtation des 4 bits comme donnes auxiliaires
est typique du contexte broadcast o 20 bits sont considrs comme
suffisants pour coder le signal audio. La norme UIT-R BT.1305 est
oriente par ce contexte : elle loge sparment les donnes auxi-
liaires, quand bien mme elles sont les bits de poids faible des
donnes audio.
Dans la terminologie UIT-R BT.1305, une donne audio ( audio
data ) est un paquet de bits correspondant un chantillon : le signal
est reprsent par 20 bits auxquels sajoutent les 3 bits dtat VUC.
Une donne audio est donc un mot de 23 bits.
La norme prvoit que lon puisse insrer jusqu 16 canaux
audio dans un flux vido. Ces canaux sont regroups en quatre
groupes audio (audio group ), chaque groupe contenant donc une
ou deux paires de canaux. Les groupes audio insrs dans la vido
sont numrots 1 4.
On a vu que le flux audio AES transmis sans discontinuit doit
tre dcoup pour sinsrer dans les intervalles entre les lignes
vido. Un bloc de donnes ancillaires contient souvent plusieurs
chantillons audio successifs qui doivent appartenir aux canaux
audio se situant dans un mme groupe audio. Ils constituent un
paquet de donnes audio (audio data packet : ADP).
La mme logique de dcoupe en paquets sapplique aux autres
donnes vhicules par le flux AES/EBU. Les donnes auxiliaires
associes aux donnes audio faisant partie dun paquet de donnes
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 5 420 14 Techniques de lIngnieur
SAV C,Y...
SAV C,Y...
Figure 13 Insertion des diffrents paquets
ancillaires dans une ligne vido
audio (ADP) constituent un paquet de donnes tendues (extended
data packet : EDP). Ce paquet doit suivre immdiatement lADP
auquel il est associ. Cette dernire contrainte simplifie la recons-
truction des donnes au niveau du rcepteur.
Linsertion de laudio dans le flux vido repose sur le choix de
multiples options. Les paramtres choisis doivent tre transmis au
rcepteur pour lui permettre le dcodage du flux reu. Cela se fait
par le biais dun paquet de commande audio (audio control packet :
ACP). Il sagit dun paquet ancillaire optionnel, qui ne peut tre
prsent que dans deux lignes vido (no 8 et no 320).
La figure 13 montre de quelle manire les diffrents types de
paquets ancillaires sont insrs dans la ligne vido entre le groupe
de quatre mots qui clt la ligne vido active (EAV) et celui qui
ouvre la prochaine ligne vido active (SAV).
Les donnes ancillaires doivent commencer immdiatement
aprs le groupe EAV. On retrouve les trois types de donnes
ancillaires :
les paquets de donnes audio, reprsents dans cette
figure 13 par les lettres ADP ;
les paquets de donnes auxiliaires ou paquets de donnes
tendues, nots EDP, chaque paquet EDP suivant immdiatement
le paquet ADP auquel il est associ ;
les paquets de commande audio, nots ACP. Un tel paquet ne
peut figurer quune fois dans la trame vido, aux lignes 8/320 ; il
est optionnel, mais sil est prsent, il doit prcder tous les autres
paquets ancillaires et suivre directement lEAV.
On remarque aussi un quatrime type de paquet ancillaire, not
EAD (end of ancillary data ), qui se limite au seul groupe de quatre
mots den-tte. Ce paquet signifie quil ny a plus de donnes ancil-
laires dans le reste de la ligne vido en cours.
Comment le rcepteur dtecte-t-il les limites des paquets ? Cest
grce aux huit valeurs possibles des mots de contrle. Tout paquet
ancillaire commence par le groupe de 4 mots {000 3FF 3FF DID}, o
le mot DID slectionne le type de paquet (ADP, EDP, ACP ou EAD).
Ce mot sert aussi slectionner le groupe audio auquel appar-
tiennent les donnes ancillaires. Par consquent, lintrieur des
diffrents paquets ancillaires, seules sont permises les 1 016 valeurs
restantes, comme pour les chantillons vido. Cela signifie que la
reprsentation des donnes auxiliaires est trs contrainte ; disons-
le, elle est plutt complique !
Voyons comment sinsre un chantillon audio. Dun ct, nous
avons cet chantillon sur 20 bits, plus les bits U, C, P, soit une
donne audio de 23 bits au total. De lautre ct, nous avons une
succession de mots de 10 bits, dont certaines valeurs sont interdi-
tes. Pour viter les valeurs interdites, la norme se contente de dci-
der que le bit de poids le plus fort soit toujours choisi comme
loppos du bit qui le suit immdiatement. Cest simple et robuste,
mais peu efficace, car il ne reste plus que 512 valeurs possibles,
reprsentes sur les 9 bits restants. On voit quil faut trois mots
successifs (soit 27 bits) pour recevoir une donne audio (23 bits),
les quatre bits restants servent pour un bit de parit et deux bits
codant le numro du canal audio dans son groupe mais aussi le bit
_________________________________________________________________________________________________ INTERFACES AUDIONUMRIQUES AES/EBU

0 3 4 7 8 27 31
Prambule AUX V U C P

20 + 3 bits de donnes

Checksum
AES 1, L AES 1, R AES 2, L
DBN
DID
DH

Canal 1 Canal 2 Canal 3

DC

X, X + 1, X + 2 X, X + 1, X + 2 X, X + 1, X + 2

Data Count : nombre de donnes

Data Block Number : numro du bloc de donnes
Data Identification : type de donnes
Data Header : en-tte 000 3FF 3FF Figure 14 Insertion des donnes audio
dans un paquet ancillaire ADP

0 3 4 7 8 27 31
Prambule AUX V U C P

4 bits de donnes
AUX AUX

Checksum
DBN
DID
DH

DC

Figure 15 Insertion des bits auxiliaires

dans un paquet de donnes tendues

Z. On rappelle que le numro du groupe est cod dans len-tte

ADP. La figure 14 montre linsertion des donnes audio extraites Tableau 3 Nombre dchantillons audio par trame vido
dune sous-trame AES/EBU.
La figure 14 montre aussi les autres mots prsents dans le Cadence Film PAL/SECAM 525 Mono NTSC
paquet ancillaire ADP. On trouve par ordre darrive : audio
(kHz) 24 im/s 25 im/s 30 im/s 30/1,001 im/s
les trois mots ouvrant un paquet ancillaire et valant
{000 3FF 3FF}, nots DH ;
32 4000/3 1280 3200/3 16016/15
le quatrime mot ouvrant le paquet ancillaire, not DID, qui
dfinit le type de paquet et le groupe audio ; 48 2000 1920 1600 8008/5
un mot dfinissant le numro du bloc de donnes (DBN) ;
un mot dfinissant le nombre de donnes prsentes dans ce 44,1 3675/2 1764 1470 147147/100
paquet (DC) ;
les chantillons audio raison de trois mots par chantillon ;
un mot de contrle de parit. respecter exactement ces rapports. On dit alors que lon se trouve
La figure 15 montre la construction dun paquet EDP. On dans le cas isochrone, par opposition au cas asynchrone.
retrouve les mmes lments que dans le paquet ADP. La seule dif- Le cas particulier du NTSC amne modifier dans un rapport
frence vient ensuite des mots contenant les bits auxiliaires : les 1/1,001 la frquence dchantillonnage audio, de manire se
paquets de quatre bits auxiliaires sont runis raison de deux par ramener aux rapports un peu plus simples figurant dans la colonne
mot du paquet EDP. 525 Mono. Si lon se trouve dans un cas isochrone o un nombre
(0)

entier dchantillons audio correspond plus dune trame vido,

5.3 Contrle des trames audio et vido
Suivant les cadences de trames vido et la frquence dchan-
tillonnage audio, le nombre dchantillons audio par trames varie ;
il peut mme ne pas tre entier. Le tableau 3 donne lquivalence
entre nombre de trames audio et nombre dimages pour le cinma
et la tlvision. Lorsque la rfrence audionumrique est fabrique
partir dune horloge vido, le signal de rfrence audio doit
on introduit le numro de trame audio (audio frame number ),
nombre (commenant 1) de la trame vido dans la squence
audio de trames. Quand la vido est 25 trames par seconde, une
trame vido contient toujours un nombre entier de donnes audio.
Quand la vido est une cadence de 29,97 trames par seconde, il
faut plusieurs trames vido pour avoir un nombre entier dchan-
tillons audio. Par exemple, si laudio est 48 kHz, il faut cinq tra-
mes vido pour obtenir 8 008 chantillons audio ; le numro de
trame audio va alors de 1 5.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur TE 5 420 15
INTERFACES AUDIONUMRIQUES AES/EBU _________________________________________________________________________________________________

4:2:2 4:2:2
Insertion Dsinsertion
1 1
AES AES
2 2
3 3
AES AES
4 4
5 5
AES AES
6 6
7 7
AES AES
8 8
Figure 16 Insertion de quatre paires AES par
une cascade de quatre quipements

4:2:2 Traitement 4:2:2

4:2:2 vido numrique 4:2:2
insr insr
Dsinsertion Insertion
AES

AES

Signaux Signaux
synchrones asynchrones Figure 17 Perte de synchronisme audio-vido
du fait du traitement

Comme linsertion accepte galement des frquences dchan-
tillonnage ne faisant pas partie de la liste propose par le standard
AES/EBU, il faut aussi prciser cette frquence. Dans ce cas asyn-
chrone, il est indispensable de transmettre le numro de trame
audio, pour permettre au rcepteur de rattraper le synchronisme
entre les flux audio et vido. Ces donnes figurent dans le paquet
de commande audio (ACP). Ce paquet est facultatif dans le cas iso-
chrone 48 kHz. Il est obligatoire dans tous les autres cas. Chaque
groupe audio possde son propre paquet ACP. Le contenu du
paquet ACP fait apparatre dans lordre :
le numro de trame audio pour les voies 1-2 et 3-4 du
groupe ;
la frquence dchantillonnage de chaque paire de canaux et
leur ventuel asynchronisme ;
les canaux actifs dans le groupe ;
le retard du traitement audio par rapport la vido, exprim
en priodes dchantillonnage audio.
La structure de ce paquet ACP repose sur les mmes principes
utiliss dans la construction des paquets ADP et EDP : un en-tte
de quatre mots, les trois premiers qui permettent de dtecter une
commande, le quatrime mot dsignant le type de paquet et le
numro de groupe, puis une suite de mots dont les valeurs sont
codes sur 9 bits, avec toujours un bit de poids fort oppos au bit
suivant pour viter les huit codes rservs aux commandes. Les
deux premiers de ces mots reprent le numro du bloc et la taille
du paquet. Le paquet se termine par un contrle de parit.
5.4 Difficults pratiques : insertion
multiple et dsynchronisation
Pour conclure cette description de linsertion dun flux audio AES
dans un flux vido numrique 4:2:2, nous nous penchons sur un
problme pratique, celui du synchronisme entre les canaux AES
qui nest pas prserv par les insertions multiples.
Le premier exemple est illustr par la figure 16. On y voit quatre
quipements dinsertion dun flux AES dans un flux vido, mais
chaque quipement nest capable dinsrer quune seule paire AES.
Le recours quatre quipements permet de raliser linsertion
recherche, grce une mise en cascade des quipements. Le pro-
blme qui surgit alors est le dcalage entre le flux audio entrant et
celui qui a dj t insr. Si lon procde ensuite lextraction
comme il est montr sur la figure 16, les retards lextraction sont
accrus. Pour quune telle cascade dinsertions fonctionne, il faut que
chacun travaille au moins au niveau I, cest--dire gre le retard.
La figure 17 illustre un autre exemple de perte de synchronisme
entre audio et vido. Cest un schma trs classique, dans lequel
on veut appliquer un traitement sur la vido. Si lquipement ne
sait pas traiter laudio, il faut lextraire avant le traitement vido, et
rinsrer le signal audio aprs. Si les signaux sont synchrones la
sortie de lextracteur, ils ne le sont plus lors de la rinsertion. La
solution consiste appliquer un retard sur le signal audio pour
compenser le retard pris par la vido.
6. Conclusion et repres
La transmission de signaux audio entre quipements de studio
repose, on la vu, sur des normes nombreuses et enchevtres .
Le signal AES/EBU est un signal numrique deux canaux rgi par
les normes AES3, EBU Tech. 3250, ANSI S4.40, quivalentes entre
elles et la norme CEI 60958-3 (mode consommateur). La synchroni-
sation de plusieurs de ces signaux est dfinie dans les normes
AES11, EBU R83, ANSI S4.44. Un autre aspect de la synchronisation
entre lquipement metteur et lquipement rcepteur est trait
dans la norme AES42 qui comporte aussi deux autres aspects : lali-
mentation via le cble et la remonte dinformation de rglage.
Linsertion de flux audio AES dans un signal vido numrique est
traite dans les normes UIT-R BT.1305 et SMPTE 272M.
Dautres normes existent mais nont pas t traites ici, par
exemple, la norme MADI (AES10) qui permet de regrouper jusqu
56 canaux audionumriques en parallle.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 5 420 16 Techniques de lIngnieur