Et bien je vais tenter de répondre à ta question.
Les bons paramètres pour un "DAE buffer size" dépend pour beaucoup du nombre de pistes audios à lire ainsi que le nombres de montages, la fréquences d'échantillonnage utilisées dans protools.
Du côté des disques durs sa vitesse de rotation sa mémoire cache et le driver de disques sont des paramètres importants.

Pour bien comprendre l'interaction entre tous ces paramètres, il faut étudier un peu la topologie des disques durs.

Lorsque vous enregistrer dans un Protools le soft prend un certain nombres de décisions.
Prenons l'exemple d'un enregistrement de 6 pistes sur un disque dur fraichement acheté chez votre revendeur préféré. Le logigiel va calculer la taille disponible sur votre disque dur et la divise par 6 pour avoir le temps maximum d'enregistrement.
puis place les données sur votre disque de manière à optimiser le temps d'accès.

Dans notre exemple le logiciel place les audios de manière à ce que l'espace entre les pistes audios soient les mêmes pour avoir un temps d'enregistrement équivalent et une fragmentation minimum. En effet à la lecture le Protools va lire les pistes dans l'ordre. Le contrôleur de disque dur va donc lire la piste 1 puis la 2 en une rotation de disque. Puis il va changer de cylindre en déplaçant les têtes sur le cylindre suivant. Cette opération est la plus coûteuse en temps. On veillera donc à optimiser le changement de cylindre. Une fois la rotation de disque effectuée les pistes 3 et 4 sont lus et ainsi de suite en boucle. Il est à noter que l'on ne lit pas les pistes en entiers mais uniquement des fragments qui viendront alimenter le DAE en permanence pour lire simultanément les 6 pistes sans interruption de flux.
Si on décide d'enregistrer 6 pistes de plus on obtient le schéma suivant :

Cet exemple va nous permettre de mieux comprendre l'intérêt des mémoires tampons (buffers).
On voit que les fichiers sont entrelacés. donc si on suit l'algorithme précédent, le contrôleur de disque va lire la piste 1 puis la piste 2, changer de cylindre jusqu'à la piste 6 pour retourner au cylindre 1 et lire Les pistes 7 et 8. On voit que le déplacement des cylindres n'est pas optimisé. Dans ce cas il suffirai de lire la piste 1 et 2 comme prévu et de mettre en même temps dans un buffer les pistes 7 et 8. On évite ainsi le déplacement inutile entre les cylindres.
Pour être complet imaginons ce que donnerai notre algorithme si il ne faisait qu'optimiser le déplacement entre les cyclindres. On demande au contrôleur de disque de lire les pistes de 1 à 12 en continue. Pour optimiser le déplacement entre les cylindre les pistes 1,7,2 et 8 seraient lues. Les requêtes de lecture des autres pistes seraient mises de côtés jusqu'à ce que toutes les pistes du cylindre 1 aient étés lues. Le problème c'est que d'autres requêtes des pistes 1,7,2 et 8 vont arrivées pour continuer la lecture de ces pistes. Le contrôleur ne changera pas de cylindre puisque qu'il voit qu'il a d'autres lectures à effectuer sur ce cylindre et quels sont prioritaires. On se retrouverai alors dans une situation de blocage ou les autres pistes ne seraient jamais lues. Pour éviter cela on va utiliser l'algorithme dit de "l'ascenseur".
Je ne sais pas si vous vous êtes déjà retrouvé dans un ancien immeuble parisien (comme par exemple chez Celmar Angel ), mais il est trés difficile d'obtenir un ascenseur si vous habiter au 6 ème étage.
Imaginons le voisin du 3è qui arrive à prendre cet ascenseur. Il descend au rez de chaussé. Comme d'autres personnes arrivent pour rentrer chez eux ils prennent logiquement l'ascenseur pour aller au 2è. Le voisin du 2è étage sort de chez lui et prend donc l'ascenceur pour aller au rez de chaussé et ainsi de suite jusqu'à ce que plus personne ne le réclame. Cela peut-être long aux heures de pointes.
A la tour montparnasse remplit de bureaux ce schéma serait inacceptable. Les ingénieurs ont alors inventé un algorithme permettant à tous les utilisateurs d'être servis équitablement.
Lorsque l'ascenseur monte il ne redescendra pas avant d'avoir atteint l'étage le plus haut ou il a été appelé.
Lorsqu'il descend il s'assurera aussi qu'il a traité toutes les demandes des étages les plus bas avant de remonter.
C'est exactement ce qui va se passer pour les demandes d'accès aux fichiers entre les cylindres.

