Déphasage entre quoi et quoi? Pour qu'il y ait interférences, il faut plusieurs sources cohérentes, et pour que les sources soient cohérentes il faut qu'elle sortent de la même carte son.
Et pour qu'il n'y ait pas le déphasage dont tu parles, il faut que les deux sources soit proches l'une de l'autre. Si tu dis que 0.1ms et trop long, ça revient à dire qu'il faut placer tes deux sources a moins de 4cm l'une de l'autre pour que "la phase" ne change pas pendant la propagation du son. Ça n'a pas de sens, ne serait ce que parce que la taille des haut-parleurs est souvent supérieure à 4cm.
Non, désolé, c'est très simple. Tu as déjà écrit du soft pour ça? Il suffit d'envoyer le son puis d'utiliser l'horloge de la carte son (numéro échantillon qu'elle est en train de lire) et d'afficher les images au bon moment. Toutes les APIs audio exposent ça d'une façon ou d'une autre.
C'est pas faux. Mais il n'y a pas que ca. Passer des blocs d'échantillons d'un endroit à l'autre d'un format à l'autre (c'est essentiellement ce que fait le système) ne coûte pas grand chose. Que ce soit du "pro" ou du "desktop". L'audio est tellement simple, que si le système consommait trop de ressources, j'aurai envie de dire qu'il y a des choses à revoir.
Si on regarde ce que fait une carte audio, qu'elle soit pci, usb, ou autre, en gros elle echantillonne et/ou reconstitue le signal analogique. On ne lui demande rien d'autre: jouer et enregistrer, et ça c'est simple. Le système, lui, a juste à fournir les primitives pour que les programmes puissent utiliser la carte son; en gros ça revient à fournir des drivers qui exposent une interface commune. Ça aussi c'est simple, même si c'est beaucoup de boulot.
Alors qu'est-ce qui a changé? qu'est ce qui est devenu compliqué?
À mon humble avis on a multiplié les apis (esd, arts, alsa, oss, sun, pulse, sndio, portaudio et j'en passe) et il en résulte du code plein de couches de compatibilité, chronophages et sources de faux problèmes. À l'opposé, dans l'audio "pro" il n'y a qu'une api (jack). Pour le matériel c'est similaire.
Le fond du problème est que ça coûte bien plus cher en temps et en énergie de produire du code simple et élégant que d'empiler des couches d'abstractions.
En disant ça, je ne suis pas en train de casser du bois sur pulseaudio (que je connais que très peu), bien au contraire, je trouve que Lennart cherche à résoudre le problème ci-dessus. Alors notre rôle dans tout ça serait simplement de refuser le matériel et le logiciel complexe ou obscur et de soutenir ce qui nous paraît simple et pérenne; c'est un avis très personnel.
Exemple, si BSD n'offre pas d'équivalent aux cgroup, il dommage de se passer de cette fonctionnalité qui est une énorme avancée. Ca comble une grosse lacune. On avance ou on attend qu'hypothétiquement tout les systèmes existant implémentent une fonctionnalité équivalente ?
Le fond du problème est qu'on ne maîtrise plus les deamons qui tournent sur nos bécanes. Alors plutôt que de les améliorer, de les rendre déterministes, faire qu'ils se terminent quand on le leur demande, qu'est-ce qu'on fait? On écrit un framework qui nettoie les débris qu'ils laissent. On ajoute un framework pour cacher le problème.
Peut-être que d'autres OS préfèrent rendre les choses plus déterministes et se passer du besoin de cgroup ou équivalent.
L'ironie, c'est que les piles audio pour les applications professionnelles peuvent généralement être implémentées beaucoup plus simplement que celles pour l'audio grand-public et pour les périphériques mobiles.
Ou autrement dit, pour lire un pauv .mp3 et pour que gnome fasse "dring" on déroule des lignes et des lignes de code. Alors que les "pro" arrivent à faire des choses bien plus complexes beaucoup plus simplement. Bizarre non? Personne n'y voit de problème? Bref, je suis tristement d'accord avec Lennart.
Et l'ironie c'est que nous, developpeurs, on continue à écrire des framework de framework de framework de plus en plus baroques, pour résoudre un problème bien résolu depuis des décenies: jouer et enregistrer un son.
Au final, on quotionne un modèle où même les choses simples deviennent lourdes
et compliquées. Où le soft aura beau être open-source, progressivement il deviendra compliqué et inaccessible, peut-être au point où plus grand monde ne saura le modifier; au final, est-ce si différent d'un binaire gratuit?
[^] # Re: quel est le besoin en matière de son?
Posté par ratchov . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 1.
Oups. Bien sur. Merci
[^] # Re: quel est le besoin en matière de son?
Posté par ratchov . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à -6.
Non, c'est bien ça le sujet: personne n'a besoin de 0.1ms de latence.
[^] # Re: quel est le besoin en matière de son?
Posté par ratchov . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 3.
Déphasage entre quoi et quoi? Pour qu'il y ait interférences, il faut plusieurs sources cohérentes, et pour que les sources soient cohérentes il faut qu'elle sortent de la même carte son.
Et pour qu'il n'y ait pas le déphasage dont tu parles, il faut que les deux sources soit proches l'une de l'autre. Si tu dis que 0.1ms et trop long, ça revient à dire qu'il faut placer tes deux sources a moins de 4cm l'une de l'autre pour que "la phase" ne change pas pendant la propagation du son. Ça n'a pas de sens, ne serait ce que parce que la taille des haut-parleurs est souvent supérieure à 4cm.
[^] # Re: quel est le besoin en matière de son?
Posté par ratchov . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 2.
Non, désolé, c'est très simple. Tu as déjà écrit du soft pour ça? Il suffit d'envoyer le son puis d'utiliser l'horloge de la carte son (numéro échantillon qu'elle est en train de lire) et d'afficher les images au bon moment. Toutes les APIs audio exposent ça d'une façon ou d'une autre.
[^] # Re: quel est le besoin en matière de son?
Posté par ratchov . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à -1.
0.1ms est le temps que le son met à parcourir 4cm. Il faut rester tout près des haut-parleurs pour bien l'apprécier une aussi petite latence :)
Je ne pense pas que quelqu'un essaie d'utiliser de telles latences, ni même que ça marche.
[^] # Re: quel est le besoin en matière de son?
Posté par ratchov . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 3.
C'est pas faux. Mais il n'y a pas que ca. Passer des blocs d'échantillons d'un endroit à l'autre d'un format à l'autre (c'est essentiellement ce que fait le système) ne coûte pas grand chose. Que ce soit du "pro" ou du "desktop". L'audio est tellement simple, que si le système consommait trop de ressources, j'aurai envie de dire qu'il y a des choses à revoir.
[^] # Re: quel est le besoin en matière de son?
Posté par ratchov . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 8.
Si on regarde ce que fait une carte audio, qu'elle soit pci, usb, ou autre, en gros elle echantillonne et/ou reconstitue le signal analogique. On ne lui demande rien d'autre: jouer et enregistrer, et ça c'est simple. Le système, lui, a juste à fournir les primitives pour que les programmes puissent utiliser la carte son; en gros ça revient à fournir des drivers qui exposent une interface commune. Ça aussi c'est simple, même si c'est beaucoup de boulot.
Alors qu'est-ce qui a changé? qu'est ce qui est devenu compliqué?
À mon humble avis on a multiplié les apis (esd, arts, alsa, oss, sun, pulse, sndio, portaudio et j'en passe) et il en résulte du code plein de couches de compatibilité, chronophages et sources de faux problèmes. À l'opposé, dans l'audio "pro" il n'y a qu'une api (jack). Pour le matériel c'est similaire.
Le fond du problème est que ça coûte bien plus cher en temps et en énergie de produire du code simple et élégant que d'empiler des couches d'abstractions.
En disant ça, je ne suis pas en train de casser du bois sur pulseaudio (que je connais que très peu), bien au contraire, je trouve que Lennart cherche à résoudre le problème ci-dessus. Alors notre rôle dans tout ça serait simplement de refuser le matériel et le logiciel complexe ou obscur et de soutenir ce qui nous paraît simple et pérenne; c'est un avis très personnel.
[^] # Re: Ça fait peur
Posté par ratchov . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 6.
Le fond du problème est qu'on ne maîtrise plus les deamons qui tournent sur nos bécanes. Alors plutôt que de les améliorer, de les rendre déterministes, faire qu'ils se terminent quand on le leur demande, qu'est-ce qu'on fait? On écrit un framework qui nettoie les débris qu'ils laissent. On ajoute un framework pour cacher le problème.
Peut-être que d'autres OS préfèrent rendre les choses plus déterministes et se passer du besoin de cgroup ou équivalent.
# quel est le besoin en matière de son?
Posté par ratchov . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 10.
Ou autrement dit, pour lire un pauv .mp3 et pour que gnome fasse "dring" on déroule des lignes et des lignes de code. Alors que les "pro" arrivent à faire des choses bien plus complexes beaucoup plus simplement. Bizarre non? Personne n'y voit de problème? Bref, je suis tristement d'accord avec Lennart.
Et l'ironie c'est que nous, developpeurs, on continue à écrire des framework de framework de framework de plus en plus baroques, pour résoudre un problème bien résolu depuis des décenies: jouer et enregistrer un son.
Au final, on quotionne un modèle où même les choses simples deviennent lourdes
et compliquées. Où le soft aura beau être open-source, progressivement il deviendra compliqué et inaccessible, peut-être au point où plus grand monde ne saura le modifier; au final, est-ce si différent d'un binaire gratuit?