[...]
> > Oui, j'ai apporté qq modifs à mon fichier de conf', mais je ne
> > pense pas que tes erreurs viennent de là (surtout si tu ne les
> > avais pas avant). À la rigueur, l'autorisation RT (j'ai pensé que
> > c'était *déjà* fait): realtime-scheduling = yes
> > (elle est à 'no' par défaut)
>
> Non je n'y ai pas touché j'ai juste le high-priority
Oui mais non, je fatigue là, c'est 'high-priority' l'important,
le no-scheduling ne devrait pas générer tes messages d'erreur.
[...]
> > Mais ça dépend de ta CPU et de ta mémoire.
>
> 2Gio et Dual Core T7300
Ben tu dois pouvoir augmenter tout ça, mais je ne
pourrai pas t'aider, j'ai fait ça il y a longtemps,
je ne me souviens plus à quoi correspondent les valeurs
des vars exactement.
Mais tout est là :
'man pulse-daemon.conf'
D'autre part il y a pas mal de trucs intéressants là :
[...]
> > Oui, j'ai apporté qq modifs à mon fichier de conf', mais je ne
> > pense pas que tes erreurs viennent de là (surtout si tu ne les
> > avais pas avant). À la rigueur, l'autorisation RT (j'ai pensé que
> > c'était *déjà* fait): realtime-scheduling = yes
> > (elle est à 'no' par défaut)
>
> Non je n'y ai pas touché j'ai juste le high-priority
Oui mais non, je fatigue là, c'est 'high-priority' l'important,
le no-scheduling ne devrait pas générer tes messages d'erreur.
[...]
> > Mais ça dépend de ta CPU et de ta mémoire.
>
> 2Gio et Dual Core T7300
Ben tu dois pouvoir augmenter tout ça, mais je ne
pourrai pas t'aider, j'ai fait ça il y a longtemps,
je ne me souviens plus à quoi correspondent les valeurs
des vars exactement.
Mais tout est là :
'man pulse-daemon.conf'
D'autre part il y a pas mal de trucs intéressants là :
[...]
> > Oui, j'ai apporté qq modifs à mon fichier de conf', mais je ne
> > pense pas que tes erreurs viennent de là (surtout si tu ne les
> > avais pas avant). À la rigueur, l'autorisation RT (j'ai pensé que
> > c'était *déjà* fait): realtime-scheduling = yes
> > (elle est à 'no' par défaut)
>
> Non je n'y ai pas touché j'ai juste le high-priority
Oui mais non, je fatigue là, c'est 'high-priority' l'important,
le no-scheduling ne devrait pas générer tes messages d'erreur.
[...]
> > Mais ça dépend de ta CPU et de ta mémoire.
>
> 2Gio et Dual Core T7300
Ben tu dois pouvoir augmenter tout ça, mais je ne
pourrai pas t'aider, j'ai fait ça il y a longtemps,
je ne me souviens plus à quoi correspondent les valeurs
des vars exactement.
Mais tout est là :
'man pulse-daemon.conf'
D'autre part il y a pas mal de trucs intéressants là :
> Hé ! Dis-donc !? Sois poli, hein ! :)
> J'utilise *blackbox* moi, môssieur. :D
Milles excuses mon Seigneur! ;)
> >
> > > P.S. : Pas la peine de me mettre en CC: de tes posts, je suis la
> > > ML.
> >
> > Désolé je n'avais pas vu. C'est parce que tu as remplis le
> > reply-to ...
> Yep !
> Il est différent du 'From:', pour ça.
Pourtant je reçois la même adresse dans les deux ???
> Hé ! Dis-donc !? Sois poli, hein ! :)
> J'utilise *blackbox* moi, môssieur. :D
Milles excuses mon Seigneur! ;)
> >
> > > P.S. : Pas la peine de me mettre en CC: de tes posts, je suis la
> > > ML.
> >
> > Désolé je n'avais pas vu. C'est parce que tu as remplis le
> > reply-to ...
> Yep !
> Il est différent du 'From:', pour ça.
Pourtant je reçois la même adresse dans les deux ???
> Hé ! Dis-donc !? Sois poli, hein ! :)
> J'utilise *blackbox* moi, môssieur. :D
Milles excuses mon Seigneur! ;)
> >
> > > P.S. : Pas la peine de me mettre en CC: de tes posts, je suis la
> > > ML.
> >
> > Désolé je n'avais pas vu. C'est parce que tu as remplis le
> > reply-to ...
> Yep !
> Il est différent du 'From:', pour ça.
Pourtant je reçois la même adresse dans les deux ???
> > Non je n'y ai pas touché j'ai juste le high-priority
> Oui mais non, je fatigue là , c'est 'high-priority' l'important,
> le no-scheduling ne devrait pas générer tes messages d'erreur .
Me too, d'ailleurs je vais aller voir morphée ;)
> je ne me souviens plus à quoi correspondent les valeurs
> des vars exactement.
> Mais tout est là :
> 'man pulse-daemon.conf'
Oui et non, ils n'expliquent pas la signification des valeurs. Par
exemple ça ne dit pas ce que veux dire -1 pour memlock
Dois manquer un petit lien, non? ;)
Bonne nuit.
> > Non je n'y ai pas touché j'ai juste le high-priority
> Oui mais non, je fatigue là , c'est 'high-priority' l'important,
> le no-scheduling ne devrait pas générer tes messages d'erreur .
Me too, d'ailleurs je vais aller voir morphée ;)
> je ne me souviens plus à quoi correspondent les valeurs
> des vars exactement.
> Mais tout est là :
> 'man pulse-daemon.conf'
Oui et non, ils n'expliquent pas la signification des valeurs. Par
exemple ça ne dit pas ce que veux dire -1 pour memlock
Dois manquer un petit lien, non? ;)
Bonne nuit.
> > Non je n'y ai pas touché j'ai juste le high-priority
> Oui mais non, je fatigue là , c'est 'high-priority' l'important,
> le no-scheduling ne devrait pas générer tes messages d'erreur .
Me too, d'ailleurs je vais aller voir morphée ;)
> je ne me souviens plus à quoi correspondent les valeurs
> des vars exactement.
> Mais tout est là :
> 'man pulse-daemon.conf'
Oui et non, ils n'expliquent pas la signification des valeurs. Par
exemple ça ne dit pas ce que veux dire -1 pour memlock
Dois manquer un petit lien, non? ;)
Bonne nuit.
[...]
> > je ne me souviens plus à quoi correspondent les valeurs
> > des vars exactement.
> > Mais tout est là :
> > 'man pulse-daemon.conf'
>
> Oui et non, ils n'expliquent pas la signification des valeurs. Par
> exemple ça ne dit pas ce que veux dire -1 pour memlock
Oui, mais ils disent *aussi* que si tu veux plus de détails, il faut
faire ça :
'man 2 getrlimit'
Et là, *entre autres* :
RLIMIT_MEMLOCK
Le nombre maximal d’octets de mémoire virtuelle que le processus peut
verrouiller en RAM. En pratique cette limite est arrondie vers le bas
au multiple de la taille de page le plus proche. Cette limite affecte
mlock(2) et mlockall(2) ainsi que l’opération MAP_LOCKED de mmap(2).
Depuis Linux 2.6.9, elle affecte aussi l’opération SHM_LOCK de shmctl
(2), où elle limite le nombre total d’octets dans des segments de
mémoire partagée (voir shmget(2)) que l’UID réel du processus
appelant peut verrouiller. Les verrous de shmctl(2) SHM_LOCK sont
comptés séparément des verrous de mémoire par processus établis par
mlock(2), mlockall(2) et mmap(2) MAP_LOCKED ; un processus peut
verrouiller des octets jusqu’à la limite dans chacune de ces
catégories. Dans les noyaux antérieurs à 2.6.9, cette limite
contrôlait la quantité de mémoire qu’un processus privilégié pouvait
verrouiller. Depuis Linux 2.6.9, un processus privilégie peut
verrouiller autant de mémoire qu’il le souhaite, et cette limite
contrôle la quantité de mémoire pouvant être verrouillée par un
processus non privilégié.
>
> Dois manquer un petit lien, non? ;)
Arf ... ben j'aurais juré qu'il y était !?!
Gasp, le v'la :
[...]
> > je ne me souviens plus à quoi correspondent les valeurs
> > des vars exactement.
> > Mais tout est là :
> > 'man pulse-daemon.conf'
>
> Oui et non, ils n'expliquent pas la signification des valeurs. Par
> exemple ça ne dit pas ce que veux dire -1 pour memlock
Oui, mais ils disent *aussi* que si tu veux plus de détails, il faut
faire ça :
'man 2 getrlimit'
Et là, *entre autres* :
RLIMIT_MEMLOCK
Le nombre maximal d’octets de mémoire virtuelle que le processus peut
verrouiller en RAM. En pratique cette limite est arrondie vers le bas
au multiple de la taille de page le plus proche. Cette limite affecte
mlock(2) et mlockall(2) ainsi que l’opération MAP_LOCKED de mmap(2).
Depuis Linux 2.6.9, elle affecte aussi l’opération SHM_LOCK de shmctl
(2), où elle limite le nombre total d’octets dans des segments de
mémoire partagée (voir shmget(2)) que l’UID réel du processus
appelant peut verrouiller. Les verrous de shmctl(2) SHM_LOCK sont
comptés séparément des verrous de mémoire par processus établis par
mlock(2), mlockall(2) et mmap(2) MAP_LOCKED ; un processus peut
verrouiller des octets jusqu’à la limite dans chacune de ces
catégories. Dans les noyaux antérieurs à 2.6.9, cette limite
contrôlait la quantité de mémoire qu’un processus privilégié pouvait
verrouiller. Depuis Linux 2.6.9, un processus privilégie peut
verrouiller autant de mémoire qu’il le souhaite, et cette limite
contrôle la quantité de mémoire pouvant être verrouillée par un
processus non privilégié.
>
> Dois manquer un petit lien, non? ;)
Arf ... ben j'aurais juré qu'il y était !?!
Gasp, le v'la :
[...]
> > je ne me souviens plus à quoi correspondent les valeurs
> > des vars exactement.
> > Mais tout est là :
> > 'man pulse-daemon.conf'
>
> Oui et non, ils n'expliquent pas la signification des valeurs. Par
> exemple ça ne dit pas ce que veux dire -1 pour memlock
Oui, mais ils disent *aussi* que si tu veux plus de détails, il faut
faire ça :
'man 2 getrlimit'
Et là, *entre autres* :
RLIMIT_MEMLOCK
Le nombre maximal d’octets de mémoire virtuelle que le processus peut
verrouiller en RAM. En pratique cette limite est arrondie vers le bas
au multiple de la taille de page le plus proche. Cette limite affecte
mlock(2) et mlockall(2) ainsi que l’opération MAP_LOCKED de mmap(2).
Depuis Linux 2.6.9, elle affecte aussi l’opération SHM_LOCK de shmctl
(2), où elle limite le nombre total d’octets dans des segments de
mémoire partagée (voir shmget(2)) que l’UID réel du processus
appelant peut verrouiller. Les verrous de shmctl(2) SHM_LOCK sont
comptés séparément des verrous de mémoire par processus établis par
mlock(2), mlockall(2) et mmap(2) MAP_LOCKED ; un processus peut
verrouiller des octets jusqu’à la limite dans chacune de ces
catégories. Dans les noyaux antérieurs à 2.6.9, cette limite
contrôlait la quantité de mémoire qu’un processus privilégié pouvait
verrouiller. Depuis Linux 2.6.9, un processus privilégie peut
verrouiller autant de mémoire qu’il le souhaite, et cette limite
contrôle la quantité de mémoire pouvant être verrouillée par un
processus non privilégié.
>
> Dois manquer un petit lien, non? ;)
Arf ... ben j'aurais juré qu'il y était !?!
Gasp, le v'la :
>>>> "GP" <=> Gaëtan PERRIER
>>>> "GP" <=> Gaëtan PERRIER
>>>> "GP" <=> Gaëtan PERRIER
>>>> "GP" <=> Gaëtan PERRIER
Le(On) Sun, 8 Mar 2009 13:02:38 +0100,
Gaëtan PERRIER écrivait(wrote) :
Bonjour,
bien dormi ?
[...]
Erf... bon, après vérifs, il se trouve que [chez moi] cette page
n'existe -- étrangement -- que dans les man 'fr' que tu ne dois pas
avoir, ça ne te fera pas de mal de les avoir, anyway, donc :
'apt-get install manpages-fr'
devrait faire l'affaire.
>> Et là, *entre autres* :
>>
>> RLIMIT_MEMLOCK Le nombre maximal d’octets de mémoire virtuelle
>> que le processus peut verrouiller en RAM. En pratique cette
>> limite est arrondie vers le bas au multiple de la taille de
[...]
>> >
>> > Dois manquer un petit lien, non? ;)
>> Arf ... ben j'aurais juré qu'il y était !?! Gasp, le v'la :
>>
GP> Ah ben non il n'est toujours pas là... :)
Oué, ben ça me confirme que ça vient bien du webmail Orange
... pfff...
Donc, le voici [3ème ;) ] :
<http://www.pulseaudio.org/wiki/>
Oui, tout ça pour ça ... :)
Pendant que j'y suis, je reviens vite fait sur un truc qui me semble
quand même important (pas le temps cette nuit, il se faisait tard) :
Quand je t'ai parlé de latence, tu m'as répondu 'mp3' et 'vidéo' ...
ahem ... je pensais que tu étais musicien !? Si tu ne comptes pas
faire de la prise de son temps réel, voire du mixage ou autres
joyeusetés, je doute fort que tu aies besoin des capacités temps
réel de pulseaudio.
En tout cas, c'est parfaitement inutile pour écouter de la zik ou
regarder des vidéos.
Du coup, ça m'amène une autre question (dans l'hypothèse où tu
y tiendrais absolument) : Es-tu certain d'avoir un noyau compilé
"remps réel" ?
Vérification :
egrep 'PREEM|HZ' /boot/config | grep y$
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_NO_HZ=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_RCU=y
CONFIG_HZ_1000=y
CONFIG_DEBUG_PREEMPT=y
Il te faut au moins :
CONFIG_PREEMPT=y
CONFIG_HZ_*=y
Au pire si ça ne renvoie rien, teste en module, mais il me semble
bien que ces paramètres ne sont possibles qu'en dur.
Le cas échéant :
egrep 'PREEM|HZ' /boot/config | grep m$
>>>> "GP" <=> Gaëtan PERRIER
Le(On) Sun, 8 Mar 2009 13:02:38 +0100,
Gaëtan PERRIER écrivait(wrote) :
Bonjour,
bien dormi ?
[...]
Erf... bon, après vérifs, il se trouve que [chez moi] cette page
n'existe -- étrangement -- que dans les man 'fr' que tu ne dois pas
avoir, ça ne te fera pas de mal de les avoir, anyway, donc :
'apt-get install manpages-fr'
devrait faire l'affaire.
>> Et là, *entre autres* :
>>
>> RLIMIT_MEMLOCK Le nombre maximal d’octets de mémoire virtuelle
>> que le processus peut verrouiller en RAM. En pratique cette
>> limite est arrondie vers le bas au multiple de la taille de
[...]
>> >
>> > Dois manquer un petit lien, non? ;)
>> Arf ... ben j'aurais juré qu'il y était !?! Gasp, le v'la :
>>
GP> Ah ben non il n'est toujours pas là... :)
Oué, ben ça me confirme que ça vient bien du webmail Orange
... pfff...
Donc, le voici [3ème ;) ] :
<http://www.pulseaudio.org/wiki/>
Oui, tout ça pour ça ... :)
Pendant que j'y suis, je reviens vite fait sur un truc qui me semble
quand même important (pas le temps cette nuit, il se faisait tard) :
Quand je t'ai parlé de latence, tu m'as répondu 'mp3' et 'vidéo' ...
ahem ... je pensais que tu étais musicien !? Si tu ne comptes pas
faire de la prise de son temps réel, voire du mixage ou autres
joyeusetés, je doute fort que tu aies besoin des capacités temps
réel de pulseaudio.
En tout cas, c'est parfaitement inutile pour écouter de la zik ou
regarder des vidéos.
Du coup, ça m'amène une autre question (dans l'hypothèse où tu
y tiendrais absolument) : Es-tu certain d'avoir un noyau compilé
"remps réel" ?
Vérification :
egrep 'PREEM|HZ' /boot/config | grep y$
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_NO_HZ=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_RCU=y
CONFIG_HZ_1000=y
CONFIG_DEBUG_PREEMPT=y
Il te faut au moins :
CONFIG_PREEMPT=y
CONFIG_HZ_*=y
Au pire si ça ne renvoie rien, teste en module, mais il me semble
bien que ces paramètres ne sont possibles qu'en dur.
Le cas échéant :
egrep 'PREEM|HZ' /boot/config | grep m$
>>>> "GP" <=> Gaëtan PERRIER
Le(On) Sun, 8 Mar 2009 13:02:38 +0100,
Gaëtan PERRIER écrivait(wrote) :
Bonjour,
bien dormi ?
[...]
Erf... bon, après vérifs, il se trouve que [chez moi] cette page
n'existe -- étrangement -- que dans les man 'fr' que tu ne dois pas
avoir, ça ne te fera pas de mal de les avoir, anyway, donc :
'apt-get install manpages-fr'
devrait faire l'affaire.
>> Et là, *entre autres* :
>>
>> RLIMIT_MEMLOCK Le nombre maximal d’octets de mémoire virtuelle
>> que le processus peut verrouiller en RAM. En pratique cette
>> limite est arrondie vers le bas au multiple de la taille de
[...]
>> >
>> > Dois manquer un petit lien, non? ;)
>> Arf ... ben j'aurais juré qu'il y était !?! Gasp, le v'la :
>>
GP> Ah ben non il n'est toujours pas là... :)
Oué, ben ça me confirme que ça vient bien du webmail Orange
... pfff...
Donc, le voici [3ème ;) ] :
<http://www.pulseaudio.org/wiki/>
Oui, tout ça pour ça ... :)
Pendant que j'y suis, je reviens vite fait sur un truc qui me semble
quand même important (pas le temps cette nuit, il se faisait tard) :
Quand je t'ai parlé de latence, tu m'as répondu 'mp3' et 'vidéo' ...
ahem ... je pensais que tu étais musicien !? Si tu ne comptes pas
faire de la prise de son temps réel, voire du mixage ou autres
joyeusetés, je doute fort que tu aies besoin des capacités temps
réel de pulseaudio.
En tout cas, c'est parfaitement inutile pour écouter de la zik ou
regarder des vidéos.
Du coup, ça m'amène une autre question (dans l'hypothèse où tu
y tiendrais absolument) : Es-tu certain d'avoir un noyau compilé
"remps réel" ?
Vérification :
egrep 'PREEM|HZ' /boot/config | grep y$
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_NO_HZ=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_RCU=y
CONFIG_HZ_1000=y
CONFIG_DEBUG_PREEMPT=y
Il te faut au moins :
CONFIG_PREEMPT=y
CONFIG_HZ_*=y
Au pire si ça ne renvoie rien, teste en module, mais il me semble
bien que ces paramètres ne sont possibles qu'en dur.
Le cas échéant :
egrep 'PREEM|HZ' /boot/config | grep m$
>>>> "GP" <=> Gaëtan PERRIER
>>>> "GP" <=> Gaëtan PERRIER
>>>> "GP" <=> Gaëtan PERRIER
[...]
GP> Moi j'ai:
GP> $ egrep 'PREEM|HZ' /boot/config-2.6.26-1-686 | grep y$
GP> CONFIG_PREEMPT_NOTIFIERS=y CONFIG_NO_HZ=y
GP> CONFIG_PREEMPT_NONE=y
C'est un bon compromis pour ton utilisation :
This is the traditional Linux preemption model, geared towards
throughput. It will still provide good latencies most of the
time, but there are no guarantees and occasional longer delays
are possible.
GP> CONFIG_HZ_250=y
Bon compromis pour un serveur, mais pour un desktop, tu peux te
permettre "1000" ... mais bon, tu ne vas pas recompiler ton noyau
pour ça. ;)
[...]
Bonne fin d'après-midi ... et de WE ! ;)
[...]
GP> Moi j'ai:
GP> $ egrep 'PREEM|HZ' /boot/config-2.6.26-1-686 | grep y$
GP> CONFIG_PREEMPT_NOTIFIERS=y CONFIG_NO_HZ=y
GP> CONFIG_PREEMPT_NONE=y
C'est un bon compromis pour ton utilisation :
This is the traditional Linux preemption model, geared towards
throughput. It will still provide good latencies most of the
time, but there are no guarantees and occasional longer delays
are possible.
GP> CONFIG_HZ_250=y
Bon compromis pour un serveur, mais pour un desktop, tu peux te
permettre "1000" ... mais bon, tu ne vas pas recompiler ton noyau
pour ça. ;)
[...]
Bonne fin d'après-midi ... et de WE ! ;)
[...]
GP> Moi j'ai:
GP> $ egrep 'PREEM|HZ' /boot/config-2.6.26-1-686 | grep y$
GP> CONFIG_PREEMPT_NOTIFIERS=y CONFIG_NO_HZ=y
GP> CONFIG_PREEMPT_NONE=y
C'est un bon compromis pour ton utilisation :
This is the traditional Linux preemption model, geared towards
throughput. It will still provide good latencies most of the
time, but there are no guarantees and occasional longer delays
are possible.
GP> CONFIG_HZ_250=y
Bon compromis pour un serveur, mais pour un desktop, tu peux te
permettre "1000" ... mais bon, tu ne vas pas recompiler ton noyau
pour ça. ;)
[...]
Bonne fin d'après-midi ... et de WE ! ;)
pulseaudio[5645]: module-esound-compat-spawnfd.c: write(17, 1, 1) failed:
Relais brisé (pipe)
pulseaudio[5645]: module-esound-compat-spawnfd.c: write(17, 1, 1) failed:
Relais brisé (pipe)
pulseaudio[5645]: module-esound-compat-spawnfd.c: write(17, 1, 1) failed:
Relais brisé (pipe)
>>>> "GP" <=> Gaëtan PERRIER
>>>> "GP" <=> Gaëtan PERRIER
>>>> "GP" <=> Gaëtan PERRIER