Ce petit exposé vous parait peut-être inutile mais il a le mérite de comprendre l'intérêt d'un bon driver de disque de sa mémoire cache et de l'importance de sa vitesse de rotation.
Lorsque le controleur à été cherché les données sur le disque dur il previent le driver que des données sont disponibles dans sa mémoire cache. Le driver va alors faire un accés DMA (Direct Memory acces) pour allez chercher les données et les stocker dans la mémoire tampon du DAE. Cette mémoire est plus importante que celle qui se trouve sur le disque et permet de stocker quelques secondes d'audios de manière à permettre au disque de mettre les données suivantes à disposition même en cas de grandes fragmentations générées par un grand nombre d'edits ou d'un disque fragmenté.
Le paramètre "DAE playback buffer size" va de 0 à 8. Plus le nombre est élevé plus la mémoire tampon est importante. Le risque d'avoir des erreurs DAE est atténué.
Alors pourquoi ne pas mettre le buffer du DAE toujours au maximum ?
Le problème engendré par une mémoire tampon importante et le délai entre le moment ou appuyez sur play et le moment ou l'audio sort du protools. Si vous mixez et que l'audio arrive quelques secondes plus tard ce n'est pas très gênant. Par contre quand vous éditez ou enregistrez ce délai est plutôt gênant.
On voit donc que tout n'est que compromis entre délai et performance. Il n'est donc pas simple de donner une configuration pour tout le monde.
Mais cela devrait vous permettre d'adapter votre configuration à vos besoins.

Quel disque j'utilise ? sur quel bus ?
Ai-je beaucoup d'édit ? mon disque est-il fragmenté ?
Combien de pistes ? quel fréquence d'échantillonnage ?

Vous pouvez vous référer au site digidesign http://www.digidesign.com/index.cfm?langid...mp;itemid=23114 pour avoir des indications dont voici un extrait :

Beau travail!
Enfin des explications claires, simples, intelligentes et documentées...
C'est parce que j'y croise souvent ce genre d'approche que j'aime MacMusic!!!!
Merc, jlddsgt!

Et l'âge du capitaine ?

Un autre sujet : PT7.2 Time Shift
Si qq'un a une idée....

Et d'aprés toi quel est le meilleur age pour le capitaine ?

Sinon quels sont les réglages qui te semblent optimum ?

Pour le mix et record le master 5.1 sur la même station:
Bof... 512 ou 1024 de buffer,
90% sur le bi-proc,
delay compensation au max,
level 4,
2 DSP pour 96 voices,

J'ai rarement eu le semtiment d'avoir besoin de passer en level 8,

quand il y a des erreur DAE, c'est que la video est sur le même disque que les audio files,
ou qu'il y a du fromage dans les buss.

Il y a deux semaines, un gentil assistant m'à killé un disque system, en éteignant un autre ordinateur, pourtant en réseau (sans le déconnecter du réseau) et juste après, en débranchant à chaud une Canopus puis en reconnectant un disque FW......
Son seul commentaire ; "pourtant je l'ai déjà fait sans aucun problème......."
Je m'apprêtais à sauvegarder ce qu'il y avait sur le disque décédé....
Après le scratch, en continuant sur l'autre disque system, et sur un Fw de sauvegarde miroir pour les sessions j'ai eu un quantité impressionnante d'erreur DAE en play du -4, du - 9060 (pas documenté pour PT7.2 ) du (# -7100) et d'autres, Tous les disques en avaient pris un coup, Techtools a remis un peu les choses d'aplomb avec l'aide d'Onyx...

Maintenant il ne reste plus qu'à récupèrer les sessions !

Questions de base

- si l'on répartit les audiofiles d'une session sur plusieurs HD, tout devient-il plus fluide ?

- je n'ai jamais défragmenté aucun de mes HD depuis OS X, quel est, ou sont les meilleurs programmes pour ça ?

Effectivement, le fait de distribuer les audiofiles sur 2 disques te permet d'accroitre ton debit général.
Il faut comprendre que se qui limite le nombre de pistes par disques c'est le déplacement des têtes demandé par la multitude de fichier audios.

