Carte son et qualité d'export
- 12 réponses
- 6 participants
- 1 473 vues
- 6 followers

Kortes
54

Posteur·euse AFfranchi·e
Membre depuis 17 ans
Sujet de la discussion Posté le 02/06/2022 à 07:43:34Carte son et qualité d'export
Bonjour à tous, je me posais une question quant à l'utilité d'une carte son.
Est-ce qu'une carte son permet un export de meilleur qualité (daw > wav) ou elle n'a pas d'influence, seul le moteur audio du daw compte ?
Je comprends l'utilité pour l'acquisition à travers les preamps et le ADC, et la restitution à travers le dac, aussi le fait qu'elle décharge le cpu (tiens d'ailleurs comment se faisse ?) mais si on reste dans le domaine du numérique a-t-elle une quelconque utilité ?
Voilà quelques questions qui posent dans ma tête sans avoir de réponse, donc je me tourne vers la communauté pour m'éclairer.
Merci à vous.
Est-ce qu'une carte son permet un export de meilleur qualité (daw > wav) ou elle n'a pas d'influence, seul le moteur audio du daw compte ?
Je comprends l'utilité pour l'acquisition à travers les preamps et le ADC, et la restitution à travers le dac, aussi le fait qu'elle décharge le cpu (tiens d'ailleurs comment se faisse ?) mais si on reste dans le domaine du numérique a-t-elle une quelconque utilité ?
Voilà quelques questions qui posent dans ma tête sans avoir de réponse, donc je me tourne vers la communauté pour m'éclairer.
Merci à vous.

TAMPCO Pedals
3615

Squatteur·euse d’AF
Membre depuis 10 ans
2 Posté le 02/06/2022 à 15:24:24
Hello !
C'est ton ordinateur qui fait l'export, pas ta carte son, à moins que tu n'enregistres l'audio en temps réel sur Audacity ou sur une bande magnétique
Je ne suis pas certain que la carte son décharge de beaucoup le processeur ? Il a justement plus de contrôles, d'entrées et de sorties à gérer simultanément (quelqu'un aurait des chiffres ?).
Après pour l'acquisition et l'écoute c'est effectivement une autre problématique. Pour l'export pur et dur aucune différence je pense.
C'est ton ordinateur qui fait l'export, pas ta carte son, à moins que tu n'enregistres l'audio en temps réel sur Audacity ou sur une bande magnétique

Je ne suis pas certain que la carte son décharge de beaucoup le processeur ? Il a justement plus de contrôles, d'entrées et de sorties à gérer simultanément (quelqu'un aurait des chiffres ?).
Après pour l'acquisition et l'écoute c'est effectivement une autre problématique. Pour l'export pur et dur aucune différence je pense.
0
Ancienement appelé The Koala

Graffy
601

Posteur·euse AFfolé·e
Membre depuis 20 ans
3 Posté le 02/06/2022 à 15:51:24
A ce niveau là si je puis dire, la qualité du résultat va surtout se faire sur la conversion et donc le ou les dac qui équipent la carte son.
Pour l’encodage puisque c’est de cela dont tu parles, du moment que ta machine est assez puissante et supporte les formats voulus mais cela n’aura pas ou très peu d’incidence sur le résultat en comparaison de la qualité des préamps et des convertisseurs pour la numérisation.
Exemple vécu, j’avais une Focusrite 18i20 3ème génération qui est une très bonne carte, facile à utiliser..Et quand je suis passé à l’Antelope discrete 8 SC, j’ai vu ou plutôt j’ai écouté la différence, il n’y avait pas photo que ce soit au monitoring ou le rendu final sur le ssd.
Pour l’encodage puisque c’est de cela dont tu parles, du moment que ta machine est assez puissante et supporte les formats voulus mais cela n’aura pas ou très peu d’incidence sur le résultat en comparaison de la qualité des préamps et des convertisseurs pour la numérisation.
Exemple vécu, j’avais une Focusrite 18i20 3ème génération qui est une très bonne carte, facile à utiliser..Et quand je suis passé à l’Antelope discrete 8 SC, j’ai vu ou plutôt j’ai écouté la différence, il n’y avait pas photo que ce soit au monitoring ou le rendu final sur le ssd.
0
[ Dernière édition du message le 02/06/2022 à 15:57:00 ]

