Re: rengister une parole à partir d'un micro

[Étienne Mollier]

Bernard Schoenacker, le 2017-09-23 :
> > cf sujet en employant que les logiciels libres pour une
> > webradio

Olivier Humbert, le 2017-09-23 :
> Audacity fais ça très bien.

Bonjour,

Audacity est un bon choix.

Si toutefois vous recherchez une solution minimaliste, vous
pouvez regarder du côté de Sound eXchange, paquet "sox".  Pour
vous enregistrer :

$ rec enregistrement.wav

Un simple  permet de stopper l'enregistrement.

Pour rejouer le fichier :

$ play enregistrement.wav

Plus généralement, la commande `sox` permet de travailler avec un
"pipeline" d'effets à appliquer sur des fichiers de son.  Ce
n'est peu être pas une solution recommandée pour débuter, mais ça
peut être pratique de savoir que ça existe.

À plus,
-- 
Étienne Mollier 

Re: XFCE pb lancement Synaptic depuis le menu

[Pierre L.]

Bonjour,
Merci beaucoup, faut que je vérifie cela !



Le 21/09/2017 à 20:41, lou a écrit :
> Le Mon, 18 Sep 2017 14:07:46 +0200,
> "Pierre L."  a écrit :
>
>> Bonjour,
>>
>> Je pense suite à upgrade Jessie 8 > Stretch 9,
>> dans le menu XFCE, plus moyen de lancer Synaptic.
>>
>> Celui-ci fonctionne depuis un terminal en l'appelant par son nom via
>> root.
>>
>> Tentative infructueuse en le désinstallant, puis réinstallant :
>> l'entrée dans le menu a été recréée, mais toujours même souci.
>>
>> Peut-être auriez-vous une idée pour corriger le tir ?
>> Une autre piste... Je vois qu'il est possible de copier le menu
>> d'origine de XFCE (xfce4-panel 4.12.1), puis d'utiliser sa version
>> modifiée... une magouille pour éventuellement lancer ce Synaptic avec
>> un sudo devant ? (si c'est bien ca le souci!)
>>
>> Merci d'avance pour les tuyaux :)
>>
> Salut,
>
> Dans mon menu la commande pour lancer synaptic c'est : synaptic-pkexec
> j'utilise xfce4 avec debian stretch
> au plaisir :)
>




signature.asc
Description: OpenPGP digital signature

Re: Performance RAID instable

[Pierre L.]

Le 23/09/2017 à 10:40, Pascal Hambourg a écrit :
> Le 23/09/2017 à 08:50, Pierre L. a écrit :
>> Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite
>> carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée
>> être du "fakeraid"...
> A quoi d'autre t'attendais-tu ?
Tu n'as jamais été jeune ?!

>> Possibilité d'installer et d'utiliser le Raid0 qui
>> était dessus, mais il finissait par perdre les perfs jusqu'à
>> l'octet/s :s
>> Souvent la machine freezait de longs moments !
>> Par contre c'était cool avec Windows.
> C'est-à-dire ?
Linux = performances pourries
Windows = OK

>> Ca sentait le "pilote" intégré à Debian,
> C'est-à-dire ?
Pure réflexion de quelqu'un qui n'est (je cite ma précédente réponse)
"absolument pas expert en la matière ;) "
Les échanges sont faits pour s'enrichir en connaissance !

>> J'ai souvenir que pour installer Debian sur du raid, il fallait
>> absolument ajouter dmraid=true dans la ligne de commande du cd
>> d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc
>> géré par l'OS ?
>
> Uniquement pour le fakeRAID. Pas nécessaire pour utiliser le RAID
> logiciel natif de Linux (md).
>
Donc si j'ai bien compris le principe, si on configure notre chipset de
carte mère (un truc de bureau hein) pour faire du fakeraid (ok ?)

Merci pour les réponses agréables et les élagages de citations inutiles.
C'est toujours sympa d'être au contact des humains courtois et...
"humains" !
Bien à vous



signature.asc
Description: OpenPGP digital signature