Prenons un exemple concret :
Le firewire 400 permet un débit de 400Mbits par seconde. c'est à dire que le débit maximum supporté par ce firewire est de 50Moctets par seconde. C'est à peu prés le débit maximum d'un disque aujourd'hui.
Donc si l'on veut savoir le nombre de pistes audios que peut théoriquement supporter un disque dur on fait le calcul suivant :
Pour une session en 48khz 16bits,
On a 48000 * 2 échantillons par secondes soit 96000 octets par seconde et par pistes.
Si vous êtes en 24 bits il faut multiplier 48000*3 (puisqu'il y a 3 octets pour 24bits au lieu de 2 en 16bits).
Le nombre de pistes par disques serait donc de 50Moctets / 96000octets soit à peu près 520 pistes audios pour une fréquence de 48khz 16bits.
Il est évident qu'aucun disque ne supporte ce nombre de pistes.
Ce qui limite le débit ici c'est le nombre de fichiers qu'il faut lire simultanement. Contrairement à la lecture d'une vidéo qui demande un trés gros débit mais qui n'est finalement qu'un seul fichier à lire (donc peu de déplacement des têtes de lectures) , L'audio nécessite la lecture d'un grand nombre de fichiers et (donc beaucoup de déplacements des têtes de lectures).
Le fait de mettre plusieurs disques divise ces déplacements par disques. C'est donc une bonne solution.
On remarquera que chainer 2 disques sur la même chaine firewire est possible.
Il est quand même utile de savoir que le nombres de pistes sur un firewire 800 avec 2 disques durs sera plus importants que 2 disques durs en firewire 400. La gestion du firewire 800 n'étant pas la même.
Je n'est pas eu d'explication logique de la part de digidesign à cela mais il semble que le nombres de petits "paquets" à envoyer du à la fragmentation stature plus vite le bus firewire400. Il est aussi possible que le protocole utilisé par le driver du firwire800 soit plus éfficace. Si vous avez une réponse claire je serai trés interressé.



Cette question à l'air de revenir souvent.
Il a déjà été dit que sur Mac osx (et unix/linux en général) le système de fichiers ne permet pas de fragmenter les fichiers au sens "windows" du terme.
Il n'est donc pas utile de défragmenter un disque audio. Dans la plus part des cas cela empire même la fragmentation au sens audio du terme. Car ton défragmenteur va regrouper tous les fichiers mais ne va pas optimiser le déplacement des têtes de lectures de ton disques. Ce n'est pas toujours vrai mais pour cela il faudrait regarder en détail comment les systèmes de fichiers gère cela...

Bonjour,
Hey, jlddsgt! reviens souvent sur les forums, stp!
J'ai l'mpression d'être moins naze après chaque lecture de tes post... Merci.

C'est vrai que le monsieur a beau avoir le pseudo le plus compliqué qu'il m'ait été donné de voir sur ce forum, force est de constater que ses explications sont fort instructives et détaillées.
Chapeau!

C'est vrai qu'on se demande d'où il sort un pseudo pareil ....
En revanche, questions connaissances, c'est du béton !
Chapeau bas, camarade !

Autre rebond sur le sujet : je vois bien l'intérêt du FW 800 par rapport au 400, mais quid des échnges avec un HD en IDE (en interne, quoi ...) ?
Parce que, en tant qu'adepte du montage-démontage, on sait que le HD FW externe n'est ni plus ni moins qu'un IDE mis dans un boîtier avec arrivée d'alim et tutti quanti.

A priori, en enlevant cet intermédiaire, la vie devrait être plus simple.
...

Mais question défragmentation, il est surtout conseillé de dédier certains disques aux sessions exclusivement, avec backups quotidiens et de stocker les données plus "volatiles" (plugs settings, bounces ou autres ) sur un support séparé. Ca limite les engorgements à la lecture de l'audio.

HTH
Myriam

Ce n'est pas si Il y a au moins 3 ou 4 générations de disques FW avec des puces différentes (on se rappelle de l'Oxford 910 des années 2002)
et la nouvelle génération (depuis un an approximativement) est annoncée beaucoup plus véloce… Mais TOUT dépend de la vitesse du ou des buss internes de l'ordinateur !
un FW800 n'apparaîtra pas significativement plus rapide qu'un FW400 sur un G4
Alors que sur un G5, la différence commencera à devenir sensible…

