Cette espace vous permet de voir toutes les Voir les messages réalisées par ce membre. Vous ne pouvez voir que les Voir les messages réalisées dans les espaces auxquels vous avez accès.
Au final, j'ai du mal à comprendre pourquoi https://software.opensuse.org propose des fichiers .ymp pour Leap 16.0 alors qu'il n'y a plus Yast pour les installer. Peut-être la force de l'habitude ...
Bonjour, Effectivement. Avec "expert Download", on aboutit à différentes possibilités. - Soit les commandes zypper pour installer le paquetage - Soit "récupérer les paquets binaires directement" et obtenir le .rpm J'ai mis le rpm dans un dossier séparé que j'ai ajouté à Myrlyn Mais j'ai trouvé plus simple de faire clic droit et "Ouvrir avec Discover"
Bonjour, Je viens d'installer Leap16 dans une machine virtuelle pour le découvrir. Habitué à Opensuse et Leap depuis des années, je suis familier de Yast. Maintenant plus de Yast, en particulier pour installer des logiciels. Pourquoi pas ? Myrlyn est pas mal du tout, Discovery aussi. J'ai voulu ajouter avidemux. Il existe à https://software.opensuse.org/package/avidemux?search_term=avidemux On voit un paquetage pour la Leap16.0 Il y a un paquet communautaire avec install en 1 clic. Ce clic charge un fichier avidemux.ymp Problème : les .ymp sont des fichiers Yast Méta Package. Mais Yast n'est plus là. Discover ne sait pas ouvrir ce fichier. Myrlyn non plus.
Comment installe-t-on un paquetage avec un fichier.ymp dans Leap16 ? J'ai raté un truc ?
Le problème a disparu. Je suppose qu'il a été résolu par une mise à jour régulière des paquetages, mais je ne saurais pas dire de quel paquetage il s'agit. Je classe le sujet résolu sans pouvoir vous en dire plus.
@Yoman OK pour le blog. Pour pipewire, je vois que c'est une interface graphique ressemblant énormément à Jack. Ce Jack est une surcouche de ALSA qui permet de connecter des entrées et des sorties audio. Avec des câbles virtuels. Jack a besoin d'un serveur qu'il faut paramétrer, avec même des notions de temps réel. Et j'ai pas mal galéré pour identifier la numérotation des entrées/sorties des carte son. Cette numérotation étant différente de celle d'ALSA.
Sur pipewire, pour le peu que j'ai vu, on a la notion des câbles virtuels, mais sans l'inconvénient du paramétrage d'un serveur. Bonne expérimentation ! Wallace
La carte Hauppauge HVR5525 PCI-express est dotée de plusieurs tuners : - un tuner radio - un tuner satellite DVB-S2 Montage Technology - un tuner Silicon Labs Si2168 pour une entrée cable et DVB-T2
Normalement, il est correctement reconnu par Kaffeine, et permet la réception de la TNT.
Je dis bien "normalement" car dans la majorité des cas, le lancement de Kaffeine provoque les évènements suivants visibles par dmmesg :
[ 5533.992691] m88ds3103 3-0069: found a 'Montage Technology M88RS6000' in cold state [ 5533.995390] m88ds3103 3-0069: downloading firmware from file 'dvb-demod-m88rs6000.fw' [ 5534.928437] m88ds3103 3-0069: found a 'Montage Technology M88RS6000' in warm state [ 5534.928439] m88ds3103 3-0069: firmware version: 4.1 [ 5535.090622] si2168 3-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 5535.718422] si2168 3-0064: firmware version: B 4.0.11 [ 5535.724910] si2157 4-0060: found a 'Silicon Labs Si2157-A30 ROM 0x50' [ 5535.724957] si2157 4-0060: Using ROM firmware. [ 5535.773757] si2157 4-0060: firmware version: 3.0.5
Dans ce cas, tout fonctionne bien : la TNT est utilisable.
Récemment, peut-être après une mise à jour de la Leap 15.6, la TNT ne fonctionne plus au démarrage de Kaffeine. Les canaux préréglés ne détectent plus de signal. Et dmesg donne : [ 5533.992691] m88ds3103 3-0069: found a 'Montage Technology M88RS6000' in cold state [ 5533.995390] m88ds3103 3-0069: downloading firmware from file 'dvb-demod-m88rs6000.fw' [ 5534.928437] m88ds3103 3-0069: found a 'Montage Technology M88RS6000' in warm state [ 5534.928439] m88ds3103 3-0069: firmware version: 4.1 [ 5535.090622] si2168 3-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 5535.718422] si2168 3-0064: firmware version: B 4.0.11
C'est-à-dire que les 3 dernières lignes "normales" ont disparu : pas de Silicon Labs Si2157-A30 Je suis obligé d'éteindre le PC, et le redémarrer, pour que le Silicon Labs veuille bien s'activer. La commande re-démarrer ne suffit pas.
Quelqu'un aurait une idée pour forcer cette activation sans redémarrer le PC ?
J'ai continué sur mon idée du openSUSE-Leap-15.6-DVD-x86_64-Media.iso et j'ai regardé quels étaient les paquets mis à jour qui pouvaient amener à la panne. J'ai trouvé le coupable : gstreamer. Mais c'est très très bizarre.
Solution: Sur un système où apparaît le phénomène, la solution est de descendre la version de gstreamer-plugins-good pour l'amener à 1.24.0-150600.1.1 Sur la première machine où j'ai le défaut, elle est à 1.24.0-150600.3.3.1 Youpie ! Plus d'erreur ! Le son sort correctement !
L'histoire aurait pu s'arrêter là. Mais j'ai voulu tenter de remettre la version 1.24.0-150600.3.3.1 qui foirait. Résultat : ça marche toujours ! Le son continue à sortir !
Peut-être que l'ordre d'installation des paquetages entre eux a un effet ? Je laisse le soin aux spécialistes et passionnés de trouver l'explication technique.
Pour ma part je vous propose cette solution de dépannage: passer provisoirement gstreamer-plugins-good en version 1.24.0-150600.1.1
Merci à Yoman. Grace à toi, j'ai découvert et installé pipewire que je ne connaissais pas du tout.
Merci de m'avoir répondu. Avant de lire ton message d'aujourd'hui, j'avais voulu faire un test de distribution. Vu que j'avais fait un tas d'installations de paquetages, certains avec des sources expérimentales, je me suis dit que j'avais mis la pagaille dans la Leap 15.6 J'ai donc tenté, sur une autre machine, deux install minimales de la Leap 15.6
La première, en utilisant la source openSUSE-Leap-15.6-NET-x86_64-Media.iso J'ai installé le minimum de KDE, et la virtualisation avec KVM. Je lance virt-manager --debug Je crée une machine virtuelle avec un disque utilisé dans la machine où j'avais des ennuis. Un Windows 7. Résultat : pas de son, et même message : (virt-manager:22705): GStreamer-App-CRITICAL **: 17:42:39.902: gst_app_src_push_internal: assertion 'GST_IS_APP_SRC (appsrc)' failed
La deuxième, en utilisant la source openSUSE-Leap-15.6-DVD-x86_64-Media.iso Et en débranchant le cable réseau, pour empêcher de charger les dernières versions de paquetages. J'ai installé le minimum de KDE, et la virtualisation avec KVM. Je lance virt-manager --debug Je crée une machine virtuelle avec le disque du même Windows 7 que précédemment. Résultat : ça marche !!!!! Pas de message d'erreur, et le son sort de la machine virtuelle.
Comment interpréter ça ? Peut-on dire que la 15.6 "up to date" qui s'installe avec openSUSE-Leap-15.6-NET-x86_64-Media.iso amène des paquetages dont les conflits de versions ne permettent plus de faire fonctionner virt-manager correctement ? Dois-je tenter, avec la dernière install, en rebranchant le cable, de mettre à jour paquet par paquet, afin de voir le coupable qui bloque le son ?
J'ai progressé en ajoutant quelques paquetages de pipewire, comme pipewire-pulseaudio
Voici les nouveaux résultats des commandes : pulseaudio --check donne :
var-lib-nfs-rpc_pipefs.mount loaded active mounted /var/lib/nfs/rpc_pipefs pipewire-pulse.service loaded active running PipeWire PulseAudio pipewire.service loaded active running PipeWire Multimedia Service pipewire-pulse.socket loaded active running PipeWire PulseAudio pipewire.socket loaded active running PipeWire Multimedia System Sockets
inxi -A donne : Audio: Device-1: Conexant Systems CX23887/8 PCIe Broadcast Audio and Video Decoder with 3D Comb driver: cx23885 Device-2: NVIDIA driver: snd_hda_intel Device-3: AMD Starship/Matisse HD Audio driver: snd_hda_intel API: ALSA v: k6.4.0-150600.23.50-default status: kernel-api Server-1: PipeWire v: 1.4.3 status: active
On voit apparaître PipeWire en serveur. On progresse !
Et pactl info donne :
Version du protocole de bibliothèque : 35 Version du protocole du serveur : 35 Local : oui Index client : 98 Tile Size : 65472 Nom d’hôte : localhost Nom du serveur : PulseAudio (on PipeWire 1.4.3) Version du serveur : 15.0.0 Spécification d’échantillon par défaut : float32le 2ch 48000Hz Plan de canaux par défaut : front-left,front-right Destination par défaut : alsa_output.pci-0000_0d_00.4.iec958-stereo Source par défaut : alsa_input.pci-0000_07_00.0.stereo-fallback
Malgré tout, ça ne marche toujours pas. Avec /usr/bin/virt-manager --debug je vois toujours : (virt-manager:5923): GStreamer-App-CRITICAL **: 21:39:50.101: gst_app_src_push_internal: assertion 'GST_IS_APP_SRC (appsrc)' failed
var-lib-nfs-rpc_pipefs.mount loaded active mounted /var/lib/nfs/rpc_pipefs pipewire.service loaded active running PipeWire Multimedia Service pulseaudio.service loaded active running Sound Service pipewire.socket loaded active running PipeWire Multimedia System Sockets pulseaudio.socket loaded active running Sound System
inxi -A donne : Audio: Device-1: Conexant Systems CX23887/8 PCIe Broadcast Audio and Video Decoder with 3D Comb driver: cx23885 Device-2: NVIDIA driver: snd_hda_intel Device-3: AMD Starship/Matisse HD Audio driver: snd_hda_intel API: ALSA v: k6.4.0-150600.23.50-default status: kernel-api Server-1: PulseAudio v: 17.0 status: active
Pas de pipewire à l'horizon.
J'ai regardé dans Yast : j'ai bien le paquetage pipewire 1.0.5+git36.60deeb2-150600.3.3.5
virt-viewer: No Audio due to Missing GStreamer Plugins #284447 Describe the bug: virt-viewer lacks sound support due to being built without GStreamer plugins. This prevents audio playback from virtual machines on the host system.
C'est bien ce qui se produit. J'incrimine donc la relation virt-manger <> GStreamer
Malheureusement, je ne sais pas interpréter la suite.
Quelqu'un d'expérimenté saurait décoder tout ça ?
Pour info, sur ma distribution : virt-manager --version 4.1.0-150600.12.6.2 gstreamer version 1.24.12-lp156.238.3