Kortes
54

Posteur·euse AFfranchi·e
Membre depuis 17 ans
4 Posté le 03/06/2022 à 03:28:29
Ok c'est bien ce que je pensais, la carte n'est pas utile à l'encodage.
Pour la décharge CPU, j'ai vu la différence nettement, après peut être que ça vient des drivers je sais pas trop...
Pour la décharge CPU, j'ai vu la différence nettement, après peut être que ça vient des drivers je sais pas trop...
0

Snowfall
1681

AFicionado·a
Membre depuis 12 ans
5 Posté le 03/06/2022 à 04:19:31
J'aurais tendance à dire que ça peut aider le CPU tout comme lui demander plus de travail selon la taille du buffer. Plus elle est basse plus le CPU va devoir travailler, à l'inverse, on peut l'augmenter bien plus que ce que ne propose Windows, donc à ce moment-là ça aide le CPU.
C'est une théorie sortie de mon chapeau, à voir si certains peuvent la confirmer ou l'infirmer.
C'est une théorie sortie de mon chapeau, à voir si certains peuvent la confirmer ou l'infirmer.
1

Eric Music Strasbourg
4598

Squatteur·euse d’AF
Membre depuis 18 ans
6 Posté le 03/06/2022 à 08:28:58
Citation de Snowfall :
J'aurais tendance à dire que ça peut aider le CPU tout comme lui demander plus de travail selon la taille du buffer. Plus elle est basse plus le CPU va devoir travailler, à l'inverse, on peut l'augmenter bien plus que ce que ne propose Windows, donc à ce moment-là ça aide le CPU.
C'est une théorie sortie de mon chapeau, à voir si certains peuvent la confirmer ou l'infirmer.
l'histoire du buffer est totalement vraie, et tu lèves une question intéressante: si on regarde les soft de chez Steinberg cubase nuendo, on constate que suivant notre manière d'utiliser le soft il est parfois obligatoire d'exporter nos compos en temps réel. du coup sur la qualité même il pourrait bien avoir un résultat plus au moins différent.
Je repense à un article sur le realtime d'un ordinateur et je fais le parallèle.
si mon échantillonnage est de 44100 fois par seconde il faut que l'ordinateur est assez de puissance ou de temps si on est pas en temps réel musical pour donner le résultat.
Snow a "raison" quand il dit qu'un grand buffer baisse la conso cpu. en fait ca ne baisse pas vraiment la conso en tant que nombre de calculs pour obtenir le résultat car ils seront identiques mais laisse plus de temps au cpu en ayant un temps de latence entre l'entrée et la sortie du signal pour donner le résultat final. ca c'est lors de l'enregistrement et de la lecture
Lors de l'export il n' y a plus rien qui rentre. mais la question qui se pose c'est : puisque on est souvent en temps réel pour l'export le cpu a t'il le temps de donner le résultat exacte de chaque traitement et la sommation à la fin...
En temps réel lorsque le cpu est trop chargé il n'a plus le temps et ca donne un glitch audio un décrochage fort désagréable. ok ! mais alors quid en export?
y aurait il une approximation si le cpu est en forte surcharge... perso je dirais oui, parce qu'il n' y aucune raison pour que le cpu qui a le devoir de donner les résultats en temps et en heure ne soit pas à bout de souffle si on lui en demande trop, livrant ainsi parfois des approximations.
Perso lors des mix je règle le buffer sur 1024 voir 2048. le coté chiant c'est que quand j'arrête la lecture j'ai encore le signal un petit temps... comme si on n'était pas en temps réel... derniers vidages de buffers? peut être bien.
Par contre mon cpu est en net baisse pour traiter tout le mix les périphériques.. bref tout.
Du coup ton intuition n'est pas idiote du tout snow parce qu'une fois que le cpu est au maximum de ses possibilités de rendu il rend des résultats qui ne sont déjà plus utiles parce que la sommation du signal a déjà eu lieu mais est donc erronée
Darkmoon avait expliqué que le realtime est une pure imagination de notre esprit. en vérité le cpu bosse avec plein de process en parallèles. c'est une image mais on peut imaginer que si mon process qui s'occupe de la compression donne le résultat du signal de sortie après que la sommation des signaux ait été calculée mon résultat sera donc approximatif d'où l'intérêt de ne pas bosser en temps réel pour les exports. on laisse le cpu faire ce qu'il a à faire et il n'est pas "stressé" outre mesure...
si on prend reaper par exemple, les développeurs ont pris comme parti pris de calculer en amont le résultat de la sommation audio (comme un grand buffer dont on calculerait le résultat tout le temps et dont on livrerait le résultat que si on en a besoin (lecture du signal ou enregistrement donc les deux). Du coup la charge cpu visible sur le barre graphe ce conso cpu diminue puisque on ne demande pas soudain au cpu un résultat qui demande beaucoup de calcul.
Steinberg semble ne pas avoir pris cette option et seul la taille du buffer de la carte son nous laisse un peu de répi. il y a bien l'asio guard, mai scelle ci augmente la charge cpu parce que justement une part du cpu est réservé à un process peut etre du même type mais peut être moins bien pensé et qui semble prendre les devants pour être certain qu'il n'y aura pas de décrochage cpu créant des glitschs... mais le moteur audio lui même n'a pas été reprogrammé (ca coute cher) parce que sinon Steinberg en aurait sans doute profité pour modifier aussi le fait qu'il n'y ait plus de coupure du son lorsque on ajoute un vsti... tous les utilisateurs râlent de cette coupure. mais elle témoigne du fait qu'une buffeurisation interne n'est pas capable de supporter une interruption trop longue tel l'ouverture d'un nouveau vsti.. si cette buffeurisation était plus grande alors il n'y aurait pas de coupure. imaginons que nous ayant 4 buffers interne au moteur audio. chaque buffer fait 1 seconde. ils sont calculés en amont pour la lecture des données internes déjà enregistrées. ainsi si j'ajoute un vsti les buffers de précalcule de résultat laisse le temps au cpu d'ouvrir le vsti... le moteur audio continue sa petite lecture et s'en fout... cette réflexion permet de voir que c'est la philosophie même du soft et du moteur audio qui permettra par exemple de ne pas avoir de coupures audio... mais je pense que pour l'export on est dans les mêmes problématiques.
bon désolé je me suis peut etre un peu beaucoup éloigné du sujet de départ mais en même temps ca permet de mieux comprendre les interactions..
pour revenir à la question TAMPCO Pedals a raison... la carte son en tant que telle n'a pas d'interaction endehors d'une possibilité de mettre un buffer de plus grande taille qui laisse le cpu faire autre chose en un même temps imparti.
je ne suis pas un expert de tout cela mais c'est ce que j'ai compris de mes lectures et ai pu constaté lors des exports... ceci dit je peux me tromper mais si Darkmoon passe par là il pourrait nous dire le vrai du faux...
0
Eric
[ Dernière édition du message le 03/06/2022 à 08:30:56 ]

Kortes
54

Posteur·euse AFfranchi·e
Membre depuis 17 ans
7 Posté le 05/06/2022 à 01:54:45
Citation de Eric :
bon désolé je me suis peut etre un peu beaucoup éloigné du sujet de départ mais en même temps ca permet de mieux comprendre les interactions..
Non non c'est clair et concis

0

Anonyme

8 Posté le 05/06/2022 à 09:45:38
- la carte son n'intervient pas dans le bounce
- le temps réel n'existe pas
- la sommation est une opération ultra-simple
- pseudo temps-réel ou offline, le résultat sera le même (exception faite des variables aléatoires, comme toujours, peu importe la façon de faire l'export)
- augmenter les tampons permettra de laisser de la marge au processeur
- pas de offline si insertion de traitements externes
- le temps réel n'existe pas
- la sommation est une opération ultra-simple
- pseudo temps-réel ou offline, le résultat sera le même (exception faite des variables aléatoires, comme toujours, peu importe la façon de faire l'export)
- augmenter les tampons permettra de laisser de la marge au processeur
- pas de offline si insertion de traitements externes
1

Eric Music Strasbourg
4598

Squatteur·euse d’AF
Membre depuis 18 ans
9 Posté le 05/06/2022 à 18:35:20
Citation de Gulistan :
- la carte son n'intervient pas dans le bounce
- le temps réel n'existe pas
- la sommation est une opération ultra-simple
- pseudo temps-réel ou offline, le résultat sera le même (exception faite des variables aléatoires, comme toujours, peu importe la façon de faire l'export)
- augmenter les tampons permettra de laisser de la marge au processeur
- pas de offline si insertion de traitements externes
Un beau résumé. D'ailleurs que nous soyons précis quand cubase exporte il donne en message qu'il ne peut le faire qu'en temps réel. On parle alors de tempo respecté et donc pas d'un export accéléré ce qui peut être fait si on a pas d'instruments externes ( ce qui a été dit juste avant

0
Eric

Snowfall
1681

AFicionado·a
Membre depuis 12 ans
10 Posté le 05/06/2022 à 20:27:15
Est-ce que vous avez déjà pu essayer sous Cubase, avec une session qui décroche à cause de la charge CPU, si l'on entend des glitches sur l'export ? Pas forcément le glitch en lui-même, j'imagine bien, mais un son qui coupe ou quelque chose de comparable ?
Ou bien, si je comprends bien, comme ça n'est pas véritablement du temps réel, le logiciel créé une sorte de buffer temporaire histoire de se laisser une marge lors de l'export ?
Ou bien, si je comprends bien, comme ça n'est pas véritablement du temps réel, le logiciel créé une sorte de buffer temporaire histoire de se laisser une marge lors de l'export ?
0

Anonyme

11 Posté le 05/06/2022 à 21:39:46
En export, pas de glitch, il prendra le temps qu'il faut.
0

Eric Music Strasbourg
4598

Squatteur·euse d’AF
Membre depuis 18 ans
12 Posté le 06/06/2022 à 07:31:57
Citation de Gulistan :
En export, pas de glitch, il prendra le temps qu'il faut.
Sauf que si cubase exige une sortie temps réelle à cause d'instruments externes alors le CPU peut aussi saturer et un glitch par le maque de temps processeur peu apparaître. J'admets que c'est très rare et qu'il faut que la charge CPU soit très forte que toutes les conditions soient réunies à savoir tps réel qui équivaut à une lecture normale, avoir des synthés physiquement câbler en instruments externes dans cubase et une très forte charge CPU à travers des vsti vstfx.
Le glitch apparaît pour les mêmes raisons que quand on joue ou enregistre : le temps réel CPU n'existe pas et que comme les process sont en parallèles si l'un des process n'a.plus le temps de résoudre ce qu'il doit rendre ça peut devenir catastrophe. J'ai pu le constater et même aller jusqu'au plantage de l'export qui s'arrête tout simplement.
Après il faut vraiment surcharger la machine..
0
Eric

Eric Music Strasbourg
4598

Squatteur·euse d’AF
Membre depuis 18 ans
13 Posté le 06/06/2022 à 07:36:33
Pour en avoir le coeur net si vous avez cubase. Chargez une composition, mettez un buffer assez petit 128. Utilisez des instruments externes câblés vsti lancez l'export et vous aurez le résultat. Diminuez encore le buffer et vous pourrez aller jusqu'au plantage machine. Ou alors ma machine a un gros souci mais je n'y crois pas trop. Après autre point j'utilise beaucoup de vsti a5 modélisation physique qui provoque une charge CPU hyper lourde.
Le test le plus simple et de prendre une piste de 4 ou 5 mn
Et de la dupliquer jusqu'à saturation CPU. Attention ne pas oublier de mettre un limiteur en sortie sinon bonjour les dégâts...
Si vous pouvez faire ce test et me dire si vous arrivez au même résultat que moi ça m'intéresse, sait on jamais que tous comptes fait ce soit ma machine qui déconne, mais comme je l'ai dit plus haut je n'y crois pas je pense vraiment que c'est la charge CPU qui devient trop importante.
Par contre si l'export n'est pas temps réel (en respectant le Tempo de la compo) alors pour une compo de 4 minutes si il y a très forte surcharge CPU il mettra peut être 6 ou 7 mn mais réussira à faire l'export puisque le CPU prend le temps qui lui est nécessaire.
Gulistan, tu crois que tu pourrais avoir le temps de faire le test?
En tous cas le moteur audio de Steinberg n'a pas évolué semble t'il depuis un moment. Les utilisateurs demandent le fait qu'il n'y ait plus de coupure audio quand on charge un vsti mais il semble que cette option demande une réécriture complète du moteur audio pour le développer avec une autre vision une autre philosophie.
Juste un autre point est ce que quelqu'un peut modifier la valeur du asioguard en mettant de bas à élevé (ce ne sont peut être pas les termes exactes je n'ai pas la machine devant les yeux. Mais j'ai remarqué que plus je mets une valeur sensée protéger le système des fortes charges CPU... Plus la charge CPU est elle même élevée ce qui n'a pas de sens voir qui est un contre sens puisque le but est d'éviter la surcharge cpu.
Faites vous la même constatation ?
Le test le plus simple et de prendre une piste de 4 ou 5 mn
Et de la dupliquer jusqu'à saturation CPU. Attention ne pas oublier de mettre un limiteur en sortie sinon bonjour les dégâts...
Si vous pouvez faire ce test et me dire si vous arrivez au même résultat que moi ça m'intéresse, sait on jamais que tous comptes fait ce soit ma machine qui déconne, mais comme je l'ai dit plus haut je n'y crois pas je pense vraiment que c'est la charge CPU qui devient trop importante.
Par contre si l'export n'est pas temps réel (en respectant le Tempo de la compo) alors pour une compo de 4 minutes si il y a très forte surcharge CPU il mettra peut être 6 ou 7 mn mais réussira à faire l'export puisque le CPU prend le temps qui lui est nécessaire.
Gulistan, tu crois que tu pourrais avoir le temps de faire le test?
En tous cas le moteur audio de Steinberg n'a pas évolué semble t'il depuis un moment. Les utilisateurs demandent le fait qu'il n'y ait plus de coupure audio quand on charge un vsti mais il semble que cette option demande une réécriture complète du moteur audio pour le développer avec une autre vision une autre philosophie.
Juste un autre point est ce que quelqu'un peut modifier la valeur du asioguard en mettant de bas à élevé (ce ne sont peut être pas les termes exactes je n'ai pas la machine devant les yeux. Mais j'ai remarqué que plus je mets une valeur sensée protéger le système des fortes charges CPU... Plus la charge CPU est elle même élevée ce qui n'a pas de sens voir qui est un contre sens puisque le but est d'éviter la surcharge cpu.
Faites vous la même constatation ?
0
Eric
[ Dernière édition du message le 06/06/2022 à 07:59:37 ]
- < Liste des sujets
- Charte