Re: Performance RAID instable

[Jean-Michel OLTRA]

Bonjour,


Le samedi 23 septembre 2017, Pascal Hambourg a écrit...


> PS : les uns et les autres, ce serait sympa pour les lecteurs d'élaguer les
> citations inutiles des messages auxquels vous répondez.

+1

-- 
jm

Re: Performance RAID instable

[Pascal Hambourg]

Le 23/09/2017 à 11:57, Seb a écrit :


Après j'avoue que ca m'a toujours un peu perdu ces histoires de 
fakeraid...


J'aurais dû préciser quelque chose qui n'était qu'implicite dans mon 
message initial: tout mes tableaux RAID sont en soft, gérés par 'mdadm'. 


C'était clairement indiqué dans le contenu de /proc/mdstat.

PS : les uns et les autres, ce serait sympa pour les lecteurs d'élaguer 
les citations inutiles des messages auxquels vous répondez.

Re: rengister une parole à partir d'un micro

[humbert . olivier . 1]

> cf sujet en employant que les logiciels libres pour une webradio

Salut Bernard.

Audacity fais ça très bien.

En espérant que ça aide,
Olivier

rengister une parole à partir d'un micro

[bernard . schoenacker]

bonjour,

cf sujet en employant que les logiciels libres pour une webradio


slt
bernard

Re: Performance RAID instable

[Seb]

Hello,


Après j'avoue que ca m'a toujours un peu perdu ces histoires de 
fakeraid...


J'aurais dû préciser quelque chose qui n'était qu'implicite dans mon 
message initial: tout mes tableaux RAID sont en soft, gérés par 'mdadm'. 
Je n'utilise aucune carte RAID.


J'ai souvenir que pour installer Debian sur du raid, il fallait 
absolument ajouter dmraid=true dans la ligne de commande du cd 
d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc 
géré par l'OS ?


Je configure le RAID soft avec le partitionneur de Debian (version 
manuelle), lors de l'installation.



Seb.






Le 22/09/2017 à 17:09, Seb a écrit :


Bonjour,



Les astuces que j'ai décrites permettent de maintenir les
performances quand on écrit une grande quantité de données d'un coup
ou bien une grandes quantité d'écritures aléatoirement réparties.
C'est donné au cas où l'hypothèse que j'ai émise est la bonne, car ça
colle très bien à ce que j'observe sur les supports amovibles. Reste
à vérifier si l'architecture dont j'ai parlé est la même sur les SSD.
J'irai jeter un oeil par curiosité.


La comparaison me paraît limitée: sur mon système, je peux copier des
centaines de Mo sans aucun problème à pleine vitesse puis, une heure
plus tard, alors qu'il ne se passe rien de particulier sur la machine,
observer que mes disques SSD sont tout à coup devenus plus lents que
ma connexion
ADSL.


