Avec JACK, les deux solutions me permettent d'obtenir une latence audio dans JACK aussi faible qu'une milliseconde, ce qui me permet d'avoir un système fiable dans tous les cas avec une latence comprise entre 10 et 20 ms. Un kernel standard ne permet de faire ça qu'avec RT_GROUP_SCHED.
Il montre pourquoi l'audio est un gros bordel sous GNU/Linux. Il montre aussi deux choses sur Lennart. D'abord c'est un mec plein de bonne volonté et qui s'investit beaucoup. Ensuite il a un ego disproportionné et quand sa solution n'est pas adoptée ou est critiquée, plutôt que d'accepter la critique et discuter de ce qui peut être changé, il se braque et traite ses interlocuteurs de "desktop haters". Ce qui clos la discussion.
Avec JACK, et une dizaine de lignes dans mon .asoundrc, j'interface JACK et les applications ALSA, ceci sans latence supplémentaire, et chaque application ALSA apparaît dans le graphe de connexion de qjackctl, j'obtiens à peu près la même chose qu'avec pulseaudio, mais avec une latence constance au lieu d'avoir une latence qui augmente au premier xrun dans pulseaudio, avec comme seule possibilité pour la faire redescendre de devoir stopper et redémarrer pulse. http://www.linuxmao.org/ALSA+Router+un+flux+ALSA+vers+JACK Quand je vois ça, je suis sur et certain que si la communauté audio pro avait été écoutée, au lieu de développer un système non professionnel comme pulseauedio, il aurait été possible, en construisant uniquement sur ALSA et JACK, d'obtenir la même chose, mais mieux car professionnel, et ceci vraisemblablement avec bien moins d'efforts que ceux qui ont été mis en oeuvre pour développer pulse, car toutes les briques de base existent.
Quand à systemd, selon plusieurs développeurs de la LAD (liste Linux Audio Development), même si certains d'entre eux l'utilisent, il est en train de devenir un plus grand problème que celui qu'il est censé résoudre, ceci pour la raison que systemd fourni des politiques de gestion du système au lieu de fournir les moyens de créer des politiques de gestion. Ce qui limite la liberté du choix des utilisateurs de créer leurs propres politiques de gestion du système. Et quand je parle de ce problème avec eux, les développeurs de systemd me répondent que Linux n'a jamais été une question de choix, ce qui clos toute discussion.
Je comprends très bien, étant moi-même manager de plusieurs projets, que la liberté de choix d'un développeur peut venir en conflit avec la liberté de choix des utilisateurs, mais j'estime aussi que cela fait partie du devoir d'un développeur, s'il casse quelque chose offert à ses utilisateurs, de proposer une nouvelle façon de le faire. Pour cela, je suis toujours très clair avec les nouveaux développeurs qui joignent mes projets: ils peuvent faire ce qu'ils veulent tant qu'ils ne cassent pas les fonctions existantes des programmes. Ils peuvent les modifier, mais les fonctionnalités présentes avant leurs modifications doivent continuer à exister.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Scheduler Temps reel
Posté par Domi . En réponse au message Les cgroups et systemd. Évalué à 1. Dernière modification le 14 janvier 2014 à 15:16.
Le patch -rt, comme RT_GROUP_SCHED, apportent quelque chose en plus. Voir http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler?page=0
Avec JACK, les deux solutions me permettent d'obtenir une latence audio dans JACK aussi faible qu'une milliseconde, ce qui me permet d'avoir un système fiable dans tous les cas avec une latence comprise entre 10 et 20 ms. Un kernel standard ne permet de faire ça qu'avec RT_GROUP_SCHED.
Un autre article intéressant sur l'audio est celui-ci: http://lwn.net/Articles/339316/
Il montre pourquoi l'audio est un gros bordel sous GNU/Linux. Il montre aussi deux choses sur Lennart. D'abord c'est un mec plein de bonne volonté et qui s'investit beaucoup. Ensuite il a un ego disproportionné et quand sa solution n'est pas adoptée ou est critiquée, plutôt que d'accepter la critique et discuter de ce qui peut être changé, il se braque et traite ses interlocuteurs de "desktop haters". Ce qui clos la discussion.
Avec JACK, et une dizaine de lignes dans mon .asoundrc, j'interface JACK et les applications ALSA, ceci sans latence supplémentaire, et chaque application ALSA apparaît dans le graphe de connexion de qjackctl, j'obtiens à peu près la même chose qu'avec pulseaudio, mais avec une latence constance au lieu d'avoir une latence qui augmente au premier xrun dans pulseaudio, avec comme seule possibilité pour la faire redescendre de devoir stopper et redémarrer pulse. http://www.linuxmao.org/ALSA+Router+un+flux+ALSA+vers+JACK Quand je vois ça, je suis sur et certain que si la communauté audio pro avait été écoutée, au lieu de développer un système non professionnel comme pulseauedio, il aurait été possible, en construisant uniquement sur ALSA et JACK, d'obtenir la même chose, mais mieux car professionnel, et ceci vraisemblablement avec bien moins d'efforts que ceux qui ont été mis en oeuvre pour développer pulse, car toutes les briques de base existent.
Quand à systemd, selon plusieurs développeurs de la LAD (liste Linux Audio Development), même si certains d'entre eux l'utilisent, il est en train de devenir un plus grand problème que celui qu'il est censé résoudre, ceci pour la raison que systemd fourni des politiques de gestion du système au lieu de fournir les moyens de créer des politiques de gestion. Ce qui limite la liberté du choix des utilisateurs de créer leurs propres politiques de gestion du système. Et quand je parle de ce problème avec eux, les développeurs de systemd me répondent que Linux n'a jamais été une question de choix, ce qui clos toute discussion.
Je comprends très bien, étant moi-même manager de plusieurs projets, que la liberté de choix d'un développeur peut venir en conflit avec la liberté de choix des utilisateurs, mais j'estime aussi que cela fait partie du devoir d'un développeur, s'il casse quelque chose offert à ses utilisateurs, de proposer une nouvelle façon de le faire. Pour cela, je suis toujours très clair avec les nouveaux développeurs qui joignent mes projets: ils peuvent faire ce qu'ils veulent tant qu'ils ne cassent pas les fonctions existantes des programmes. Ils peuvent les modifier, mais les fonctionnalités présentes avant leurs modifications doivent continuer à exister.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.