Avec l'aide d'Audacity, par exemple, je crée une tonalité de 1000 Hz d'une
durée quelconque que j'exporte vers un fichier 1000.wav. Je peux ensuite
lire ce fichier sur n'importe quel ordinateur et mesurer avec précision et
avec un même fréquencemètre la fréquence du signal délivré en sortie de
carte son.
D'un pc à un autre, j'observe que cette fréquence n'est jamais exactement la
même, l'écart relatif pouvant atteindre 1/10000 (Un dixième de hertz dans
mon exemple) et probablement encore plus avec d'autres pc. Un tel décalage
peut avoir de fâcheuses conséquences quand il s'agit, par exemple, de
diffuser un même contenu musical en différents points d'un même local d'écoute.
J'aimerais savoir si la fréquence mesurée dépend de l'horloge de la carte
son, de celle du processeur, ou d'une autre horloge, et s'il existe des
possibilités de synchronisation permettant de lutter efficacement contre
l'effet signalé.
Le 29/04/2013 16:22, *bilou* a écrit fort à propos :
Bonjour Ca dépend de l'horloge de la carte son qui parfois est dérivée de celle du PC. Les 2 sont souvent très imprécises.et pas stables dans le temps.
Surtout celle de la carte son semble-t-il, du moins des miennes.
J'ai eu des soucis du même genre avec des enregistrements de longue durée sur 24 H on a des décalages de plus de 10 minutes..
Voila en fait l'aspect des choses qui m'intéresse parce que cet effet affecte les softphones au point que certains en perdent pédales en cours de communication. Je n'avais évoqué l'aspect décalage en fréquence que parce qu'il me semble plus frappant et plus facile à mettre en évidence.
En plus le format *.WAV est limité a 2Go Quand on se décale en temps dans un fichier audio le player calcule en prenant la frequence d'échantillonage théorique et on a vite tout faux. Il y a un filtre audio qui sait corriger cela ,utilisé dans les players video / DVD Mais outre que j'ai oublié son nom il procede par suppression ou duplication d'un echantillon tous les "N " et ne corrige pas la frequence exacte du son..
Si les développeurs de Linphone parvenaient à mettre en place une correction aussi subtile, je crois qu'ils résoudraient au mieux un gros problème. Mais faute de pouvoir les y aider, je me propose de faire baisser un peu la fréquence d'horloge de ma carte la plus rapide en ajoutant un condensateur sur une patte du quartz. Je doute toutefois de pouvoir agir suffisamment.
Curieusement cette caractéristique n'est jamais précisée meme sur du materiel audio haut de gamme.
Il existe des horloges étalon et des émetteurs de radio qui en diffusent. Je trouve étonnant que rien ne soit fait pour synchroniser toutes les horloges de tous les ordinateurs du monde sur une même horloge de référence...
Le 29/04/2013 16:22, *bilou* a écrit fort à propos :
Bonjour
Ca dépend de l'horloge de la carte son qui parfois est dérivée de celle du
PC.
Les 2 sont souvent très imprécises.et pas stables dans le temps.
Surtout celle de la carte son semble-t-il, du moins des miennes.
J'ai eu des soucis du même genre avec des enregistrements de longue durée
sur 24 H on a des décalages de plus de 10 minutes..
Voila en fait l'aspect des choses qui m'intéresse parce que cet effet
affecte les softphones au point que certains en perdent pédales en cours de
communication. Je n'avais évoqué l'aspect décalage en fréquence que parce
qu'il me semble plus frappant et plus facile à mettre en évidence.
En plus le format *.WAV est limité a 2Go
Quand on se décale en temps dans un fichier audio le player calcule en
prenant la frequence d'échantillonage théorique et on a vite tout faux.
Il y a un filtre audio qui sait corriger cela ,utilisé dans les players
video / DVD
Mais outre que j'ai oublié son nom il procede par suppression ou duplication
d'un echantillon
tous les "N " et ne corrige pas la frequence exacte du son..
Si les développeurs de Linphone parvenaient à mettre en place une correction
aussi subtile, je crois qu'ils résoudraient au mieux un gros problème. Mais
faute de pouvoir les y aider, je me propose de faire baisser un peu la
fréquence d'horloge de ma carte la plus rapide en ajoutant un condensateur
sur une patte du quartz. Je doute toutefois de pouvoir agir suffisamment.
Curieusement cette caractéristique n'est jamais précisée meme sur du
materiel audio haut de gamme.
Il existe des horloges étalon et des émetteurs de radio qui en diffusent. Je
trouve étonnant que rien ne soit fait pour synchroniser toutes les horloges
de tous les ordinateurs du monde sur une même horloge de référence...
Le 29/04/2013 16:22, *bilou* a écrit fort à propos :
Bonjour Ca dépend de l'horloge de la carte son qui parfois est dérivée de celle du PC. Les 2 sont souvent très imprécises.et pas stables dans le temps.
Surtout celle de la carte son semble-t-il, du moins des miennes.
J'ai eu des soucis du même genre avec des enregistrements de longue durée sur 24 H on a des décalages de plus de 10 minutes..
Voila en fait l'aspect des choses qui m'intéresse parce que cet effet affecte les softphones au point que certains en perdent pédales en cours de communication. Je n'avais évoqué l'aspect décalage en fréquence que parce qu'il me semble plus frappant et plus facile à mettre en évidence.
En plus le format *.WAV est limité a 2Go Quand on se décale en temps dans un fichier audio le player calcule en prenant la frequence d'échantillonage théorique et on a vite tout faux. Il y a un filtre audio qui sait corriger cela ,utilisé dans les players video / DVD Mais outre que j'ai oublié son nom il procede par suppression ou duplication d'un echantillon tous les "N " et ne corrige pas la frequence exacte du son..
Si les développeurs de Linphone parvenaient à mettre en place une correction aussi subtile, je crois qu'ils résoudraient au mieux un gros problème. Mais faute de pouvoir les y aider, je me propose de faire baisser un peu la fréquence d'horloge de ma carte la plus rapide en ajoutant un condensateur sur une patte du quartz. Je doute toutefois de pouvoir agir suffisamment.
Curieusement cette caractéristique n'est jamais précisée meme sur du materiel audio haut de gamme.
Il existe des horloges étalon et des émetteurs de radio qui en diffusent. Je trouve étonnant que rien ne soit fait pour synchroniser toutes les horloges de tous les ordinateurs du monde sur une même horloge de référence...
Geo Cherchetout
Le 29/04/2013 18:43, *Alain Naigeon* a écrit fort à propos :
Oui mais après le microphone, le support d'enregistrement, et la chaîne de reproduction, il y a finalement... une autre oreille ;-)
Bien entendu. ;-)
Le 29/04/2013 18:43, *Alain Naigeon* a écrit fort à propos :
Oui mais après le microphone, le support d'enregistrement, et la chaîne
de reproduction, il y a finalement... une autre oreille ;-)
Le 29/04/2013 18:43, *Alain Naigeon* a écrit fort à propos :
Oui mais après le microphone, le support d'enregistrement, et la chaîne de reproduction, il y a finalement... une autre oreille ;-)
Bien entendu. ;-)
Geo Cherchetout
Le 25/04/2013 22:10, *Alain Naigeon* a écrit fort à propos :
Je n'ai pas la réponse, je remarque simplement que la précision de l'horloge d'un PC en bon état paraît sensiblement meilleure que le 1 / 10 000. En effet, supposons deux synchronisations par ntp à une semaine d'intervalle, ce qui correspond à plus de 600 000 secondes. Le 1 / 10 000 cumulé sur la semaine s'élèverait donc à 60 secondes, ce qui, vous en conviendrez sans doute, est nettement supérieur au décalage que nous pouvons observer en une seule semaine.
Mon expérience personnelle le confirme. Livrés à eux-mêmes, j'ai un des deux ordinateurs de l'expérience initiale qui prend environ deux secondes de retard par jour, mais uniquement pendant ses heures d'arrêt, et l'autre n'a jamais varié de deux secondes en presque une semaine. Le gros décalage signalé ne peut donc pas être imputé à une imprécision des horloges principales des machines.
Le 25/04/2013 22:10, *Alain Naigeon* a écrit fort à propos :
Je n'ai pas la réponse, je remarque simplement que la précision de
l'horloge
d'un PC en bon état paraît sensiblement meilleure que le 1 / 10 000.
En effet, supposons deux synchronisations par ntp à une semaine
d'intervalle, ce qui correspond à plus de 600 000 secondes. Le 1 / 10
000
cumulé sur la semaine s'élèverait donc à 60 secondes, ce qui, vous en
conviendrez sans doute, est nettement supérieur au décalage que nous
pouvons observer en une seule semaine.
Mon expérience personnelle le confirme. Livrés à eux-mêmes, j'ai un des deux
ordinateurs de l'expérience initiale qui prend environ deux secondes de
retard par jour, mais uniquement pendant ses heures d'arrêt, et l'autre n'a
jamais varié de deux secondes en presque une semaine.
Le gros décalage signalé ne peut donc pas être imputé à une imprécision des
horloges principales des machines.
Le 25/04/2013 22:10, *Alain Naigeon* a écrit fort à propos :
Je n'ai pas la réponse, je remarque simplement que la précision de l'horloge d'un PC en bon état paraît sensiblement meilleure que le 1 / 10 000. En effet, supposons deux synchronisations par ntp à une semaine d'intervalle, ce qui correspond à plus de 600 000 secondes. Le 1 / 10 000 cumulé sur la semaine s'élèverait donc à 60 secondes, ce qui, vous en conviendrez sans doute, est nettement supérieur au décalage que nous pouvons observer en une seule semaine.
Mon expérience personnelle le confirme. Livrés à eux-mêmes, j'ai un des deux ordinateurs de l'expérience initiale qui prend environ deux secondes de retard par jour, mais uniquement pendant ses heures d'arrêt, et l'autre n'a jamais varié de deux secondes en presque une semaine. Le gros décalage signalé ne peut donc pas être imputé à une imprécision des horloges principales des machines.
Nicolas George
Geo Cherchetout , dans le message <klt9rn$25s2$, a écrit :
Mon expérience personnelle le confirme. Livrés à eux-mêmes, j'ai un des deux ordinateurs de l'expérience initiale qui prend environ deux secondes de retard par jour, mais uniquement pendant ses heures d'arrêt, et l'autre n'a jamais varié de deux secondes en presque une semaine. Le gros décalage signalé ne peut donc pas être imputé à une imprécision des horloges principales des machines.
As-tu vérifié si NTPd tournait ?
Geo Cherchetout , dans le message <klt9rn$25s2$1@obelix.gegeweb.org>, a
écrit :
Mon expérience personnelle le confirme. Livrés à eux-mêmes, j'ai un des deux
ordinateurs de l'expérience initiale qui prend environ deux secondes de
retard par jour, mais uniquement pendant ses heures d'arrêt, et l'autre n'a
jamais varié de deux secondes en presque une semaine.
Le gros décalage signalé ne peut donc pas être imputé à une imprécision des
horloges principales des machines.
Geo Cherchetout , dans le message <klt9rn$25s2$, a écrit :
Mon expérience personnelle le confirme. Livrés à eux-mêmes, j'ai un des deux ordinateurs de l'expérience initiale qui prend environ deux secondes de retard par jour, mais uniquement pendant ses heures d'arrêt, et l'autre n'a jamais varié de deux secondes en presque une semaine. Le gros décalage signalé ne peut donc pas être imputé à une imprécision des horloges principales des machines.
As-tu vérifié si NTPd tournait ?
Geo Cherchetout
Le 25/04/2013 10:46, j'ai écrit :
Bonjour,
Avec l'aide d'Audacity, par exemple, je crée une tonalité de 1000 Hz d'une durée quelconque que j'exporte vers un fichier 1000.wav. Je peux ensuite lire ce fichier sur n'importe quel ordinateur et mesurer avec précision et avec un même fréquencemètre la fréquence du signal délivré en sortie de carte son.
D'un pc à un autre, j'observe que cette fréquence n'est jamais exactement la même, l'écart relatif pouvant atteindre 1/10000 (Un dixième de hertz dans mon exemple) et probablement encore plus avec d'autres pc. Un tel décalage peut avoir de fâcheuses conséquences quand il s'agit, par exemple, de diffuser un même contenu musical en différents points d'un même local d'écoute.
J'aimerais savoir si la fréquence mesurée dépend de l'horloge de la carte son, de celle du processeur, ou d'une autre horloge, et s'il existe des possibilités de synchronisation permettant de lutter efficacement contre l'effet signalé.
Ne soupçonnant pas l'importance de ce détail, j'avais omis d'indiquer dans l'énoncé le logiciel utilisé pour lire le fichier, et justement j'ai fini par coincer le coupable en la personne de la commande aplay que j'utilise, sous linux, sur un des ordinateurs de l'expérience objet du post initial.
En effet, avec le matériel ordinaire que j'utilise, la fréquence délivrée en sortie de carte son lors de la lecture d'un fichier audio à 3125 Hz par Audacity s'avère être exacte à moins de 1 ppm près, ceci quelle que soit la fréquence d'échantillonnage du fichier parmi 8000, 11025, 16000, 22050, 32000, 44100 et 48000 ech/s. L'erreur est encore plus minime pour un signal généré par la commande siggen qui s'adresse directement au matériel. (Fréquence d'échantillonnage par défaut 22050 Hz). En revanche, avec aplay, la fréquence mesurée excède de 0,44 % sa valeur nominale pour du 3125 Hz à 8000 ech/s. (Pour obtenir un son à 3125 Hz, il me faut lire un fichier enregistré en 3111,33 Hz !) En raison de la lourdeur de mon procédé de mesure, je n'ai pas chiffré l'écart, apparemment très important aussi, pour toutes les fréquences d'échantillonnage. Le seul cas où aplay restitue précisément la fréquence enregistrée dans le fichier lu est pour la fréquence d'échantillonnage 48000 Hz. L'erreur est alors la même qu'avec Audacity, soit 0,7 ppm, je ne suis pas sûr du signe. Les spécialistes d'ALSA sauront, j'espère, m'expliquer le phénomène.
Sans résoudre complètement le problème, utiliser le même logiciel de lecture sur les différents ordinateurs en atténuerait donc déjà beaucoup les effets.
Pour info, j'ai choisi pour des mesures vraiment précises sur un seul ordinateur et une seule carte son la fréquence 3125 Hz parce que c'est le 1/5 du 15625 Hz facile à prélever sur un téléviseur à tube cathodique en fonctionnement, que je considère comme une référence précise et stable. Et 3125 Hz est compatible avec toutes les fréquences d'échantillonnage. La carte son est une très ordinaire Ensoniq CT4810 sur port PCI et je sais pouvoir m'attendre à des erreurs plus importantes avec l'HDA Intel incorporé à la carte mère. À moins que l'erreur due au matériel ne compense celle due au logiciel...
Le 25/04/2013 10:46, j'ai écrit :
Bonjour,
Avec l'aide d'Audacity, par exemple, je crée une tonalité de 1000 Hz d'une
durée quelconque que j'exporte vers un fichier 1000.wav. Je peux ensuite
lire ce fichier sur n'importe quel ordinateur et mesurer avec précision et
avec un même fréquencemètre la fréquence du signal délivré en sortie de
carte son.
D'un pc à un autre, j'observe que cette fréquence n'est jamais exactement la
même, l'écart relatif pouvant atteindre 1/10000 (Un dixième de hertz dans
mon exemple) et probablement encore plus avec d'autres pc. Un tel décalage
peut avoir de fâcheuses conséquences quand il s'agit, par exemple, de
diffuser un même contenu musical en différents points d'un même local d'écoute.
J'aimerais savoir si la fréquence mesurée dépend de l'horloge de la carte
son, de celle du processeur, ou d'une autre horloge, et s'il existe des
possibilités de synchronisation permettant de lutter efficacement contre
l'effet signalé.
Ne soupçonnant pas l'importance de ce détail, j'avais omis d'indiquer dans
l'énoncé le logiciel utilisé pour lire le fichier, et justement j'ai fini
par coincer le coupable en la personne de la commande aplay que j'utilise,
sous linux, sur un des ordinateurs de l'expérience objet du post initial.
En effet, avec le matériel ordinaire que j'utilise, la fréquence délivrée en
sortie de carte son lors de la lecture d'un fichier audio à 3125 Hz par
Audacity s'avère être exacte à moins de 1 ppm près, ceci quelle que soit la
fréquence d'échantillonnage du fichier parmi 8000, 11025, 16000, 22050,
32000, 44100 et 48000 ech/s. L'erreur est encore plus minime pour un signal
généré par la commande siggen qui s'adresse directement au matériel.
(Fréquence d'échantillonnage par défaut 22050 Hz). En revanche, avec aplay,
la fréquence mesurée excède de 0,44 % sa valeur nominale pour du 3125 Hz à
8000 ech/s. (Pour obtenir un son à 3125 Hz, il me faut lire un fichier
enregistré en 3111,33 Hz !)
En raison de la lourdeur de mon procédé de mesure, je n'ai pas chiffré
l'écart, apparemment très important aussi, pour toutes les fréquences
d'échantillonnage. Le seul cas où aplay restitue précisément la fréquence
enregistrée dans le fichier lu est pour la fréquence d'échantillonnage 48000
Hz. L'erreur est alors la même qu'avec Audacity, soit 0,7 ppm, je ne suis
pas sûr du signe.
Les spécialistes d'ALSA sauront, j'espère, m'expliquer le phénomène.
Sans résoudre complètement le problème, utiliser le même logiciel de lecture
sur les différents ordinateurs en atténuerait donc déjà beaucoup les effets.
Pour info, j'ai choisi pour des mesures vraiment précises sur un seul
ordinateur et une seule carte son la fréquence 3125 Hz parce que c'est le
1/5 du 15625 Hz facile à prélever sur un téléviseur à tube cathodique en
fonctionnement, que je considère comme une référence précise et stable. Et
3125 Hz est compatible avec toutes les fréquences d'échantillonnage. La
carte son est une très ordinaire Ensoniq CT4810 sur port PCI et je sais
pouvoir m'attendre à des erreurs plus importantes avec l'HDA Intel incorporé
à la carte mère. À moins que l'erreur due au matériel ne compense celle due
au logiciel...
Avec l'aide d'Audacity, par exemple, je crée une tonalité de 1000 Hz d'une durée quelconque que j'exporte vers un fichier 1000.wav. Je peux ensuite lire ce fichier sur n'importe quel ordinateur et mesurer avec précision et avec un même fréquencemètre la fréquence du signal délivré en sortie de carte son.
D'un pc à un autre, j'observe que cette fréquence n'est jamais exactement la même, l'écart relatif pouvant atteindre 1/10000 (Un dixième de hertz dans mon exemple) et probablement encore plus avec d'autres pc. Un tel décalage peut avoir de fâcheuses conséquences quand il s'agit, par exemple, de diffuser un même contenu musical en différents points d'un même local d'écoute.
J'aimerais savoir si la fréquence mesurée dépend de l'horloge de la carte son, de celle du processeur, ou d'une autre horloge, et s'il existe des possibilités de synchronisation permettant de lutter efficacement contre l'effet signalé.
Ne soupçonnant pas l'importance de ce détail, j'avais omis d'indiquer dans l'énoncé le logiciel utilisé pour lire le fichier, et justement j'ai fini par coincer le coupable en la personne de la commande aplay que j'utilise, sous linux, sur un des ordinateurs de l'expérience objet du post initial.
En effet, avec le matériel ordinaire que j'utilise, la fréquence délivrée en sortie de carte son lors de la lecture d'un fichier audio à 3125 Hz par Audacity s'avère être exacte à moins de 1 ppm près, ceci quelle que soit la fréquence d'échantillonnage du fichier parmi 8000, 11025, 16000, 22050, 32000, 44100 et 48000 ech/s. L'erreur est encore plus minime pour un signal généré par la commande siggen qui s'adresse directement au matériel. (Fréquence d'échantillonnage par défaut 22050 Hz). En revanche, avec aplay, la fréquence mesurée excède de 0,44 % sa valeur nominale pour du 3125 Hz à 8000 ech/s. (Pour obtenir un son à 3125 Hz, il me faut lire un fichier enregistré en 3111,33 Hz !) En raison de la lourdeur de mon procédé de mesure, je n'ai pas chiffré l'écart, apparemment très important aussi, pour toutes les fréquences d'échantillonnage. Le seul cas où aplay restitue précisément la fréquence enregistrée dans le fichier lu est pour la fréquence d'échantillonnage 48000 Hz. L'erreur est alors la même qu'avec Audacity, soit 0,7 ppm, je ne suis pas sûr du signe. Les spécialistes d'ALSA sauront, j'espère, m'expliquer le phénomène.
Sans résoudre complètement le problème, utiliser le même logiciel de lecture sur les différents ordinateurs en atténuerait donc déjà beaucoup les effets.
Pour info, j'ai choisi pour des mesures vraiment précises sur un seul ordinateur et une seule carte son la fréquence 3125 Hz parce que c'est le 1/5 du 15625 Hz facile à prélever sur un téléviseur à tube cathodique en fonctionnement, que je considère comme une référence précise et stable. Et 3125 Hz est compatible avec toutes les fréquences d'échantillonnage. La carte son est une très ordinaire Ensoniq CT4810 sur port PCI et je sais pouvoir m'attendre à des erreurs plus importantes avec l'HDA Intel incorporé à la carte mère. À moins que l'erreur due au matériel ne compense celle due au logiciel...
Geo Cherchetout
Le 02/05/2013 11:07, *Nicolas George* a écrit fort à propos :
As-tu vérifié si NTPd tournait ?
J'avais désactivé ce bazar la semaine dernière avant de me mettre à surveiller les dérives.
Le 02/05/2013 11:07, *Nicolas George* a écrit fort à propos :
As-tu vérifié si NTPd tournait ?
J'avais désactivé ce bazar la semaine dernière avant de me mettre à
surveiller les dérives.
Le 02/05/2013 11:07, *Nicolas George* a écrit fort à propos :
As-tu vérifié si NTPd tournait ?
J'avais désactivé ce bazar la semaine dernière avant de me mettre à surveiller les dérives.
Nicolas George
Geo Cherchetout , dans le message <kltm4n$2u0r$, a écrit :
Les spécialistes d'ALSA sauront, j'espère, m'expliquer le phénomène.
Quel périphérique utilisais-tu ? Si c'est « default » (c'est le cas si tu ne spécifie rien), essaie avec « -D hw:0 » (ou 1 ou 2, cf. /proc/asound/cards).
Geo Cherchetout , dans le message <kltm4n$2u0r$1@obelix.gegeweb.org>, a
écrit :
Les spécialistes d'ALSA sauront, j'espère, m'expliquer le phénomène.
Quel périphérique utilisais-tu ? Si c'est « default » (c'est le cas si tu ne
spécifie rien), essaie avec « -D hw:0 » (ou 1 ou 2, cf. /proc/asound/cards).
Geo Cherchetout , dans le message <kltm4n$2u0r$, a écrit :
Les spécialistes d'ALSA sauront, j'espère, m'expliquer le phénomène.
Quel périphérique utilisais-tu ? Si c'est « default » (c'est le cas si tu ne spécifie rien), essaie avec « -D hw:0 » (ou 1 ou 2, cf. /proc/asound/cards).
Geo Cherchetout
Le 02/05/2013 14:47, *Nicolas George* a écrit fort à propos :
Geo Cherchetout , dans le message <kltm4n$2u0r$, a écrit :
Les spécialistes d'ALSA sauront, j'espère, m'expliquer le phénomène.
Quel périphérique utilisais-tu ? Si c'est « default » (c'est le cas si tu ne spécifie rien), essaie avec « -D hw:0 » (ou 1 ou 2, cf. /proc/asound/cards).
C'était bien hw:0. Je ne peux pas me tromper parce que hw:1 (ou hw:2, je ne l'ai pas devant les yeux) est le chip de la carte mère. De son côté, lors des mesures d'hier, Audacity s'adressait bien aussi au périphérique ALSA et donc à hw:0.
Le 02/05/2013 14:47, *Nicolas George* a écrit fort à propos :
Geo Cherchetout , dans le message <kltm4n$2u0r$1@obelix.gegeweb.org>, a
écrit :
Les spécialistes d'ALSA sauront, j'espère, m'expliquer le phénomène.
Quel périphérique utilisais-tu ? Si c'est « default » (c'est le cas si tu ne
spécifie rien), essaie avec « -D hw:0 » (ou 1 ou 2, cf. /proc/asound/cards).
C'était bien hw:0. Je ne peux pas me tromper parce que hw:1 (ou hw:2, je ne
l'ai pas devant les yeux) est le chip de la carte mère. De son côté, lors
des mesures d'hier, Audacity s'adressait bien aussi au périphérique ALSA et
donc à hw:0.
Le 02/05/2013 14:47, *Nicolas George* a écrit fort à propos :
Geo Cherchetout , dans le message <kltm4n$2u0r$, a écrit :
Les spécialistes d'ALSA sauront, j'espère, m'expliquer le phénomène.
Quel périphérique utilisais-tu ? Si c'est « default » (c'est le cas si tu ne spécifie rien), essaie avec « -D hw:0 » (ou 1 ou 2, cf. /proc/asound/cards).
C'était bien hw:0. Je ne peux pas me tromper parce que hw:1 (ou hw:2, je ne l'ai pas devant les yeux) est le chip de la carte mère. De son côté, lors des mesures d'hier, Audacity s'adressait bien aussi au périphérique ALSA et donc à hw:0.
Nicolas George
Geo Cherchetout , dans le message <kltr2r$64s$, a écrit :
C'était bien hw:0. Je ne peux pas me tromper parce que hw:1 (ou hw:2, je ne l'ai pas devant les yeux) est le chip de la carte mère.
Tu es passé à côté du point important de mon message : as-tu demandé à aplay d'utiliser DIRECTEMENT hw:0, ou bien lui as-tu laissé utiliser « default », qui contient souvent des plugins, au moins plug et dmix, probablement asym aussi.
De son côté, lors des mesures d'hier, Audacity s'adressait bien aussi au périphérique ALSA et donc à hw:0.
C'est suspect, parce que aplay ne va vraiment rien faire activement pour changer la sortie.
Mais la question du périphérique précis utilise se pose pour Audacity aussi bien que pour aplay, bien sûr.
Geo Cherchetout , dans le message <kltr2r$64s$1@obelix.gegeweb.org>, a
écrit :
C'était bien hw:0. Je ne peux pas me tromper parce que hw:1 (ou hw:2, je ne
l'ai pas devant les yeux) est le chip de la carte mère.
Tu es passé à côté du point important de mon message : as-tu demandé à aplay
d'utiliser DIRECTEMENT hw:0, ou bien lui as-tu laissé utiliser « default »,
qui contient souvent des plugins, au moins plug et dmix, probablement asym
aussi.
De son côté, lors
des mesures d'hier, Audacity s'adressait bien aussi au périphérique ALSA et
donc à hw:0.
C'est suspect, parce que aplay ne va vraiment rien faire activement pour
changer la sortie.
Mais la question du périphérique précis utilise se pose pour Audacity aussi
bien que pour aplay, bien sûr.
Geo Cherchetout , dans le message <kltr2r$64s$, a écrit :
C'était bien hw:0. Je ne peux pas me tromper parce que hw:1 (ou hw:2, je ne l'ai pas devant les yeux) est le chip de la carte mère.
Tu es passé à côté du point important de mon message : as-tu demandé à aplay d'utiliser DIRECTEMENT hw:0, ou bien lui as-tu laissé utiliser « default », qui contient souvent des plugins, au moins plug et dmix, probablement asym aussi.
De son côté, lors des mesures d'hier, Audacity s'adressait bien aussi au périphérique ALSA et donc à hw:0.
C'est suspect, parce que aplay ne va vraiment rien faire activement pour changer la sortie.
Mais la question du périphérique précis utilise se pose pour Audacity aussi bien que pour aplay, bien sûr.
Geo Cherchetout
Le 02/05/2013 15:55, *Nicolas George* a écrit fort à propos :
Tu es passé à côté du point important de mon message : as-tu demandé à aplay d'utiliser DIRECTEMENT hw:0, ou bien lui as-tu laissé utiliser « default », qui contient souvent des plugins, au moins plug et dmix, probablement asym aussi.
Je n'avais pas compris parce que je croyais que default était simplement synonyme de hw:0,0. Attends, j'allume l'ordinateur et je regarde dans .bash_history...
Ma commande aplay ne précisait rien et donc « default » était utilisé. Par contre, dans les préférences d'Audacity, hw:0,0 était bien spécifié car on ne peut pas laisser le champ vide.
Je viens de faire quatre mesures rapides avec la fonction fréquencemètre peu précise d'un multimètre :
$ aplay 3125-8000.wav donne 3112,8 Hz
Même valeur avec Audacity en spécifiant default comme périphérique.
$ aplay -D hw:0,0 3125-8000.wav donne 3125,0 Hz
Même valeur avec Audacity en spécifiant hw:0,0
Cette affaire de plugins est pour moi une révélation, merci, je m'en méfierai désormais.
Remarque, je ne vois pas pourquoi l'erreur introduite par ces plugins était hier dans le sens d'une fréquence délivrée supérieure à celle du fichier et aujourd'hui dans le sens opposé, mais ce n'est pas grave.
Merci à tous et à bientôt pour de nouvelles aventures.
Le 02/05/2013 15:55, *Nicolas George* a écrit fort à propos :
Tu es passé à côté du point important de mon message : as-tu demandé à aplay
d'utiliser DIRECTEMENT hw:0, ou bien lui as-tu laissé utiliser « default »,
qui contient souvent des plugins, au moins plug et dmix, probablement asym
aussi.
Je n'avais pas compris parce que je croyais que default était simplement
synonyme de hw:0,0. Attends, j'allume l'ordinateur et je regarde dans
.bash_history...
Ma commande aplay ne précisait rien et donc « default » était utilisé. Par
contre, dans les préférences d'Audacity, hw:0,0 était bien spécifié car on
ne peut pas laisser le champ vide.
Je viens de faire quatre mesures rapides avec la fonction fréquencemètre peu
précise d'un multimètre :
$ aplay 3125-8000.wav donne 3112,8 Hz
Même valeur avec Audacity en spécifiant default comme périphérique.
$ aplay -D hw:0,0 3125-8000.wav donne 3125,0 Hz
Même valeur avec Audacity en spécifiant hw:0,0
Cette affaire de plugins est pour moi une révélation, merci, je m'en
méfierai désormais.
Remarque, je ne vois pas pourquoi l'erreur introduite par ces plugins était
hier dans le sens d'une fréquence délivrée supérieure à celle du fichier et
aujourd'hui dans le sens opposé, mais ce n'est pas grave.
Merci à tous et à bientôt pour de nouvelles aventures.
Le 02/05/2013 15:55, *Nicolas George* a écrit fort à propos :
Tu es passé à côté du point important de mon message : as-tu demandé à aplay d'utiliser DIRECTEMENT hw:0, ou bien lui as-tu laissé utiliser « default », qui contient souvent des plugins, au moins plug et dmix, probablement asym aussi.
Je n'avais pas compris parce que je croyais que default était simplement synonyme de hw:0,0. Attends, j'allume l'ordinateur et je regarde dans .bash_history...
Ma commande aplay ne précisait rien et donc « default » était utilisé. Par contre, dans les préférences d'Audacity, hw:0,0 était bien spécifié car on ne peut pas laisser le champ vide.
Je viens de faire quatre mesures rapides avec la fonction fréquencemètre peu précise d'un multimètre :
$ aplay 3125-8000.wav donne 3112,8 Hz
Même valeur avec Audacity en spécifiant default comme périphérique.
$ aplay -D hw:0,0 3125-8000.wav donne 3125,0 Hz
Même valeur avec Audacity en spécifiant hw:0,0
Cette affaire de plugins est pour moi une révélation, merci, je m'en méfierai désormais.
Remarque, je ne vois pas pourquoi l'erreur introduite par ces plugins était hier dans le sens d'une fréquence délivrée supérieure à celle du fichier et aujourd'hui dans le sens opposé, mais ce n'est pas grave.
Merci à tous et à bientôt pour de nouvelles aventures.
