Quand il sort une nouvelle version du noyau, il apparaît
automatiquement une nouvelle version compilée de ALSA. Le nom du
paquet pour le driver porte même la version du noyau. Ainsi pour le
noyau 2.4.27, on a: alsa-driver-1.0.6a_2.4.27-i486-1.tgz
Dans Slackware, ce driver fonctionne-t-il seulement avec le noyau
bare.i ? Si je recompile le noyau pour avoir l'acpi ou le SMP, par
exemple, dois-je recompiler aussi les modules?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
no_spam
On Mon, 04 Oct 2004 14:46:50 -0400, GP wrote:
Quand il sort une nouvelle version du noyau, il apparaît automatiquement une nouvelle version compilée de ALSA. Le nom du paquet pour le driver porte même la version du noyau. Ainsi pour le noyau 2.4.27, on a: alsa-driver-1.0.6a_2.4.27-i486-1.tgz
Dans Slackware, ce driver fonctionne-t-il seulement avec le noyau bare.i ?
Tout dépend comment il est compilé, etc... Donc, quand on ne sait pas, il est plus prudent de recompiler
Si je recompile le noyau pour avoir l'acpi ou le SMP, par exemple, dois-je recompiler aussi les modules?
l'ACPI ne doit pas interférer avec les modules ALSA. Par contre, passer en SMP implique de recompier tous les drivers: il faut que les "spinlocks" soient de vrais verrous partagés entre les CPUs, alors que ce sont des structures vides quand on utilise qu'un CPU. Et si jamais il n'y avait pas spinlock dans un driver, c'est soit juste une "driver de protocole", soit un driver buggé... De même, un passage en kernel préemptif ou les options de la MMU imposent une recompilation totale.
Des références seraient appréciées.
grep -r spinlock /usr/src/linux/* et less /usr/src/linux/include/linux/spinlock.h J'ai pas mieux...
On Mon, 04 Oct 2004 14:46:50 -0400, GP wrote:
Quand il sort une nouvelle version du noyau, il apparaît
automatiquement une nouvelle version compilée de ALSA. Le nom du
paquet pour le driver porte même la version du noyau. Ainsi pour le
noyau 2.4.27, on a: alsa-driver-1.0.6a_2.4.27-i486-1.tgz
Dans Slackware, ce driver fonctionne-t-il seulement avec le noyau
bare.i ?
Tout dépend comment il est compilé, etc...
Donc, quand on ne sait pas, il est plus prudent de recompiler
Si je recompile le noyau pour avoir l'acpi ou le SMP, par
exemple, dois-je recompiler aussi les modules?
l'ACPI ne doit pas interférer avec les modules ALSA.
Par contre, passer en SMP implique de recompier tous les drivers:
il faut que les "spinlocks" soient de vrais verrous partagés entre les
CPUs, alors que ce sont des structures vides quand on utilise qu'un CPU.
Et si jamais il n'y avait pas spinlock dans un driver, c'est soit juste
une "driver de protocole", soit un driver buggé...
De même, un passage en kernel préemptif ou les options de la MMU
imposent une recompilation totale.
Des références seraient appréciées.
grep -r spinlock /usr/src/linux/*
et less /usr/src/linux/include/linux/spinlock.h
J'ai pas mieux...
Quand il sort une nouvelle version du noyau, il apparaît automatiquement une nouvelle version compilée de ALSA. Le nom du paquet pour le driver porte même la version du noyau. Ainsi pour le noyau 2.4.27, on a: alsa-driver-1.0.6a_2.4.27-i486-1.tgz
Dans Slackware, ce driver fonctionne-t-il seulement avec le noyau bare.i ?
Tout dépend comment il est compilé, etc... Donc, quand on ne sait pas, il est plus prudent de recompiler
Si je recompile le noyau pour avoir l'acpi ou le SMP, par exemple, dois-je recompiler aussi les modules?
l'ACPI ne doit pas interférer avec les modules ALSA. Par contre, passer en SMP implique de recompier tous les drivers: il faut que les "spinlocks" soient de vrais verrous partagés entre les CPUs, alors que ce sont des structures vides quand on utilise qu'un CPU. Et si jamais il n'y avait pas spinlock dans un driver, c'est soit juste une "driver de protocole", soit un driver buggé... De même, un passage en kernel préemptif ou les options de la MMU imposent une recompilation totale.
Des références seraient appréciées.
grep -r spinlock /usr/src/linux/* et less /usr/src/linux/include/linux/spinlock.h J'ai pas mieux...
GP
no_spam wrote:
l'ACPI ne doit pas interférer avec les modules ALSA. Par contre, passer en SMP implique de recompier tous les drivers: il faut que les "spinlocks" soient de vrais verrous partagés entre les CPUs, alors que ce sont des structures vides quand on utilise qu'un CPU. Et si jamais il n'y avait pas spinlock dans un driver, c'est soit juste une "driver de protocole", soit un driver buggé... De même, un passage en kernel préemptif ou les options de la MMU imposent une recompilation totale.
Tu sembles bien connaître le sujet, mais il me semble que les gens de chez ALSA tiennent peu compte de ceux qui n'y connaissent rien et qui n'ont d'autre préoccupation que /la musique joue/ :)
C'est à peine si on retrouve des instructions pour dire qu'il faut changer de modules quand on change de kernel. Et pour quand on doit recompiler, c'est la nuit noire.
Et ALSA est censé simplifier les choses par rapport à la situation précédente.
GP
no_spam wrote:
l'ACPI ne doit pas interférer avec les modules ALSA.
Par contre, passer en SMP implique de recompier tous les drivers:
il faut que les "spinlocks" soient de vrais verrous partagés entre les
CPUs, alors que ce sont des structures vides quand on utilise qu'un CPU.
Et si jamais il n'y avait pas spinlock dans un driver, c'est soit juste
une "driver de protocole", soit un driver buggé...
De même, un passage en kernel préemptif ou les options de la MMU
imposent une recompilation totale.
Tu sembles bien connaître le sujet, mais il me semble que les gens de
chez ALSA tiennent peu compte de ceux qui n'y connaissent rien et qui
n'ont d'autre préoccupation que /la musique joue/ :)
C'est à peine si on retrouve des instructions pour dire qu'il faut
changer de modules quand on change de kernel. Et pour quand on doit
recompiler, c'est la nuit noire.
Et ALSA est censé simplifier les choses par rapport à la situation
précédente.
l'ACPI ne doit pas interférer avec les modules ALSA. Par contre, passer en SMP implique de recompier tous les drivers: il faut que les "spinlocks" soient de vrais verrous partagés entre les CPUs, alors que ce sont des structures vides quand on utilise qu'un CPU. Et si jamais il n'y avait pas spinlock dans un driver, c'est soit juste une "driver de protocole", soit un driver buggé... De même, un passage en kernel préemptif ou les options de la MMU imposent une recompilation totale.
Tu sembles bien connaître le sujet, mais il me semble que les gens de chez ALSA tiennent peu compte de ceux qui n'y connaissent rien et qui n'ont d'autre préoccupation que /la musique joue/ :)
C'est à peine si on retrouve des instructions pour dire qu'il faut changer de modules quand on change de kernel. Et pour quand on doit recompiler, c'est la nuit noire.
Et ALSA est censé simplifier les choses par rapport à la situation précédente.
GP
no_spam
On Mon, 04 Oct 2004 16:23:56 -0400, GP wrote:
no_spam wrote:
l'ACPI ne doit pas interférer avec les modules ALSA. Par contre, passer en SMP implique de recompier tous les drivers: il faut que les "spinlocks" soient de vrais verrous partagés entre les CPUs, alors que ce sont des structures vides quand on utilise qu'un CPU. Et si jamais il n'y avait pas spinlock dans un driver, c'est soit juste une "driver de protocole", soit un driver buggé... De même, un passage en kernel préemptif ou les options de la MMU imposent une recompilation totale.
Tu sembles bien connaître le sujet, mais il me semble que les gens de chez ALSA tiennent peu compte de ceux qui n'y connaissent rien et qui n'ont d'autre préoccupation que /la musique joue/ :)
Ce n'est pas un problème lié à ALSA, mais au kernel.
C'est à peine si on retrouve des instructions pour dire qu'il faut changer de modules quand on change de kernel. Et pour quand on doit recompiler, c'est la nuit noire.
Ca dépend des versions du noyau, des options de départ et des options d'arrivée. C'est quelque chose qui devrait être documenté dans le kernel, les développeurs d'ALSA n'y sont pour rien. Si la doc existait, ils devraient à la rigueur ajouter un lien vers cette doc...
Et ALSA est censé simplifier les choses par rapport à la situation précédente.
Il ne me semble pas que le but d'ALSA soit de simplifier les choses. L'architecture ALSA est bien plus complexe que celle d'OSS. Par contre, elle permet de faire bien plus de choses, bien qu'il en manque encore: il manque au minimum le contrôle à l'octet près des buffers sons (au moins pour savoir combien d'octets ont été joué dans un buffer, ça simplifierai beaucoup les problèmes de synchro audio/vidéo...).
On Mon, 04 Oct 2004 16:23:56 -0400, GP wrote:
no_spam wrote:
l'ACPI ne doit pas interférer avec les modules ALSA.
Par contre, passer en SMP implique de recompier tous les drivers:
il faut que les "spinlocks" soient de vrais verrous partagés entre les
CPUs, alors que ce sont des structures vides quand on utilise qu'un CPU.
Et si jamais il n'y avait pas spinlock dans un driver, c'est soit juste
une "driver de protocole", soit un driver buggé...
De même, un passage en kernel préemptif ou les options de la MMU
imposent une recompilation totale.
Tu sembles bien connaître le sujet, mais il me semble que les gens de
chez ALSA tiennent peu compte de ceux qui n'y connaissent rien et qui
n'ont d'autre préoccupation que /la musique joue/ :)
Ce n'est pas un problème lié à ALSA, mais au kernel.
C'est à peine si on retrouve des instructions pour dire qu'il faut
changer de modules quand on change de kernel. Et pour quand on doit
recompiler, c'est la nuit noire.
Ca dépend des versions du noyau, des options de départ et des options
d'arrivée. C'est quelque chose qui devrait être documenté dans le
kernel, les développeurs d'ALSA n'y sont pour rien. Si la doc existait,
ils devraient à la rigueur ajouter un lien vers cette doc...
Et ALSA est censé simplifier les choses par rapport à la situation
précédente.
Il ne me semble pas que le but d'ALSA soit de simplifier les choses.
L'architecture ALSA est bien plus complexe que celle d'OSS. Par contre,
elle permet de faire bien plus de choses, bien qu'il en manque encore: il
manque au minimum le contrôle à l'octet près des buffers sons (au moins
pour savoir combien d'octets ont été joué dans un buffer, ça
simplifierai beaucoup les problèmes de synchro audio/vidéo...).
l'ACPI ne doit pas interférer avec les modules ALSA. Par contre, passer en SMP implique de recompier tous les drivers: il faut que les "spinlocks" soient de vrais verrous partagés entre les CPUs, alors que ce sont des structures vides quand on utilise qu'un CPU. Et si jamais il n'y avait pas spinlock dans un driver, c'est soit juste une "driver de protocole", soit un driver buggé... De même, un passage en kernel préemptif ou les options de la MMU imposent une recompilation totale.
Tu sembles bien connaître le sujet, mais il me semble que les gens de chez ALSA tiennent peu compte de ceux qui n'y connaissent rien et qui n'ont d'autre préoccupation que /la musique joue/ :)
Ce n'est pas un problème lié à ALSA, mais au kernel.
C'est à peine si on retrouve des instructions pour dire qu'il faut changer de modules quand on change de kernel. Et pour quand on doit recompiler, c'est la nuit noire.
Ca dépend des versions du noyau, des options de départ et des options d'arrivée. C'est quelque chose qui devrait être documenté dans le kernel, les développeurs d'ALSA n'y sont pour rien. Si la doc existait, ils devraient à la rigueur ajouter un lien vers cette doc...
Et ALSA est censé simplifier les choses par rapport à la situation précédente.
Il ne me semble pas que le but d'ALSA soit de simplifier les choses. L'architecture ALSA est bien plus complexe que celle d'OSS. Par contre, elle permet de faire bien plus de choses, bien qu'il en manque encore: il manque au minimum le contrôle à l'octet près des buffers sons (au moins pour savoir combien d'octets ont été joué dans un buffer, ça simplifierai beaucoup les problèmes de synchro audio/vidéo...).
GP
no_spam wrote:
il manque au minimum le contrôle à l'octet près des buffers sons (au moins pour savoir combien d'octets ont été joué dans un buffer, ça simplifierai beaucoup les problèmes de synchro audio/vidéo...).
Vous m'en direz tant! :) Bon, encore une fois, il faudra faire avec. On peut toujours dire au débutant d'essayer avec les modules pour bare.i pour voir ce que ça donne.
Merci de tes renseignements!
GP
no_spam wrote:
il
manque au minimum le contrôle à l'octet près des buffers sons (au moins
pour savoir combien d'octets ont été joué dans un buffer, ça
simplifierai beaucoup les problèmes de synchro audio/vidéo...).
Vous m'en direz tant! :) Bon, encore une fois, il faudra faire avec.
On peut toujours dire au débutant d'essayer avec les modules pour
bare.i pour voir ce que ça donne.
il manque au minimum le contrôle à l'octet près des buffers sons (au moins pour savoir combien d'octets ont été joué dans un buffer, ça simplifierai beaucoup les problèmes de synchro audio/vidéo...).
Vous m'en direz tant! :) Bon, encore une fois, il faudra faire avec. On peut toujours dire au débutant d'essayer avec les modules pour bare.i pour voir ce que ça donne.