Merci, Ca donne envie de continuer...



Au niveau du firewire il y a plusieurs générations de puces contrôleur Oxford.
Les évolutions des chipsets Oxford sont les suivant :

-Oxford 911 : supporte les disques ATA-100 (UDMA5) et permet un débit supérieur à 40Moctets/s uniquement pour le firewire 400.
-Oxford 911 plus : Supporte les disques jusqu'à ATA-133 (UDMA6) et permet un débit supérieur à 40Moctets/s uniquement pour le firewire 400.
-Oxford 912 : Supporte les disques jusqu'à ATA-133 (UDMA6) et permet un débit supérieur à 80Moctets/s pour du firewire 800.
-Oxford 922 : Supporte les disques ATA-100 en Master et slave, les CD ATAPI et les compact Flash. Il est compatible firewire400/800 et USB 1.1/2.0.
Attention ce chipset n'est apparemment pas recommandé pour une utilisation Audio.
-Oxford 924 : Supporte les disques SATA (génération 1 et 2). Il est compatible firewire 400/800 et USB 2.0.



Il peut-être intéressant de comparer les dernières technologies en matière de disques durs.
Les technologies de disques durs les plus utilisées sont les disques P-ATA(IDE), SATA et SCSI.
Les bus parallèles utilisés par les disques P-ATA transfèrent les données par blocks de 16bits sur un câble plat de 40 broches.
cette technologie n'est utilisé que comme bus interne car sa longueur maximale de 46cm ne permet pas de connecter un disque en externe.
De plus avec les fréquences de plus en plus rapides les bus parallèles souffrent d'une faible immunités au bruit.
Les données adjacentes perturbent les bits qui sont côte à côte par effet de couplage capacitif. Les câbles de 80 broches sont apparus pour diminuer ce "crosstalk" entre les câbles. Chaque câble de données et séparé par une masse à partir de la norme ATA-66 (UMDA4).
Les normes ATA-100 et ATA-133 nécessitent aussi un câble de 80 broches. Cette dernière norme permet un débit de 133Moctets/s.

Pour pouvoir augmenter le débit de transfert entre les disques durs et l'ordinateur ont va alors utiliser une technologie série qui peut paraître moins rapide mais qui ne souffre pas des problèmes d'immunités aux bruits. Le cable peut être mieux blindé, sa longueur de 1m et sa petite taille physique permet un câblage plus simple dans les coffrets d'ordinateurs.
Il existe deux normes pour le SATA. Le SATAI qui permet un débit maximum de 150Moctets/s et le SATAII qui offre un débit de 300Moctets/s.

Le SCSI est à l'origine un bus parallèle qui rencontre les mêmes problèmes que les disques P-ATA. Sont débit maximum est de 320Moctets/s.
Pour augmenter ce débit des bus séries sont aussi développer tel que le Serial Attach SCSI (SAS), le iSCSI, et les Fiber channels.
De manière générale les bus séries permettent des débits plus élevés sur une longueur plus grande. Il permettent aussi le branchement à chaud "hotswap" des disques durs et le nombre de disques que l'on peut brancher sur une même chaîne est plus important.

