Se connecter
Se connecter

ou
Créer un compte

ou

PB taille de buffer ?

  • 13 réponses
  • 6 participants
  • 1 255 vues
  • 5 followers
Sujet de la discussion PB taille de buffer ?
Je viens de recevoir mon nouveau PC et une carte HDSP 9652 , l'install avec les drivers du site RME ce passe bien . Avec le CD (carte d'occaz.) impossible de trouver les drivers ??? :fache: donc allons sur le net ...

J'installe cubase et là le test de configuration audio ce passe mal !!! :???:
J'ignore et je teste quand même en rec comme en play tout ce passe nickel :???: :???:
Ayant une nouvelle bécane assez puissante je teste de le gaver de plug . Aprés être arrivé à 80 % de conso proc je me dis que je vais augmenter ma taille de buffer (vu que j'était à 256) à 2024 et la à mon plus grand étonnement la conso. proc augmente ????????????????? C'EST PAS POSSIBLE !!!! :non:

Quelqu'un as-t-il déjà eu ce problème ????

Merci d'avance
Ma devise ... TRANQUILLE !!!!!!
2
UP !!!! :clin:
Ma devise ... TRANQUILLE !!!!!!
3
Un petit UP par jour , ça me parait pas mal !!!!!

:bravo:
Ma devise ... TRANQUILLE !!!!!!
4
Il me semble que les buffers que tu regles dans la fenetre du driver RME ne sont pas les memes que ceux qui gerent les plugs, mais seulement l'acces au disque en enregistrement (et monitoring puisque les buffers "stoquent" 512 ms (par exemple) les données audio avant de les envoyer aux disques dur et au softs). Enfin je ne connais pas cubase, j'utilise samplitude, et il y a des reglages interne de buffer en lecture pour les plugs et les acces (lecture) aux disques durs. Augmenter la taille des buffers ASIO ne sert (c'est une sorte de suposition) qu'a augmenter le nombre de piste enregistrable simultanement sans craquements, et à induire de fait une latence au monitoring...
Mais comme la RME contient un DSP qui gere le routing et le monitoring "hardware", ça ne pose pas de pb (le son rentre ds la carte et ressort aussitôt sans passer par les drivers, windows, le sequenceur et retour par le meme chemin, donc latence (considérée comme) zero).
Pour ton soucis, regarde plutot ce que tu peux faire dans cubase...

www.lesousmarin.net

5
Je me ravise...
Tout bien reflechi la taille des buffers ne peux rien au nb de calcul que peux effectuer ton CPU en temps reél... Il faut faire les calculs, alors que ce soit maintenant, un peu plus dans 256 ou encore plus dans 2048 ms, je pense pas que ça puisse ameliorer les choses... Au contraire meme.
Enfin tout ça c'est des sortes d'elucubrations, je suis pas specialiste en la matiere.
Bonne nuit

www.lesousmarin.net

6
Salut, pour moi il me semble que un buffer de 2048 ça me fait planter.
par contre c'est vrai qu'en passant de 256 à 1024 en taille de buffer, je gagne pas mal de ressource proc, au détriment de la latence certes, mais qui permet de rajouter un ou deux plugs au mix.
7

Citation : les buffers "stoquent" 512 ms ... Il faut faire les calculs, alors que ce soit maintenant, un peu plus dans 256 ou encore plus dans 2048 ms, je pense pas que ça puisse ameliorer les choses...



Heureusement que la taille des buffer ne reflète pas les ms , avec une latence de 512 ms dur dur de jouer :oo: , en plus le minimum en taille de buffer que je connaisse = 32 , même 32 ms c'est injouable ...

Je ne suis pas un grand spécialiste en informatique , mais ce sont en fait le nombre de sample qui vont être traiter (par paquet) , exemple 256 samples = environ à 6 ms ( 256 / 44100 Hz ) . En trés gros, quand tu fais play sur ton log. le premier paquet de sample part du DD et passe par le moteur audio (driver asio + proç.) les calculs sont faient tu entend enfin le son . Pendant ce temps un autre paquet est arrivé pour le calcul ... ainsi de suite
Maintenant on double la taille de buffer 512 , le moteur audio a 2 fois + de temps pour effectuer le calcul donc il peut se permettre de faire fonctioner d'autres prog. exemple des plug .

Conclusion : Si ta taille de buffer n'est pas au maximum , il te reste encore de la ressource . Attention car c'est relativement pénible de travailler dans ces conditions , les vu-mêtre réagissent avant le son !!!!
A 2048 ou 4096 ça fait une grosse latence mais ça peut dépanner .

Hors sujet : Du moins c'est ce que je crois savoir :clin:

Ma devise ... TRANQUILLE !!!!!!
8
:mdr:
En effet, hihihi, n'importe quoi, faut que j'arrete la biere!!! c pas 512ms mais 512 samples!
Mais ça change pas gd chose a mon idée, le fait de charger deux fois plus de samples avant de lancer la lecture ne vas pas changer le nombre de calcul sur la chanson entiere...
Je m'explique:
La lecture est en temps réel, alors que le CPU ai 512 samples a traiter toutes les 6ms ou 1024 toutes les 12ms, a priori c pareil.
Bon cela dit c pas tout a fait vrai non plus, pask'il faut considerer la moyenne sur la durée de la chanson, et qu'avoir des samples d'avances va permetre au processeur de bosser (virtuellement) a 110% de temps en temps, a 90% à d'autres moments.
Cela dit, je reste totalement dans la suputation metaphysique raportée à l'âme d'un DAW... Il faudrait qu'un concepteur de DAW nous explique.
En conclusion, quand on en arrive a se poser ce genre de questions, c qu'on arrive au bout du rouleau de son CPU et de son HD et qu'il vaut mieux changer de machine, paske c bidouilles permettent de grapiller qques %CPU, mais ps de koi relancer une carriere.

www.lesousmarin.net

9
Ha si, j'oubliais,
y a un truc qui m'a fait gagner plus de 50% de temps CPU:
-je suis repassé à l'analogique :clin:
-g jeté les 3/4 de mes plugs

Mon ordi n'est plus qu'un magneto evolué (qques plugs, les plus zarbi, et l'automation du volume et mute)
J'peux lire plus de 80 pistes sans depasser 30% CPU avec un vieux AMD athlon 2800+, et en plus, ça sonne bien mieux au final
(j'avoue c plus le meme budget)

www.lesousmarin.net

10
Pourquoi dis tu que "ce n'est plus même budget" ?
Un plug c est pas gratuit.