![[ICO]](/icons/blank.gif){kind=icon}
![[PARENTDIR]](/icons/back.gif){kind=icon}
Cet article explique comment programmer un réveil matin avec les outils Unix classiques et MOCP (Music On Console Player). Les composants nécessaires sont les suivants :
La première chose à faire est d'installer MOCP sur votre machine. Pour ce faire il suffit d'installer soit le paquet moc, soit le paquet mocp, cela dépend des distributions. Par exemple pour Debian, ce sera :
apt install moc
Si besoin, voue pouvez vous référer au site du projet pour plus d'informations sur les modes d'installation disponibles. Le logiciel fonctionne en terminal, en mode semi graphique (ncurses) ou en ligne de commande, au choix. Je vous laisse tester le mode semi graphique et vous faire votre idée sur la question. Ce qui vous intéresse, ce sont les commandes disponibles pour contrôler le lecteur. En effet, ce sont ces commandes qui seront utilisées pour démarrer la musique.
Remarque : sur Debian, le paquet moc fournit un certain nombre de décodeurs pour lire des musiques, mais beaucoup de décodeurs d'origine propriétaire sont fournis par le projet ffmpeg et nécessitent d'être installés à part. Le paquet source moc fournit le paquet binaire moc-ffmpeg-plugin pour faire la liaison, mais il n'est pas installé par défaut avec moc.
La commande mocp fournit quelques primitives pour gérer les listes de lecture. Bien que l'interface en ncurses se prête mieux à l'usage, ça peut être utile de savoir comment gérer la liste de lecture via la ligne de commande. Les primitives sont les suivantes :
En parlant des listes de lecture, la liste courante du serveur est stockée dans le fichier playlist.m3u du répertoire de configuration de moc, par défaut dans ~/.moc. Ce fichier est effacé après exécution de mocp -c. En temps normal, la liste de lecture courante est stocké en mémoire, dans le serveur, et n'est sauvegardée qu'à la fermeture propre du client. Si vous avez l'intention de dédier un liste de lecture au réveil, qui soit indépendante de la liste de lecture du jour, ce sont ces fichiers qu'il faudra gérer.
MOCP fonctionne sur le modèle client/serveur. Lorsque vous démarrez le lecteur en tapant mocp en ligne de commande, le processus va automatiquement se dupliquer. Le serveur va vous jouer la musique et le client (à savoir l'interface en ncurses va vous permettre de contrôler la musique :
Les commandes qui vont vous intéresser, une fois que vous aurez choisi quelles musiques vont vous réveiller sont :
L'idée est donc de déclencher la musique à l'heure à laquelle vous devez vous réveiller (ou un peu plus tôt si vous voulez profiter de la musique :), disons à 6:30. On édite donc le fichier crontab. Le mieux est encore de procèder en passant par la commande du même nom :
crontab -e
Cette commande ouvrira automatiquement le bon fichier de configuration avec votre éditeur de texte favori (variable d'environnement EDITOR). Le fichier est une liste de commandes en Bourne Shell, précédées de symboles permettant de régler la date et la fréquence d'exécution des commandes. Un crontab s'organise ligne après ligne. Sur une ligne les 5 premiers groupes de symboles permettent de procéder aux réglages. Dans l'ordre, nous avons donc :
Une syntaxe propre au crontab permet de gérer les dates d'exécution des commandes. Pour une liste exhaustive des détails de configuration, je ne peux que vous encourager à consulter la page de manuel :
man 5 crontab
Étant massivement présente dans les exemples, l'étoile * permet d'effectuer une opération « à chaque changement de minute, d'heure, de jour, de mois ou de jour de la semaine ». Pour mettre le réveil tous les jours à 6:30, la ligne correspondante est :
30 6 * * * mocp -S; mocp -p
Le 30 est pour la trentième minute de 6 heures, tous les jours, tous les mois, et tous les jours de la semaine, pour les trois étoiles respectivement. Le reste est une séquence de commandes interprétées par le Bourne Shell du système.
Attention : l'environnement d'exécution des tâches cron est très restreint par rapport à l'environnement d'exécution lors d'une utilisation interactive du système. Il peut être nécessaire d'ajuster l'environnement pour permettre aux tâches cron d'accéder à la pile logicielle audio. Par exemple, j'ai remarqué en Debian 13 que l'environnement XDG_RUNTIME_DIR est manquant dans l'environnement de cron, et il est nécessaire pour que le son puisse atteindre les haut-parleurs. Me concernant, avec mon utilisateur défini avec l'installeur Debian, j'ai :
$ echo "$XDG_RUNTIME_DIR" /run/user/1000où je soupçonne fortement le 1000 d'être mon identifiant utilisateur. Par conséquent un réglage générique de la variable d'environnement depuis le crontab pourrait ressembler à :
30 6 * * * XDG_RUNTIME_DIR="/run/user/$(id -u)"; export XDG_RUNTIME_DIR; mocp -S; mocp -pJ'admet que ça commence à charger la ligne de script du crontab. Pour contrer l'inflation de la longueur de la ligne de commande, une bonne approche est de tout mettre dans un script, puis d'appeler ce script depuis le crontab. Là encore, attention à l'environnement : le PATH n'est pas forcément le même que dans un environnement utilisateur classique, et il sera probablement nécessaire de spécifier le chemin complet vers le script afin de pouvoir le trouver pour l'exécuter.
J'imagine que vous ne souhaitez pas être réveillé par votre machine les jours où il n'est pas nécessaire de se réveiller tôt. Alors là, il y a deux solutions : soit vous éteignez votre machine le weekend (et vous êtes à la merci des oublis d'arrêt ou d'allumage), soit on se débrouille avec le crontab. Il est possible de spécifier des plages pour permettre d'effectuer des opérations seulement dans certains cas. Pour notre réveil, c'est simple, on souhaite l'activer sauf les samedis et dimanche. On peut donc spécfier les jours actifs avec des virgules, ou bien avec une plage ; il est même possible de mélanger les deux notations :
# Avec une plage 30 6 * * 1-5 mocp -S; mocp -p # Avec des virgules 30 6 * * 1,2,3,4,5 mocp -S; mocp -p
Le dernier raffinement que je propose est pour ceux qui auraient tendance à oublier d'arrêter la musique avant de s'endormir :
59 23 * * 0-4 mocp -x # Avant minuit # 1 0 * * 1-5 mocp -x # Après minuit
La commande va avoir pour effet de stopper automatiquement la musique (si vous utilisez mocp à ce moment là bien sûr ;-). M'étant fait avoir une fois les histoires de dates, je propose deux horaires différent pour arrêter la musique. La différence entre les deux est que la plage de jours de la semaine n'est pas la même.
La dernière amélioration qu'il est possible d'apporter, en particulier si vous dormez avec la musique allumée, serait peut-être d'avoir du son un peu plus fort pour vous réveiller. Ici, on va utiliser Alsa pour régler le son en ligne de commande. Alsa permet de piloter le son sous Linux. En particulier, on va s'intéresser à alsamixer et amixer. Le premier, comme mocp, est une interface en ncurses pour régler le volume. On peut s'en servir pour évaluer le niveau sonore que l'on souhaite obtenir. Le second permet de régler le son en ligne de commande. Utilisez Alsamixer pour régler le son et voir quels paramêtres influent sur le niveau sonore dans les réglages. Ça peut-être Master, PCM, ou n'importe quoi d'autre. Le mieux est de faire des essais et de se servir de ce qui a prouvé être efficace. Me concernant, je règle le son un peu au cas par cas en fonction des haut parleurs disponibles : il faut que ce soit assez fort pour se réveiller, mais pas trop fort pour éviter de réveiller tout le voisinage dans la foulée. Prenons par exemple 50% sur le réglage Master, pour effectuer le réglage avec amixer, il faut choisir la carte son et le paramètre identifié précédemment. Pour la carte son, dans la plupart des cas, il n'y en a qu'une, la numéro 0. Si ça ne marche pas, essayez les autres numéros (arrivé à 9 posez vous tout de même des questions). Le code ci-dessous me permet de régler le son au maximum sur ma carte :
amixer -c 0 sset Master '50%'
Comme vous l'aurez deviné : -c permet d'indiquer la carte à sélectionner, et sset le paramètre et son niveau sonore.
Le crontab a donc l'allure suivante :
0 1 * * 1-5 mocp -x 0 6 * * 1-5 amixer -c 0 sset Master 50\%; mocp -S; mocp --play
Remarque : Alsa est un composant du noyau d'assez bas niveau, mais les interfaces utilisateurs contemporaine sont plutôt pilotées avec les piles logicielles pulseaudio, ou plus moderne : pipewire. Le fait est que le réglage du volume est surprenamment plus compliqué avec ces outils, parce qu'il faut d'abord identifier comment le programme jouant de la musique est raccordé sur l'infrastructure de son. J'ai pu passer pas mal de temps à essayer de comprendre comment automatiser ces composants dans un cas d'usage de réveil matin avant de jeter l'éponge ; de toutes façon, ces composants fournissent une couche de compatibilité pour les clients sonores qui sont restés bloqués à l'âge de Alsa.
Note : D'après la coloration syntaxique de vim pour le crontab, le symbole "%" a un usage particulier. Pour inhiber son effet, il est préfixé du "\".
Note : Importante celle-là de note, les redirections de fichiers ont de bonnes chances de ne pas marcher dans de nombreux cas car le cron n'aura pas forcément les droits en lecture ou écriture dessus. Ça peut être le cas par exemple pour des redirections vers /dev/null.
Vous venez d'ajouter une fonctionnalité de réveil matin à votre machine et au passage, si ce n'était déjà connu, vous avez appris les bases de la configuration du dæmon cron. Bien joué !
| Name | Last modified | Size |
|---|---|---|---|
| Parent Directory | - |
La publication originale sur dismorphia.info/~tokamak/ date du 12 novembre 2012, mais n'est plus disponible en tant que telle aujourd'hui. Il était incomplet et les commandes relatives à ALSA ont eu une légère tendance à fonctionner avec une géométrie variable au fil du temps.
La section sur les listes de lectures a été finalement rédigée le 7 décembre 2018, soit six ans après le début de la rédaction de l'article.
Un addendum a été rajouté le 23 juillet 2025 au chapitre sur la rédaction du crontab, notamment au sujet de l'environnement spécifique des tâches cron, et du fait qu'à partir de Debian 13 trixie, il faut désormais un accès au XDG_RUNTIME_DIR afin que le logiciel de musique puisse atteindre la pile logicielle de son, soit plus de douze ans après la rédaction de l'article original. L'installation est par ailleurs accompagnée d'une remarque sur l'existence du paquet moc-ffmpeg-plugin pour les musiques nécessitant un décodeur d'origine propriétaire, par exemple pour lire les fichiers AAC.