Je serais tenté de tester les disques avec l'outil de diagnostic
constructeur, spécifique aux SSD, si il existe (je suis resté sur les
magnétiques pour le stockage de masse (je veux dire autre que l'OS)).


Je serais fort surpris que le problème soit lié aux disques:

* un reboot résout le problème pour plusieurs heures;

* ces disques fonctionnaient parfaitement juste avant le passage en
Debian 9, et incorrectement juste après;

* j'observe la chose sur deux machines, dont une neuve.


D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans
période d'arrêt ou très courte.


Sous réserve d'avoir des disques SSD d'avance, ce qui n'est pas mon
cas...


Seb.




Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :

Hello,



Les SSD prennent ils en charge TRIM ?


Oui.

~>sudo smartctl -i /dev/sda | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
T0B/EU/
(^F TRIM)

(Je m'étais assuré de ce point quand j'avais acheté les disques.)

Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
SSD
a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
de
cette machine de Debian 8 à Debian 9.


L'effondrement de performance ne serait-il consécutif à une

écriture en

peu de temps de quelques centaines de Mo, ou bien de nombreuses
écritures très petites (< 32Ko environ) ?


Il m'arrive couramment de déplacer ou copier des centaines de Mo en
peu de
temps, mais ces moments ne coïncident pas avec la perte de
performance.
Des crontabs font des tas de jobs pour moi en sous-main, mais elles
les
faisaient aussi sous Debian 8.


Je n'utilise pas JFS, mais a t il été optimisé si possible pour
respecter les contraintes techniques de ce genre de support ?


J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
disques
seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème
comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
le
cas où quelqu'un aurait connaissance d'un changement dans la prise
en
charge de ce filesystem dans Debian, mais autrement, en lui-même, il
m'a
toujours semblé très solide.


Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout

cas

sur une clé USB bas de gamme ça fait des miracles.


Merci pour ces astuces d'optimisation. Mon problème est toutefois
inverse:
empêcher la chute soudaine et inexpliquée des performances, plutôt
que
tirer autant de débit que possible d'un système fonctionnant
correctement
à la base :-)


Seb.



J'utilise Debian depuis une quinzaine d'années, sans problème de
RAID
jusqu'à présent. Mon souci actuel est que deux machines qui font
chacune
du RAID1 sur deux disques SSD ont des performances disque qui se
dégradent
brutalement, sans raison apparente (rien trouvé dans syslog,
notamment).
La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La
différence est si nette qu'une mesure grossière avec 'dd' suffit à
la
mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=1).

* La machine à la maison en a été la première victime, dès son
installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée

en

janvier aussi). Le PC était neuf, ses disques aussi. (C'est

toujours

la
version stable de Debian que j'utilise.)

* La machine de bureau, qui donnait entière satisfaction depuis
plusieurs
années, a commencé à montrer les mêmes symptômes juste après son
passage de
Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce
n'était 

Re: Performance RAID instable

[Pascal Hambourg]

Le 23/09/2017 à 08:50, Pierre L. a écrit :

Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite
carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée
être du "fakeraid"...


A quoi d'autre t'attendais-tu ?
Seules les grosses cartes RAID chères font du vrai RAID matériel.
Donc on oublie le fakeRAID et on utilise le RAID logiciel natif de 
Linux, bien plus stable et fiable que n'importe quel fakeRAID dépendant 
du matériel dont le seul avantage est la compatibilité avec Windows.



Possibilité d'installer et d'utiliser le Raid0 qui
était dessus, mais il finissait par perdre les perfs jusqu'à l'octet/s :s
Souvent la machine freezait de longs moments !
Par contre c'était cool avec Windows.


C'est-à-dire ?


Ca sentait le "pilote" intégré à Debian,


C'est-à-dire ?


selon mon avis par déduction absolument pas expert en la matière ;)
Peut-être suis-je complètement à coté de la plaque !!!


Etant donné que je ne vois absolument pas ce que tu veux dire, je suis 
bien incapable d'émettre un avis sur la question.



J'ai souvenir que pour installer Debian sur du raid, il fallait
absolument ajouter dmraid=true dans la ligne de commande du cd
d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc
géré par l'OS ?


Uniquement pour le fakeRAID. Pas nécessaire pour utiliser le RAID 
logiciel natif de Linux (md).

Re: Performance RAID instable

[Pierre L.]

Hello,
Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite
carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée
être du "fakeraid"... Possibilité d'installer et d'utiliser le Raid0 qui
était dessus, mais il finissait par perdre les perfs jusqu'à l'octet/s :s
Souvent la machine freezait de longs moments !
Par contre c'était cool avec Windows. Ca sentait le "pilote" intégré à
Debian, selon mon avis par déduction absolument pas expert en la matière ;)
Peut-être suis-je complètement à coté de la plaque !!!

Après j'avoue que ca m'a toujours un peu perdu ces histoires de fakeraid...
J'ai souvenir que pour installer Debian sur du raid, il fallait
absolument ajouter dmraid=true dans la ligne de commande du cd
d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc
géré par l'OS ?



