Réglage buffer 828 mk2 dans sx/nuendo
- 22 réponses
- 7 participants
- 2 807 vues
- 5 followers
Pakupaku (lcl)
4635
Squatteur·euse d’AF
Membre depuis 21 ans
Sujet de la discussion Posté le 08/03/2005 à 17:24:24Réglage buffer 828 mk2 dans sx/nuendo
J'aimerais avoir des exemples de réglages que vous utilisez avec la motu pour bosser sur nuendo ou sx :
quelle taille allouez vous aux buffers ?
quel est votre processeur ?
combien avez vous de ram ?
quelle latence ?
ça pourrait aider tout le monde d'avoir quelques exemples...
dès que la mienne marche je remplus ma cas ;)
(hé oui, bienvenue au club !)
quelle taille allouez vous aux buffers ?
quel est votre processeur ?
combien avez vous de ram ?
quelle latence ?
ça pourrait aider tout le monde d'avoir quelques exemples...
dès que la mienne marche je remplus ma cas ;)
(hé oui, bienvenue au club !)
sub-d25
172
Posteur·euse AFfiné·e
Membre depuis 19 ans
2 Posté le 08/03/2005 à 17:37:42
Salut, je cale rarement mes buffers au minimum, plutot au alentour de 256 samples,j'ai un atlhon 2100 + 1024 de ram, LATENCE IMPERCEPTIBLE...
damballah
87
Posteur·euse AFfranchi·e
Membre depuis 21 ans
3 Posté le 10/05/2005 à 13:10:04
J'AI DU CALE mes buffers a 96 quand je record a 44 pour me defaire de gresillements et de clics & drops en lecture. C mieux mais c ps encore propre
amd 20000
RAM500
cubase sx 2.2
win xp
amd 20000
RAM500
cubase sx 2.2
win xp
SONY VAIO F11 | CUB5 | FENDER/TAYLOR
Pakupaku (lcl)
4635
Squatteur·euse d’AF
Membre depuis 21 ans
4 Posté le 10/10/2005 à 14:10:27
Je relance le débat...
j'ai donc ce que tu appelles des "clics and drop" en lecture ET en enregistrement. penses-tu que ça puisse venir précisément du réglage des buffers ? si oui le fait de les baisser peut-il régler le problème ?
je précise ma machine :
p4 3.2
carte mère "stable"
carte firewire avec chipset intel qui va bien
OS "propre" débarassé du superflu
patchs correctif windows pour la gestion du firewire appliqué
dernière version des pilotes motu à jour
je ne vois plus d'autre solution à mon problème !!!
j'ai donc ce que tu appelles des "clics and drop" en lecture ET en enregistrement. penses-tu que ça puisse venir précisément du réglage des buffers ? si oui le fait de les baisser peut-il régler le problème ?
je précise ma machine :
p4 3.2
carte mère "stable"
carte firewire avec chipset intel qui va bien
OS "propre" débarassé du superflu
patchs correctif windows pour la gestion du firewire appliqué
dernière version des pilotes motu à jour
je ne vois plus d'autre solution à mon problème !!!
Fix
577
Posteur·euse AFfolé·e
Membre depuis 20 ans
5 Posté le 10/10/2005 à 14:40:46
Ne nous y trompons pas:
Les buffers servent à faire l'interface entre les processus asynchrone (disques) et les processus synchrones (entrées/sorties interface).
En clair:
Les données transmises entre la carte son et le PC ont un débit constant. Celui ci dépend de la fréquence d'échantillonnage et du nombre de voies. En tout état de cause c'est géré par l'interface et, sauf anomalie, c'est sensé marcher tout seul.
Par contre au niveau des disques, des traitements des plugs, etc... c'est de l'asynchrone. L'aspect multitâche des systèmes d'exploitation comme windows, MacOS, etc... empêche d'assurer un débit constant. Pour palier à ce problème il existe des buffers qui permettent de "prendre de l'avance" pour palier au retard éventuel d'un des éléments asynchrones de la chaîne. Les guillemets sont importants car il est évident qu'on ne peut pas prendre de l'avance (on ne peut pas traiter du son qui n'est as encore rentrée dans la carte). La technique consiste donc à introduire un délai (ou latence) qui permet de toujours avoir une réserve de son déjà traitée à envoyer vers les sorties. Cette réserve de son est stockée dans ces fameux buffers.
Conséquences:
Plus les buffers sont grands, plus la latence est grande, et plus la réserve de son est grande ce qui permet de faire face à des retards des traitements plus importants. Si un processus prend plus de retard que ce que permettent les buffers, il n'y a plus de réserve de son. Du coup y'a plus rien qui sort jusqu'à ce que les données en provenances des processus réapparaisse. Ca fait un craquement.
Réglages des buffers:
Etant donné tout cela, les buffers doivent être dimensionnés en fonction de la quantité des processus (plugs ou autres) et de leur complexité. Plus il y a de processus, plus les buffers doivent être grands, mais plus la latence sera grande également. Le réglage des buffers est donc à faire en fonction de chaque projet (nombre de pistes, de plugs, de VSTi, etc...). Les bargraphs de charge proc et disque sont un bon moyen d'apprécier la complexité d'un projet et donc de régler les buffers.
Notre problème de buffer plus petit qui craque moins:
Etant donné toute cette explication, ce phénomène est complètement absurde, puisque qu'en règle générale on augmente les buffers pour pas que ça craque. Donc le problème vient d'ailleurs.
PS: Désolé pour la longueur, j'ai souvent un peu de mal à être concis.
Les buffers servent à faire l'interface entre les processus asynchrone (disques) et les processus synchrones (entrées/sorties interface).
En clair:
Les données transmises entre la carte son et le PC ont un débit constant. Celui ci dépend de la fréquence d'échantillonnage et du nombre de voies. En tout état de cause c'est géré par l'interface et, sauf anomalie, c'est sensé marcher tout seul.
Par contre au niveau des disques, des traitements des plugs, etc... c'est de l'asynchrone. L'aspect multitâche des systèmes d'exploitation comme windows, MacOS, etc... empêche d'assurer un débit constant. Pour palier à ce problème il existe des buffers qui permettent de "prendre de l'avance" pour palier au retard éventuel d'un des éléments asynchrones de la chaîne. Les guillemets sont importants car il est évident qu'on ne peut pas prendre de l'avance (on ne peut pas traiter du son qui n'est as encore rentrée dans la carte). La technique consiste donc à introduire un délai (ou latence) qui permet de toujours avoir une réserve de son déjà traitée à envoyer vers les sorties. Cette réserve de son est stockée dans ces fameux buffers.
Conséquences:
Plus les buffers sont grands, plus la latence est grande, et plus la réserve de son est grande ce qui permet de faire face à des retards des traitements plus importants. Si un processus prend plus de retard que ce que permettent les buffers, il n'y a plus de réserve de son. Du coup y'a plus rien qui sort jusqu'à ce que les données en provenances des processus réapparaisse. Ca fait un craquement.
Réglages des buffers:
Etant donné tout cela, les buffers doivent être dimensionnés en fonction de la quantité des processus (plugs ou autres) et de leur complexité. Plus il y a de processus, plus les buffers doivent être grands, mais plus la latence sera grande également. Le réglage des buffers est donc à faire en fonction de chaque projet (nombre de pistes, de plugs, de VSTi, etc...). Les bargraphs de charge proc et disque sont un bon moyen d'apprécier la complexité d'un projet et donc de régler les buffers.
Notre problème de buffer plus petit qui craque moins:
Etant donné toute cette explication, ce phénomène est complètement absurde, puisque qu'en règle générale on augmente les buffers pour pas que ça craque. Donc le problème vient d'ailleurs.
PS: Désolé pour la longueur, j'ai souvent un peu de mal à être concis.
Pakupaku (lcl)
4635
Squatteur·euse d’AF
Membre depuis 21 ans
6 Posté le 10/10/2005 à 15:48:08
Non au contraire c'est très clair, merci pour les explications techniques
donc si j'ai bien suivi, la seule chose que je devrais faire au niveau des buffers si j'ai des "blancs" dans mon enregistrement, c'est les augmenter, et non pas les réduire...
seulement j'ai ce problème pour un simple enregistrement stereo sur goldwave ou nuendo, c'est kif kif, en conservant le réglage par défaut de la motu.
il y a donc de grandes chances que ça ne vienne pas de là ?
donc si j'ai bien suivi, la seule chose que je devrais faire au niveau des buffers si j'ai des "blancs" dans mon enregistrement, c'est les augmenter, et non pas les réduire...
seulement j'ai ce problème pour un simple enregistrement stereo sur goldwave ou nuendo, c'est kif kif, en conservant le réglage par défaut de la motu.
il y a donc de grandes chances que ça ne vienne pas de là ?
Fix
577
Posteur·euse AFfolé·e
Membre depuis 20 ans
7 Posté le 10/10/2005 à 15:59:59
Pour un enregistrement stéréo normalement ça passe même en 96 ech (à moins d'avoir un PII, 64Mo de RAM, et d'utiliser 6 ou 7 compress Steinberg). Moi j'ai des décrochages de temps en temps sur la lecture mais ça ne vient pas de là.
Anonyme
521410
8 Posté le 10/10/2005 à 16:07:11
As tu le pack windows sp2 installé? je sais que dans mon cas quand j'ai eu le sp2 sur mon ordi ma motu generait des clics à la lecture et a l'enregistrement comme toi et meme parfois des decrochages, j'ai remis le sp1 et tout est rentré dans l'ordre
Pakupaku (lcl)
4635
Squatteur·euse d’AF
Membre depuis 21 ans
9 Posté le 10/10/2005 à 16:09:55
ça me rend chèvre cette histoire.
j'ai des trrrrrr (genre le centième de seconde qui se répète pendant une fraction de seconde) et des "trous" de quelques dixièmes de secondes (j'ai mesuré ;) )
je ne vois pas ce que je pourrais faire de plus ?
quelqu'un saurait-il comment repasser au sp1 une fois le 2 installé ?
le PB est que j'ai un XP qui intègre le sp2... peut-on quand même revenir en arrière ?
Fix
577
Posteur·euse AFfolé·e
Membre depuis 20 ans
10 Posté le 10/10/2005 à 16:31:13
Moi j'ai le SP2 et j'ai pas plus de problèmes que ça. Bon ma machine commence à pédaler un peu dans la choucroute mais c'est parce que je fais plein de trucs avec.
Le SP2 ne me parait pas être un problème si ce n'est qu'il bride les port FW en S100 (100Mbps). Ca n'a pas une grande importance étant donné que la 828mkII utilise tout au plus 78Mbps en 96kHz, 24 bits, avec toutes les entrées/sorties utilisées. En 48kHz avec les 22 sorties et les 20 entrées en 24 bits, on est à 48Mbps. Par contre ça peut devenir critique si tu as un disque FW en chaîne avec la 828mkII. En tout état de cause Microsoft propose un patch pour rétablir les ports FW en S400 (voir forum je sais plus trop où).
Par contre tu peux avoir un autre périphérique qui met le dawha sur le bus PCI (que partage immanquablement le chipset FW). Moi pour que ça marche sur mon portable ACER, il faut que je désactive la gestion de la batterie.
Le SP2 ne me parait pas être un problème si ce n'est qu'il bride les port FW en S100 (100Mbps). Ca n'a pas une grande importance étant donné que la 828mkII utilise tout au plus 78Mbps en 96kHz, 24 bits, avec toutes les entrées/sorties utilisées. En 48kHz avec les 22 sorties et les 20 entrées en 24 bits, on est à 48Mbps. Par contre ça peut devenir critique si tu as un disque FW en chaîne avec la 828mkII. En tout état de cause Microsoft propose un patch pour rétablir les ports FW en S400 (voir forum je sais plus trop où).
Par contre tu peux avoir un autre périphérique qui met le dawha sur le bus PCI (que partage immanquablement le chipset FW). Moi pour que ça marche sur mon portable ACER, il faut que je désactive la gestion de la batterie.
- < Liste des sujets
- Charte