Hummm, ton avis est intéressant parce que plutôt subjectif pour quelqu'un qui n'utilise pas PulseAudio. Voici le mien :
Avant PA il y'avait clairement un manque côté pile audio sous linux. Dire que dmix (le mixage logiciel pour ALSA) était/est une solution n'est valable que pour le mec qui utilise encore un PC type bureau en ne branchant jamais rien dessus. Rappelons que ALSA ne gére QUE les cartes son internes et usb. Donc rien pour le firewire, le bluetooth ou le réseau. Ne parlons même pas de fonctionnalitées avancées (suppression de l'echo, ducking, …)
Jack a, lui, clairement une vocation professionnelle : réduire la latence au maximum pour permettre à des applications PRO de faire du monitoring/overdub/multi-pistes/synth… en temps réel. Est il le fait très bien.
PA s'est toujours voulu orienté "consumer audio" pas "pro audio". Il a donc des fonctions avancées (y'a un gouffre avec dmix) pour l'utilisateur classique qui branche son oreillette et utilise skype (arf… le pauvre).
Ce qu'on lui reproche c'est de ne pas être au niveau de CoreAudio (la pile audio OSX) qui, elle, arrive a concilier les deux. Mais là encore il y a des raisons. En faite une, principalement : ALSA n'est pas souple au niveau de sa gestion des tampons mémoires : explications [english]. CoreAudio sait le faire. Comment fait Jack ?? Il utilise un tampon de taille très petite, ce qui garanti une lantence très faible. Le problème c'est que seul les cartes avec une électronique pro et un processeur musclé arrivent a tenir la charge… (+ un kernel aux oignons + rtlimits + …)
"Ouai, enfin, mon PulseAudio bouffe 151% de mon CPU !". Là aussi il y'a une raison. Ce qui coûte cher en audio c'est les IRQs et le rééchantillonnage. Les IRQs c'est vu plus haut. Le rééchantillonnage : Jack ou dmix imposent le taux d'échantillonnage, et c'est a l'application de faire avec, la charge CPU va donc au client. PulseAudio essaye de trouver le bon compromis et rééchantillone lui même, c'est lui qui prend la charge. Ce qui ne veux pas dire que PA est exempt de bugs !
"Mais on peux très bien utiliser Jack sans RT ou faible latence". Certe. M'enfin niveau fonctionnalitées avancés on reppasera : un client veux jouer un son stéréo sur une carte 5.1 > il se connecte aux deux premier ports de la carte son > si c'est pas les deux L/R ben… il faut redistribuer à la main…
De par son architecture "lock-free" et "zero-copy" (en faite, comme celle de Jack) PulseAudio est à priori capable de faire du temps réel comme Jack. Mais l'orientation et clairement à la légèreté et la faible consomation d'énergie, les dévellopements ne vont pas dans ce sens.
On peux par contre regréter la mauvaise intégration avec Jack (PA deviens un simple client Jack quand celui ci se lance) : on notera un manque de volonté côté Jack qui ne veux pas entendre parlé de DBus (pour négocier la main sur ALSA, m'enfin ça va mieux depuis qu'il existe 36 version de Jack) et un retard côté PA dont le pilote Jack est plutôt (très) naze.
Notons quand même que seul Jack est capable de faire cracher les watts à une carte firewire (via libffado,). Mais (toutes ??) les cartes firewire sont des cartes pro…
Après si pour prouver ses dires il faut donner un exemple de quand ça marche pas, je vous laisse fouiner dans les buzilla respectifs de chaque projet à la recherche d'une pépité confirmant votre thèse. Je m'épargne cette peine.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par tchaik . En réponse à la dépêche Sortie de PulseAudio 4.0. Évalué à 10.
Hummm, ton avis est intéressant parce que plutôt subjectif pour quelqu'un qui n'utilise pas PulseAudio. Voici le mien :
Avant PA il y'avait clairement un manque côté pile audio sous linux. Dire que dmix (le mixage logiciel pour ALSA) était/est une solution n'est valable que pour le mec qui utilise encore un PC type bureau en ne branchant jamais rien dessus. Rappelons que ALSA ne gére QUE les cartes son internes et usb. Donc rien pour le firewire, le bluetooth ou le réseau. Ne parlons même pas de fonctionnalitées avancées (suppression de l'echo, ducking, …)
Jack a, lui, clairement une vocation professionnelle : réduire la latence au maximum pour permettre à des applications PRO de faire du monitoring/overdub/multi-pistes/synth… en temps réel. Est il le fait très bien.
PA s'est toujours voulu orienté "consumer audio" pas "pro audio". Il a donc des fonctions avancées (y'a un gouffre avec dmix) pour l'utilisateur classique qui branche son oreillette et utilise skype (arf… le pauvre).
Ce qu'on lui reproche c'est de ne pas être au niveau de CoreAudio (la pile audio OSX) qui, elle, arrive a concilier les deux. Mais là encore il y a des raisons. En faite une, principalement : ALSA n'est pas souple au niveau de sa gestion des tampons mémoires : explications [english]. CoreAudio sait le faire. Comment fait Jack ?? Il utilise un tampon de taille très petite, ce qui garanti une lantence très faible. Le problème c'est que seul les cartes avec une électronique pro et un processeur musclé arrivent a tenir la charge… (+ un kernel aux oignons + rtlimits + …)
"Ouai, enfin, mon PulseAudio bouffe 151% de mon CPU !". Là aussi il y'a une raison. Ce qui coûte cher en audio c'est les IRQs et le rééchantillonnage. Les IRQs c'est vu plus haut. Le rééchantillonnage : Jack ou dmix imposent le taux d'échantillonnage, et c'est a l'application de faire avec, la charge CPU va donc au client. PulseAudio essaye de trouver le bon compromis et rééchantillone lui même, c'est lui qui prend la charge. Ce qui ne veux pas dire que PA est exempt de bugs !
"Mais on peux très bien utiliser Jack sans RT ou faible latence". Certe. M'enfin niveau fonctionnalitées avancés on reppasera : un client veux jouer un son stéréo sur une carte 5.1 > il se connecte aux deux premier ports de la carte son > si c'est pas les deux L/R ben… il faut redistribuer à la main…
De par son architecture "lock-free" et "zero-copy" (en faite, comme celle de Jack) PulseAudio est à priori capable de faire du temps réel comme Jack. Mais l'orientation et clairement à la légèreté et la faible consomation d'énergie, les dévellopements ne vont pas dans ce sens.
On peux par contre regréter la mauvaise intégration avec Jack (PA deviens un simple client Jack quand celui ci se lance) : on notera un manque de volonté côté Jack qui ne veux pas entendre parlé de DBus (pour négocier la main sur ALSA, m'enfin ça va mieux depuis qu'il existe 36 version de Jack) et un retard côté PA dont le pilote Jack est plutôt (très) naze.
Notons quand même que seul Jack est capable de faire cracher les watts à une carte firewire (via libffado,). Mais (toutes ??) les cartes firewire sont des cartes pro…
Après si pour prouver ses dires il faut donner un exemple de quand ça marche pas, je vous laisse fouiner dans les buzilla respectifs de chaque projet à la recherche d'une pépité confirmant votre thèse. Je m'épargne cette peine.