Le 22/09/2017 à 17:09, Seb a écrit :
>
> Bonjour,
>
>
>> Les astuces que j'ai décrites permettent de maintenir les
>> performances quand on écrit une grande quantité de données d'un coup
>> ou bien une grandes quantité d'écritures aléatoirement réparties.
>> C'est donné au cas où l'hypothèse que j'ai émise est la bonne, car ça
>> colle très bien à ce que j'observe sur les supports amovibles. Reste
>> à vérifier si l'architecture dont j'ai parlé est la même sur les SSD.
>> J'irai jeter un oeil par curiosité.
>
> La comparaison me paraît limitée: sur mon système, je peux copier des
> centaines de Mo sans aucun problème à pleine vitesse puis, une heure
> plus tard, alors qu'il ne se passe rien de particulier sur la machine,
> observer que mes disques SSD sont tout à coup devenus plus lents que
> ma connexion
> ADSL.
>
>> Je serais tenté de tester les disques avec l'outil de diagnostic
>> constructeur, spécifique aux SSD, si il existe (je suis resté sur les
>> magnétiques pour le stockage de masse (je veux dire autre que l'OS)).
>
> Je serais fort surpris que le problème soit lié aux disques:
>
> * un reboot résout le problème pour plusieurs heures;
>
> * ces disques fonctionnaient parfaitement juste avant le passage en
> Debian 9, et incorrectement juste après;
>
> * j'observe la chose sur deux machines, dont une neuve.
>
>> D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans
>> période d'arrêt ou très courte.
>
> Sous réserve d'avoir des disques SSD d'avance, ce qui n'est pas mon
> cas...
>
>
> Seb.
>
>
>>
>> Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :
>>> Hello,
>>>
>>>
 Les SSD prennent ils en charge TRIM ?
>>>
>>> Oui.
>>>
>>> ~>sudo smartctl -i /dev/sda | grep ^"Device Model"
>>> Device Model: Samsung SSD 850 EVO 1TB
>>>
>>> ~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
>>> Device Model: Samsung SSD 850 EVO 1TB
>>>
>>> http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
>>> T0B/EU/
>>> (^F TRIM)
>>>
>>> (Je m'étais assuré de ce point quand j'avais acheté les disques.)
>>>
>>> Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
>>> SSD
>>> a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
>>> de
>>> cette machine de Debian 8 à Debian 9.
>>>
 L'effondrement de performance ne serait-il consécutif à une
>>> écriture en
 peu de temps de quelques centaines de Mo, ou bien de nombreuses
 écritures très petites (< 32Ko environ) ?
>>>
>>> Il m'arrive couramment de déplacer ou copier des centaines de Mo en
>>> peu de
>>> temps, mais ces moments ne coïncident pas avec la perte de
>>> performance.
>>> Des crontabs font des tas de jobs pour moi en sous-main, mais elles
>>> les
>>> faisaient aussi sous Debian 8.
>>>
 Je n'utilise pas JFS, mais a t il été optimisé si possible pour
 respecter les contraintes techniques de ce genre de support ?
>>>
>>> J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
>>> disques
>>> seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème
>>> comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
>>> le
>>> cas où quelqu'un aurait connaissance d'un changement dans la prise
>>> en
>>> charge de ce filesystem dans Debian, mais autrement, en lui-même, il
>>> m'a
>>> toujours semblé très solide.
>>>
 Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout
>>> cas
 sur une clé USB bas de gamme ça fait des miracles.
>>>
>>> Merci pour ces astuces d'optimisation. Mon problème est toutefois
>>> inverse:
>>> empêcher la chute soudaine et inexpliquée des performances, plutôt
>>> que
>>> tirer autant de débit que possible d'un système fonctionnant
>>> correctement
>>> à la base :-)
>>>
>>>
>>> Seb.
>>>
>>>
> J'utilise Debian depuis une quinzaine d'années, sans problème de
> RAID
> jusqu'à présent. Mon souci actuel est que deux machines qui font
> chacune
> du RAID1 sur deux disques SSD ont des performances disque qui se
> dégradent
> brutalement, sans raison apparente (rien trouvé dans syslog,
> notamment).
> La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5