On comprend mieux maintenant l'intérêt du firewire qui permet d'utiliser une technologie de disque IDE qui à l'origine ne permet pas d'être branché en externe. De plus le nombre de disque durs n'est plus limité à 2 disques (Maître et esclave) mais à 63 appareils connectés sur une longueur maximum de 72 mètres. Et pour finir il est "hotswapable" ce qui n'est pas le cas des disques IDE (qu'il contient en interne).

Enfin tout ça pour dire que les disques IDE allaient mourir. Vive le Serial Macmusic !!!

Encore, encore !!!!!

C'est vraiment super, merci beaucoup pour toutes ces infos.

Bon bah avec tout je viens de voir que ICE FW800 à un bridge Oxford 922 et que ce n'est pas top, donc, pour l'audio. Domage je l'utilise avec mon protools

As tu des marques de DD externe en FW800, à nous conseiller ?

baille, et merci encore pour ce cours magistral

Bah! si tu n'as pas de problème c'est cool. Je me permet juste de te donner les spécifications de digidesign concernant les chipsets Oxford :

FireWire 400 drives with the Oxford 911 FireWire chipset interface on Mac OS X & OS 9
FireWire 400 drives with the Oxford 912 or 924 FireWire chipset interface on Mac OS X 10.4
FireWire 800 drives with the Oxford 912 or 924 FireWire chipset interface on Mac OS X 10.4

Check with the drive manufacturer to verify that their drive has the "Oxford 911", "Oxford 912", "Oxford 924" or comparable chipset & drive speed of 7200 rpm.

Ca c'est trés IMPORTANT : FireWire 400 and FireWire 800 drives should not be combined.

Voilu!

Hoops plus de détails ?

Jean-Luc, que penses-tu de cet autre sujet que voilà ?

ok,

merci beaucoup.

Sinon, j'ai un principe, qui m'a évité bien des problèmes à mon avis : 1 port FW = 1 disque (et 1 seul), je ne chaine jamais des disque entre eux.
Par ailleurs je ne combine pas 800 et 400

Merci de l'info en tout cas, je vais regarder ce qu'il existe comme disque en Oxford 912 et 924

baille

bonjour à tous,

je viens de lire ce post :
1 port FW = 1 disque (et 1 seul), je ne chaine jamais des disque entre eux.
Par ailleurs je ne combine pas 800 et 400

en fait , moi je dispose de 2 hd FW 800 branchés en serie sur le meme port mais en 400 (je n'ai pas installé de carte 800)
le premier hd sur le port FW, le 2eme en serie mais branché avec un cable FW800 ...

C'est dangereux a votre avis?
merci

salut,

à mon avis oui, c'est un peu dangereux.
Un conseil : installe une carte FW, c'est pas chère maintenant. Moi j'ai un powerbook et la carte FW (pcmcia) ne m'a coutée que 20 euros pour 2 port FW400 supplémentaires.

baille

Exact, j'avais ça sur mon PB G4, et ça marchait très bien !

Par contre, si quelqu'un a trouvé une carte de ce genre pour les MacBook Pro, je veux bien l'info, parce que pour le moment, je n'ai rien trouvé…

SALUT

J'ai il y a 1ou 2 ans fait les frais d'un défragmentation sur osx et résultat: tout réinstaller en plus c'était avec techtool pro .
Alors pourquoi si on a plus besoin de défragmenter sous osx on nous vends des logiciels de défragmentations pour osx......

@+PAT

C'est les mauvaises habitudes de windows
Historiquement cela vient des systèmes de fichiers FAT16 et FAT32.
Une tables des secteurs disponibles est mise à jour à chaque fois que vous effacez ou ecrivez un fichier.
Cette table alloue les premiers secteurs de libres au fichier que vous voulez ecrire mêmes s'ils ne sont pas continues.
La fragmentation commence dès que vous effacer un petit fichier et que vous voulez en ecrire un plus gros.
Sur Macosx le système de fichier HFS+ allouera un nombre de secteurs consécutifs à votre fichier pour éviter la fragmentation.
Par contre lorsque votre disque dur se remplit de manière trop importante le système de fichier ne peut plus vous allouez de secteurs continues et ne peut plus éviter la fragmentation.
Il est donc important de ne pas remplir sont disque inconsidérement.
il est admis qu'en dessous de quelques giga-octets de place disponible, le disque va commencer à avoir une fragmentation difficile à gérer pour de l'audio.
De plus si vous descendez nettement en dessous d'un giga, votre ordinateur va ralentir fortement s'il ne reste pas assez d'espace libre pour la mémoire "swap" (pagination).
Ceci est surtout notable sur des ordinateurs qui ne possèdent pas beaucoup de mémoire.

En résumé si vous remplissez "à mort" votre DD il vous le fera savoir

J'ai défragmenté des disques FW de 250 g trop pleins,
un peu par vice et pour voir (et après sauvegarde!)
Après avoir fait un peu de place, Techtools Pro sait le faire,
ÉVIDEMENT il faut AVANT faire le ménage et vérifier la bonne santé du disque !

L'ennuie c'est que cette opération prend beaucoup trop de temps...

Comment se fait-il que je n'aie pas vu ce sujet passionnant ? Je le remets en haut de la pile.
Bravo à jlddsgt. Je comprends mieux maintenant ...(épatant, l'histoire des ascenceurs )