Ça me permet de suivre l'avancement du script en ayant l'oeil ailleurs.
Tout ça marchait très bien en 2.4.x, mais depuis que j'ai été obligé de
passer à ALSA avec le 2.6.7, j'ai un problème.
1) Le son est nul, il ressemble à un soufle très bruyant dans les HP.
2) Si la machine est en train de jouer des mp3, alors le script
contenant la ligne ci-dessus s'arrête et attend que je termine la
lecture des mp3 pour jouer les .wav et de poursuivre son exécution, au
lieu d'envoyer un bip dans le speaker du PC.
3) Les mp3 sont lu correctement.
Voici la liste des options de compil du kernel concernant le son:
# CONFIG_CHR_DEV_OSST is not set
CONFIG_SOUND_OSS=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_RAWMIDI=y
# CONFIG_SND_SEQUENCER is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
# CONFIG_SND_RTCTIMER is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_MPU401_UART=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_AC97_CODEC=y
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y Car le son est géré par une puce SiS 7012
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
Que dois-je corriger dans la config du noyau pour retrouver le même
comportement qu'en 2.4.27 ?
J'ajoute que j'ai cherché à comprendre la doc d'ALSA... simplement
imbitable :/
Config: Debian Sarge 2.6.7 / AMD Athlon
Merci de votre aide
--
> Subject: pb fvwm95-2 comment l'installer le compiler???
> Merci d'avance
je te conseille d'être un peu plus précis dans l'exposé de ton pb...
-+- EJ in guide du linuxien pervers :"Les modéros sont sympas !" -+-
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
Nicolas George
Hugolino wrote in message :
cat Appear.wav > /dev/dsp || echo -e "a" > /dev/tty0
1) Le son est nul, il ressemble à un soufle très bruyant dans les HP.
C'est que la fréquence d'échantillonage ou le format d'échantillons par défaut a changé. Solution : utiliser un player un peu plus évolué que cat. Par exemple :
sox Appear.wav -t ossdsp /dev/dsp
2) Si la machine est en train de jouer des mp3, alors le script contenant la ligne ci-dessus s'arrête et attend que je termine la lecture des mp3 pour jouer les .wav et de poursuivre son exécution, au lieu d'envoyer un bip dans le speaker du PC.
Quand le DSP est occupé, l'ouverture de /dev/dsp bloque jusqu'à ce qu'il se libère. Il est possible que l'ancien comportement ait été d'échouer avec EBUSY. Quoi qu'il en soit, il est possible de revenir au comportement initial en ouvrant en non-bloquant. Je ne connais pas d'outil shell qui fasse ça, mais redirfd, d'execline, sait faire <URL: http://www.skarnet.org/software/execline/redirfd.html > :
Hugolino wrote in message
<slrncgfr02.10m.hugolino@Deborah.RocknRoll.org>:
cat Appear.wav > /dev/dsp || echo -e "a" > /dev/tty0
1) Le son est nul, il ressemble à un soufle très bruyant dans les HP.
C'est que la fréquence d'échantillonage ou le format d'échantillons par
défaut a changé. Solution : utiliser un player un peu plus évolué que
cat. Par exemple :
sox Appear.wav -t ossdsp /dev/dsp
2) Si la machine est en train de jouer des mp3, alors le script
contenant la ligne ci-dessus s'arrête et attend que je termine la
lecture des mp3 pour jouer les .wav et de poursuivre son exécution, au
lieu d'envoyer un bip dans le speaker du PC.
Quand le DSP est occupé, l'ouverture de /dev/dsp bloque jusqu'à ce qu'il
se libère. Il est possible que l'ancien comportement ait été d'échouer
avec EBUSY. Quoi qu'il en soit, il est possible de revenir au
comportement initial en ouvrant en non-bloquant. Je ne connais pas
d'outil shell qui fasse ça, mais redirfd, d'execline, sait faire <URL:
http://www.skarnet.org/software/execline/redirfd.html > :
cat Appear.wav > /dev/dsp || echo -e "a" > /dev/tty0
1) Le son est nul, il ressemble à un soufle très bruyant dans les HP.
C'est que la fréquence d'échantillonage ou le format d'échantillons par défaut a changé. Solution : utiliser un player un peu plus évolué que cat. Par exemple :
sox Appear.wav -t ossdsp /dev/dsp
2) Si la machine est en train de jouer des mp3, alors le script contenant la ligne ci-dessus s'arrête et attend que je termine la lecture des mp3 pour jouer les .wav et de poursuivre son exécution, au lieu d'envoyer un bip dans le speaker du PC.
Quand le DSP est occupé, l'ouverture de /dev/dsp bloque jusqu'à ce qu'il se libère. Il est possible que l'ancien comportement ait été d'échouer avec EBUSY. Quoi qu'il en soit, il est possible de revenir au comportement initial en ouvrant en non-bloquant. Je ne connais pas d'outil shell qui fasse ça, mais redirfd, d'execline, sait faire <URL: http://www.skarnet.org/software/execline/redirfd.html > :
Le Wed, 28 Jul 2004 18:21:28 +0000 (UTC), Nicolas George a écrit:
Hugolino wrote in message :
cat Appear.wav > /dev/dsp || echo -e "a" > /dev/tty0
1) Le son est nul, il ressemble à un soufle très bruyant dans les HP.
C'est que la fréquence d'échantillonage ou le format d'échantillons par défaut a changé.
Changé par qui/quoi ? N'est-il pas possible de revenir à la situation antérieure (celle des 2.4.X) ?
Solution : utiliser un player un peu plus évolué que cat. Par exemple :
sox Appear.wav -t ossdsp /dev/dsp
OK, ça marche, mais qui m'assure que ça marchera pour les 2.8.X ou les 3.0.X ? C'est que je m'imagine mal ré-écrire tous mes script à chaque MÀJ du noyau...
2) Si la machine est en train de jouer des mp3, alors le script contenant la ligne ci-dessus s'arrête et attend que je termine la lecture des mp3 pour jouer les .wav et de poursuivre son exécution, au lieu d'envoyer un bip dans le speaker du PC.
Quand le DSP est occupé, l'ouverture de /dev/dsp bloque jusqu'à ce qu'il se libère. Il est possible que l'ancien comportement ait été d'échouer avec EBUSY.
Ce qui me paraît tout à fait logique.
Quoi qu'il en soit, il est possible de revenir au comportement initial en ouvrant en non-bloquant. Je ne connais pas d'outil shell qui fasse ça, mais redirfd, d'execline, sait faire <URL: http://www.skarnet.org/software/execline/redirfd.html > :
Bidouille, bidouille, bidouille. Tout ça deviendra obsolète avec le 3.2.13...
J'ai résolu mon problème à coup de 'echo -e "e[10;200]e[11;500]a">/dev/tty0'
PC-Speaker vaincra !
Merci de ton aide, c'est archivé.
-- Hugo NPN (i --> ee)
Ne pas installer Windows, c'est déjà s'y connaître...
Le Wed, 28 Jul 2004 18:21:28 +0000 (UTC), Nicolas George a écrit:
Hugolino wrote in message
<slrncgfr02.10m.hugolino@Deborah.RocknRoll.org>:
cat Appear.wav > /dev/dsp || echo -e "a" > /dev/tty0
1) Le son est nul, il ressemble à un soufle très bruyant dans les HP.
C'est que la fréquence d'échantillonage ou le format d'échantillons par
défaut a changé.
Changé par qui/quoi ?
N'est-il pas possible de revenir à la situation antérieure (celle des
2.4.X) ?
Solution : utiliser un player un peu plus évolué que cat. Par
exemple :
sox Appear.wav -t ossdsp /dev/dsp
OK, ça marche, mais qui m'assure que ça marchera pour les 2.8.X ou les
3.0.X ?
C'est que je m'imagine mal ré-écrire tous mes script à chaque MÀJ du
noyau...
2) Si la machine est en train de jouer des mp3, alors le script
contenant la ligne ci-dessus s'arrête et attend que je termine la
lecture des mp3 pour jouer les .wav et de poursuivre son exécution, au
lieu d'envoyer un bip dans le speaker du PC.
Quand le DSP est occupé, l'ouverture de /dev/dsp bloque jusqu'à ce qu'il
se libère. Il est possible que l'ancien comportement ait été d'échouer
avec EBUSY.
Ce qui me paraît tout à fait logique.
Quoi qu'il en soit, il est possible de revenir au comportement
initial en ouvrant en non-bloquant. Je ne connais pas d'outil shell
qui fasse ça, mais redirfd, d'execline, sait faire <URL:
http://www.skarnet.org/software/execline/redirfd.html > :
Le Wed, 28 Jul 2004 18:21:28 +0000 (UTC), Nicolas George a écrit:
Hugolino wrote in message :
cat Appear.wav > /dev/dsp || echo -e "a" > /dev/tty0
1) Le son est nul, il ressemble à un soufle très bruyant dans les HP.
C'est que la fréquence d'échantillonage ou le format d'échantillons par défaut a changé.
Changé par qui/quoi ? N'est-il pas possible de revenir à la situation antérieure (celle des 2.4.X) ?
Solution : utiliser un player un peu plus évolué que cat. Par exemple :
sox Appear.wav -t ossdsp /dev/dsp
OK, ça marche, mais qui m'assure que ça marchera pour les 2.8.X ou les 3.0.X ? C'est que je m'imagine mal ré-écrire tous mes script à chaque MÀJ du noyau...
2) Si la machine est en train de jouer des mp3, alors le script contenant la ligne ci-dessus s'arrête et attend que je termine la lecture des mp3 pour jouer les .wav et de poursuivre son exécution, au lieu d'envoyer un bip dans le speaker du PC.
Quand le DSP est occupé, l'ouverture de /dev/dsp bloque jusqu'à ce qu'il se libère. Il est possible que l'ancien comportement ait été d'échouer avec EBUSY.
Ce qui me paraît tout à fait logique.
Quoi qu'il en soit, il est possible de revenir au comportement initial en ouvrant en non-bloquant. Je ne connais pas d'outil shell qui fasse ça, mais redirfd, d'execline, sait faire <URL: http://www.skarnet.org/software/execline/redirfd.html > :
Bidouille, bidouille, bidouille. Tout ça deviendra obsolète avec le 3.2.13...
J'ai résolu mon problème à coup de 'echo -e "e[10;200]e[11;500]a">/dev/tty0'
PC-Speaker vaincra !
Merci de ton aide, c'est archivé.
-- Hugo NPN (i --> ee)
Ne pas installer Windows, c'est déjà s'y connaître...
Nicolas George
Hugolino wrote in message :
N'est-il pas possible de revenir à la situation antérieure (celle des 2.4.X) ?
Il faut faire des ioctl pour régler les paramètres. Normalement, il faut systématiquement le faire, mais il y a des valeurs par défaut, et si le wav tombe par hasard dessus, c'est dispensable. À noter quand même que la méthode « cat foo.wav > /dev/dsp » fait un gros craquement à cause des 44 octets en début de fichier.
OK, ça marche, mais qui m'assure que ça marchera pour les 2.8.X ou les 3.0.X ?
Ça marchera tant que l'API OSS sera maintenue, éventuellement en émulation par ALSA. OSS est obsolète, mais l'API sera probablement maintenue pendant pas mal de temps.
C'est que je m'imagine mal ré-écrire tous mes script à chaque MÀJ du noyau...
La méthode la plus fiable serait d'avoir un script mybeep qui fasse le bip comme il faut, comme ça il n'y a que celui-là à changer.
J'ai résolu mon problème à coup de 'echo -e "e[10;200]e[11;500]a">/dev/tty0'
Modification conseillée :
echo -ne '...' > /dev/tty0
-n pour éviter d'afficher un retour à la ligne pour rien, ' à la place de " parce que la signification des est mieux définie dans ce cas.
Hugolino wrote in message
<slrncglajb.9ee.hugolino@Deborah.RocknRoll.org>:
N'est-il pas possible de revenir à la situation antérieure (celle des
2.4.X) ?
Il faut faire des ioctl pour régler les paramètres. Normalement, il faut
systématiquement le faire, mais il y a des valeurs par défaut, et si le
wav tombe par hasard dessus, c'est dispensable. À noter quand même que
la méthode « cat foo.wav > /dev/dsp » fait un gros craquement à cause
des 44 octets en début de fichier.
OK, ça marche, mais qui m'assure que ça marchera pour les 2.8.X ou les
3.0.X ?
Ça marchera tant que l'API OSS sera maintenue, éventuellement en
émulation par ALSA. OSS est obsolète, mais l'API sera probablement
maintenue pendant pas mal de temps.
C'est que je m'imagine mal ré-écrire tous mes script à chaque MÀJ du
noyau...
La méthode la plus fiable serait d'avoir un script mybeep qui fasse le
bip comme il faut, comme ça il n'y a que celui-là à changer.
J'ai résolu mon problème à coup de 'echo -e "e[10;200]e[11;500]a">/dev/tty0'
Modification conseillée :
echo -ne '...' > /dev/tty0
-n pour éviter d'afficher un retour à la ligne pour rien, ' à la place
de " parce que la signification des est mieux définie dans ce cas.
N'est-il pas possible de revenir à la situation antérieure (celle des 2.4.X) ?
Il faut faire des ioctl pour régler les paramètres. Normalement, il faut systématiquement le faire, mais il y a des valeurs par défaut, et si le wav tombe par hasard dessus, c'est dispensable. À noter quand même que la méthode « cat foo.wav > /dev/dsp » fait un gros craquement à cause des 44 octets en début de fichier.
OK, ça marche, mais qui m'assure que ça marchera pour les 2.8.X ou les 3.0.X ?
Ça marchera tant que l'API OSS sera maintenue, éventuellement en émulation par ALSA. OSS est obsolète, mais l'API sera probablement maintenue pendant pas mal de temps.
C'est que je m'imagine mal ré-écrire tous mes script à chaque MÀJ du noyau...
La méthode la plus fiable serait d'avoir un script mybeep qui fasse le bip comme il faut, comme ça il n'y a que celui-là à changer.
J'ai résolu mon problème à coup de 'echo -e "e[10;200]e[11;500]a">/dev/tty0'
Modification conseillée :
echo -ne '...' > /dev/tty0
-n pour éviter d'afficher un retour à la ligne pour rien, ' à la place de " parce que la signification des est mieux définie dans ce cas.
