Chargement...
 
Skip to main content

2 - Les distributions et les noyaux

Liste des forums Liste des sujets

Forums > 2 - Les distributions et les noyaux > [RÉSOLU] alsa, perte de son après mise en pause du lecteur audio/video
 
Thread actions
Print this page
  • Imprimer toutes les pages

    • [RÉSOLU] alsa, perte de son après mise en pause du lecteur audio/video

    Envoyé par lablonde le Fri 16 Jul 2021 08:50
    Bonjour tout le monde.

    J'utilise mon laptop sous debian Testing et de temps à autre Xubuntu comme source musicale.
    Sur ce pc est branché en USB, un dac audio de chez microméga.
    Au dac est relié par rca un ampli hifi Harman Kardon.
    Et à l'ampli est relié une paire d'enceintes colonnes Elipson, et une paire d'enceintes bibliothèque Triangle.

    J'ai entièrement viré pulseaudio, pour n'utiliser que Alsa et configurer /etc/asound.conf pour utiliser le dac comme carte son principal à l'échelle du système.

    J'utilise audacious pour écouter la musique (flac, m4a, alac, ogg), pour lire les CD audio, pour écouter la radio en ligne.
    J'utilise VLC pour regarder les films, séries, documentaires, chaînes TV freebox, youtube.

    Sur audacious comme VLC, j'ai paramétré la sortie audio sur alsa, et choisi le dac en mode direct hardware device without any conversions pour avoir un 'bitperfect' le plus pur possible.

    Jusque-là tout fonctionne très bien, les flac de qobuz en 192kHz sont bien lu tel quel sans reconversion logicielle, idem pour tous les autres échantillonnages.

    Mais je me heurte à un petit soucis récurrent.
    Si je mets en pause (audacious comme VLC) et que je 'dépause' je perds le son.
    La barre d'avancements avance toujours, le temps défile, mais plus aucun son.
    Seul moyen, fermer le lecteur, et le relancer.
    Ça me le fait sur tous les formats que j'ai pu lire par audacious (flac, m4a, mp3, ogg, alac)
    Et pour toutes sortes de vidéos sur VLC (mkv, avi, mp4, codec h264, h265), le son disparaît mais l'image est bel et bien présente.

    Ce problème n'existait pas quand j'utilisais encore pulseaudio paramétré de façon classique tel quel après une installation normale de debian.

    J'ai essayé sous manjaro et Endeavour OS en live usb (même config son qu'actuellement, et le problème est également présent)
    J'ai lancé audacious comme VLC via le terminal mais aucun message d'erreur lors de la perte de son.

    Du coup je sais qu'il existe le kernel real-time optimisé pour réduire la latence, et je me demandais si mon problème ne viendrait pas du kernel classique trop lent pour ce genre d'utilisation que j'ai ?!
    Comme le son est transmis direct au dac sans reconversion logicielle, est-ce que ça peut être trop de 'boulot' pour le kernel ?

    Est-ce avantageux dans mon cas précis de tenter le kernel real-time de chez debian ?
    Ou je fais complètement fausse route ?!
    Et le problème vient d'ailleurs ?

    Le dac de microméga est entièrement pris en charge nativement par linux.
    Et autre précision, ce soucis de play/pause et perte de son est présent aussi quand je passe par la carte son d'origine du pc (une Intel) avec les mêmes réglages en direct hardware without any conversion (pour la carte son du pc), play/pause et perte de son.
    D'où le faite que je soupçonne fortement le kernel classique.

    Désolé pour le pavé, je voulais être la plus précise possible.

    En espérant avoir de l'aide ici.
    Merci.
    Lectures: 4091
    Envoyé par lablonde le Fri 16 Jul 2021 13:56

    Petite précision.

    Avant la perte de son, je peux faire une fois, ou 15 fois play/pause, avant que le son disparaisse et ne revienne qu'après avoir fermé et relancé le lecteur.
    C'est donc très aléatoire, d'où le fait que je sois perplexe et à la recherche d'aide de gens calés pour me venir en aide !
    Envoyé par calixtus06 le Fri 16 Jul 2021 18:39
    Hello

    Je ne suis pas la bonne personne pour te répondre. Peut-être quelques pistes à te donner.

    Problème d’échantillonnage ? As tu la possibilité d'essayer d'autres paramètres que 192 ? A priori oui ..

    As tu essayé d'autres ports usb ?

    j'ai trouvé ça :

    https://forums.linuxmint.com/viewtopic.php?t=128478

    https://bbs.archlinux.org/viewtopic.php?id=264051

    Est-ce que pulseaudio ne se remettrait pas en route ?

    J'espère que des connaisseurs pourront ponctuer leurs vacances en faisant un tour par ici .
    Envoyé par bda le Fri 16 Jul 2021 20:14 France
    Bonjour,

    Je suis d'accord avec calixtux06, ça fait penser à une prise de contrôle du son par un serveur comme jack ou pulseaudio ou d'une perte de contrôle. Par contre ce qui est surprenant, c'est que VLC arrive à reprendre la main après redémarrage...

    Pour être utilisateur "anti-pulseaudio" depuis longtemps, je n'ai rien trouvé de mieux que ArchLinux pour s'en passer. Et encore, souvent avec l'aide de apulse. Aussi avec des distributions exotiques comme obarun, alpinelinux, ... Avec Debian/Ubuntu, c'est plus délicat car de nombreuses applications vont forcer l'installation de pulseaudio.

    Personnellement, pour la lecture audio dans la salon, je fais appel à kodi mais cette application passe en plein écran (on ne peut utiliser qu'elle). Mais elle peut remplacer audacious ET VLC. Ça vaut peut être le coup d'essayer histoire d'être certain que le problème vienne bien d'un serveur son ou d'alsa.

    Pour ce qui est du noyau TR, il serait valable si tu avais des craquements par exemple. Mais pas une coupure totale.
    Envoyé par lablonde le Fri 16 Jul 2021 20:39
    @calixtus06, j,'ai essayé les 4 ports usb et le problème est identique, changement de câble usb, problème identique, peut importe l'échantillonnage comme le format audio (du 192kHz en flac ou du 44kHz en m4a), le bug reste présent.
    Et comme mentionné dans mon 1er message, le bug est aussi présent avec la carte intel intégrée à la carte, ce qui enlève un soucis potentiel de perte de signal usb, malheureusement ça complique la tâche :/

    @bda, jack n'est pas installé sur mon système, et pour pulseaudio le seul paquet que j'ai c'est libpulse0, la description de Debian indique ceci
    Copy to clipboard
    Ce paquet contient les bibliothèques clientes utilisées par les
applications pour accéder à un serveur de son PulseAudio en utilisant
l'interface native de PulseAudio.

    il sert pour Audacious, VLC, Gimp, ffmpeg, mkvtoolnix, si je tente de le virer, ça me casse tous ces paquets.

    Apulse n'est pas installé sur mon système, mais dispo dans les dépôts de Debian, si je l'installe, et tente de virer libpulse0, tu penses que ça peut le faire ?
    Pour Debian, j'ai configuré pour que seul les paquets essentiels soient installés (donc pas de recommandés ni de suggérés, ce qui limite les paquets inutiles).

    Kodi je m'en sers pour regarder les replays tnt, et j'ai aussi le soucis de coupure de son..

    Donc le noyau RT dans mon cas ne servira à rien, donc le problème vient d'ailleurs.
    Envoyé par lablonde le Fri 16 Jul 2021 21:45
    même problème que lui ici
    https://crunchbang.org/forums/viewtopic.php?id=22980

    Et je viens de vérifier, chez moi aussi quand le son crashe, si je fais avancer le curseur de temps, et que je dépause, le son revient.
    Quand le son se coupe, si j'appuie sur stop, et que je clique sur play, le son revient aussi.
    Aussi bien sur Audacious que VLC.

    C'est à rien n'y comprendre..
    Pas un bug grave, mais putain de chiant quand même !!
    Envoyé par Samuel le Fri 16 Jul 2021 23:23 Allemagne
    Je confirme qu'un noyau RT ou low-latency ne résoudra pas le problème, ça ne fera qu'ajouter une charge supplémentaire à ton processeur.
    Tes procédures de tests sont sans faute, et je dois avouer que sans pulse ni jackd, on est un peu "à poil" vu qu'ils sont vraiment nécessaire à notre utilisation MAO. On dirait que tes lecteurs n'arrivent pas à se reconnecter à ton DAC, mais je ne m'y connais pas assez dans le fonctionnement de alsa pour te répondre de manière formelle.

    Est ce qu'avec alsamixer tu arrives à voir ton DAC ?
    Envoyé par lablonde le Sat 17 Jul 2021 09:44
    Oui mais comme déjà dit, j'ai le même bug avec la carte son intel intégrée à la carte mère, donc pas de connexion usb, et donc pas de perte possible, t'en conviendra ?!
    De toute façon la petite lupiote est bien allumée en permanence sur le dac même pendant la perte de son, donc bien reconnu.
    Et comme le bug est présent avec la carte son intégrée à la carte mère, on peut chercher ailleurs que la perte signal usb..

    Ce foutu bug existe depuis 2012, un topic sur archlinux en parle, pourquoi il traîne encore ?
    Je suis la seule à utiliser que alsa sans pulseaudio, un dac, et vouloir mettre les musiques en pause ? Sérieusement ?

    Et oui le dac est bien reconnu par alsamixer, et je l'ai défini par défaut dans le /etc/asound.conf, pour que ce soit la carte son à l'échelle du système.
    Envoyé par bda le Sat 17 Jul 2021 11:35 France
    Tu n'est pas la seule personne a mettre la musique et les vidéos en pause, mais une des très rares à rencontrer ce problème.

    Les liens que tu cites ne parlent pas tous du même soucis. Par exemple sur Archlinux, avec un walkman Sony, il n'y a pas de son du tout. Le lien crunchbang est similaire au tien mais pas forcément dans les même conditions (interface audio / dac différent, ...)

    Si tu arrives à voir ton DAC avec alsamixer, ce serait intéressant de vérifier si le son est juste mis en sourdine (mute) ou si le problème est ailleurs. Il faudrait, par exemple, activer la sourdine (ou la désactiver) manuellement dans alsamixer, lorsque le problème apparaît. Si c'est le cas, il doit y avoir plusieurs solutions ou contournements.
    Est-ce que tu mets en pause à la souris, au clavier (genre avec les touches multimédia), ou avec une télécommande ou n'importe quoi d'autre?

    Aussi, lancer la commande "dmesg" dans un terminal avant le problème, activer le problème et relancer la commande histoire de comparer les deux résultats. Il est possible que le problème apparaisse...
    Envoyé par lablonde le Sat 17 Jul 2021 12:06
    Alors je viens de vérifier, quand je perds le son, dans alsamixer il n'est pas en sourdine.
    Si je mets en sourdine, et enlève la sourdine, et que je "dépause", le son ne revient toujours pas.
    Je peux retrouver le son, soit en avancer la barre de temps, soit en mettant stop, et refaire play, soit en fermant le lecteur, et en le relançant (aussi bien Audacious que VLC).

    Pour mettre en pause/play les lecteurs, je le fais soit via le bouton adéquat dans le lecteur, soit via la touche espace (pour VLC notamment), soit via le raccourci fn+F7 du pc.
    Pas de télécommande ou autre.

    La commande dmesg | tail -20 (pour voir les 20 dernières entrées) ne mentionne rien au niveau de la perte de son.
    J'ai essayé également avec la commande journalctl | tail -20 mais rien ne mentionne la perte de son encore une fois.
    Et j'ai essayé en lançant vlc comme Audacious via le terminal, jusqu'à la perte de son, et idem absolument aucune mention de cette perte sonore.

    Et j'ai essayé d'autres lecteurs me disant que eux 2 pouvaient être le problème, mais deadbeef, clémentine, rhytmbox réagissent de la même façon..

    Du coup on dirait un bug fantôme, inexistant aux yeux du système, mais pourtant bien réel, je ne comprends pas..

    Apulse n'est pas installé sur mon système, ça vaudrait le coup d'essayer, ou c'est inutile ?
    Envoyé par bda le Sat 17 Jul 2021 13:44 France
    apulse n'est valable que pour utiliser des applications qui requièrent pulseaudio. Dans ton cas il n'apporterait rien car tes applications fonctionnent avec alsa.
    Par contre il ne faut pas toucher à libpulse, ça empêcherait le fonctionnement des applications qui en ont besoin (même si elles peuvent fonctionner sans pulseaudio).

    Par contre j'ai eu un problème différent mais tout aussi étrange lors du montage de mon pc actuel. Les vidéos comportant de l'audio défilaient à moins de 10 images par seconde. Tout ça pour un bête conflit de pilote audio!
    En effet, ma carte mère embarque une interface audio sur le bus USB (d'habitude c'est sur le bus PCI) et ma CG AMD a aussi son chipset audio. J'ai du mettre le pilote (module) snd_hda_intel (oui, c'est bien le pilote audio de ma CG AMD!) en blacklist.
    J'avais aussi tout un tas de choses plus étranges les unes que les autres. Le conflit venait du module snd_hda_codec, utilisé par les deux interfaces audio... Soucis qui n'est toujours pas réglé mais apparemment assez rare.

    Ça vaut peut être le coup d'essayer avec un fichier /etc/modprobe.d/blacklist.conf contenant:
    Copy to clipboard
    install snd_hda_intel /bin/true

    Envoyé par lablonde le Sat 17 Jul 2021 14:49
    c'est ce qu'il me semblait avoir comprendre pour apulse.
    et si je tente de supprimer libpulse0, ça me casse audacious vlc, etc donc je n'y touche pas.

    je vois que l'on est plusieurs à avoir des bugs étranges et assez isolés du coup.
    je viens d'essayer le fichier blacklist dans modprobe, reboot, mais le soucis demeure identique, toujours la perte de son après pause/play.
    pourtant le dac a bien la lupiote allumée donc toujours bien alimenté par l'usb.

    je ne comprends vraiment pas :/
    c'est con parce que je me sers souvent de la pause, du coup ça me handicape un peu beaucoup ...
    Envoyé par lablonde le Sat 17 Jul 2021 15:37
    En faisant des tests plus ou moins poussés, je peux en déduire un truc.

    Dans Audacious comme VLC, si je choisis le dac avec l'option direct hardware device without any conversions qui est quand même l'intérêt d'un dac de laisser le son tel qu'il arrive, j'ai le plantage du son qui survient après mise en pause/play.

    Si je choisis n'importe quelle autre option, le son ne plante jamais après une mise en pause/play, mais tout est ré-échantillonné en 48khz, ce que je ne veux pas forcément, passer d'une musique en 192kHz à 48kHz, ça se sent à l'écoute, et l'intérêt d'un système hifi à 1 000 balles devient débile !!

    Et en cherchant sur internet, je n'ai pas trouvé d'option permettant d'empêcher alsa de ré-échantillonner la fréquence, en faite ça revient au même que quand pulseaudio est installé..

    c'est quand même dingue qu'une option si basique n'existe pas, je comprends pas les choix des développeurs parfois :/

    bref ça commence à me soûler, je vais prendre l'air, pas y passer ma journée sur cette merde, je ferais sans le play/pause et tant pis !
    Envoyé par Samuel le Sat 17 Jul 2021 16:57 Allemagne
    Je suis vraiment désolé pour toi, c'est frustrant ce genre de bug, surtout quand c'est d'aussi bas niveau.
    Idéalement, il faut le rapporter aux développeurs d'alsa pour qu'ils puissent améliorer le tout, mais ça signifie effectivement tout réexpliquer etc...
    Mais ça serait naturellement cool pour tous les audiophiles 😀

    De mon coté, je vais me documenter un peu sur les aspects audiophiles de notre plateforme préférée. J'utilise jackd, donc je ne me suis jamais posé la question du ré-échantillonnage, vu qu'il fonctionne à la fréquence d’échantillonnage choisie. Et Bit depth, c'est important aussi 😀

    D'ailleurs c'est peut être un moyen de contourner ça ? utiliser jackd sans pulseaudio ? La carte/DAC serait lockée, et ça empèche de regarder youtube et d'écouter du son en même temps, mais c'est éventuellement une solution.
    Envoyé par lablonde le Sat 17 Jul 2021 17:37
    Si les dev de alsa en tiennent compte, ce serait cool en effet, je veux bien tenter, mais honnêtement j'espère pas grand chose.

    Avec alsa sans pulseaudio, c'est le cas aussi, quand un son sort, impossible de lire un 2e son, ce qui n'est pas un problème pour ma part.

    Utiliser jackd pourquoi pas, si ça résolu le problème, je veux bien.
    J'avais survolé la doc de jack, mais j'avais pas compris grand chose (je suis pas une lumière).
    Après si on m'explique, je peux m'en sortir 😉
    Envoyé par bda le Sun 18 Jul 2021 11:55 France
    J'ai pu emprunter un DAC SMSL hier soir. Je n'ai pas la référence exacte mais c'est quelque chose comme "sanrit" et je n'ai pas cherché plus loin.
    Mais aucun soucis avec Archlinux et le noyau linux-zen (5.12.15.zen1-1). Je n'ai essayé que VLC mais RAS.
    Difficile de savoir si c'est un soucis spécifique à ton DAC ou si ton noyau est trop ancien. À ta place, j'essaierai une live genre manjaro (donc basée sur arch avec un noyau assez frais).

    Dernière idée, tu pourrais nous mettre le contenu de ton /etc/asound.conf stp?
    Envoyé par lablonde le Sun 18 Jul 2021 13:51
    Mon /etc/asound.conf ressemble à ceci
    Copy to clipboard
    # Réglages Alsa pour que le Dac soit par défaut sur tout le système #
pcm.primary {
        type hw
        card MYDAC
        device 0
}

ctl.primary {
        type hw
        card MYDAC
        device 0
}


    Le retour de aplay -l donne ceci
    Copy to clipboard
    carte 0: PCH [HDA Intel PCH], périphérique 0: ALC280 Analog [ALC280 Analog]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 0: PCH [HDA Intel PCH], périphérique 3: HDMI 0 [HDMI 0]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 1: NVidia [HDA NVidia], périphérique 3: HDMI 0 [HDMI 0]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 1: NVidia [HDA NVidia], périphérique 7: HDMI 0 [HDMI 0]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 1: NVidia [HDA NVidia], périphérique 8: HDMI 0 [HDMI 0]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 1: NVidia [HDA NVidia], périphérique 9: HDMI 0 [HDMI 0]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 2: MYDAC [MICROMEGA MYDAC], périphérique 0: USB Audio [USB Audio]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0


    J'ai essayé Endeavour Os (base Arch) donc ultra récent, et je peux reproduire le même bug sur Audacious comme VLC, aussi bien avec le Dac que la carte son intégrée à la carte mère.

    Mais en farfouillant les paramètres de Audacious, je viens de tester un truc.
    Pour le réglage de la taille du tampon (qui était à 500 ms d'origine), je viens de le passer au maximum autorisé par Audacious (10 000 ms) et étrangement le bug de la perte de son a disparu.

    Pour tenter de reproduire le bug habituel, je pause/play de façon répétée jusqu'à perdre le son, et là nickel, même en restant appuyée sur la touche espace pendant plusieurs dizaines de secondes (ça pause/play ultra rapidement) pas de perte de son.

    En remettant la taille du tampon inférieur à 10 000 ms, le bug revient.

    J'ai essayé sur différents formats de musique (flac 24 bits à 192kHz, flac 24 bits à 96kHz, flac 16 bits à 44kHz, alac en 16 bits à 44kHz, m4a à 44kHz, mp3 en 44kHz), aucun crash pourtant j'abuse volontairement de la pause/play (bien au-delà de mon utilisation classique), et le même comportement sur Endeavour Os en live usb, que sur ma Debian installée, du coup je me doute que ce soit un hasard, la taille du tampon a l'air d'être le problème si trop bas, mais la solution si réglé au maximum.

    Du coup, je me pose une question, à quoi sert la taille du tampon ?
    De mettre une taille de tampon aussi élevée a des répercussions sur le système ? sur la qualité du son ?
    Pourquoi dois-je le mettre au maximum ?
    Alors que partout sur internet, il conseille de le mettre le plus bas possible !
    Oui ça fait beaucoup de questions, mais sur ce point je suis nulle 😉
    Pourtant j'ai un pc assez solide malgré son âge (intel i7 3e génération quad core, 12 Go de ram, SSD)

    J'ai essayé avec VLC de changer la taille du tampon, mais là rien ne change, je peux toujours reproduire le bug (aussi bien avec des musiques, que des vidéos, comme depuis le début).

    Mais il y a du progrès pour Audacious en tout cas, enfin il faut que je teste plusieurs heures pour être certaine, parce que là c'est des tests rapide quand même !
    Envoyé par bda le Sun 18 Jul 2021 14:55 France
    On avance 😉
    Tu as donc trois interfaces audio. Une Intel HDA, une nvidia et ce fameux DAC.

    Tu peux nous donner un lsmod, stp? Je me demande si en désactivant les interfaces non utilisées (ou en leur donnant un index autre que 0) améliorerait les choses...
    Envoyé par lablonde le Sun 18 Jul 2021 18:57
    exact, 3 interfaces audio.

    le retour de lsmod

    Copy to clipboard
    Module                  Size  Used by
ctr                    16384  4
ccm                    20480  6
8021q                  40960  0
garp                   16384  1 8021q
stp                    16384  1 garp
mrp                    20480  1 8021q
llc                    16384  2 stp,garp
snd_hda_codec_hdmi     61440  5
snd_hda_codec_realtek   126976  1
snd_hda_codec_generic    90112  1 snd_hda_codec_realtek
hid_generic            16384  0
usbhid                 57344  0
hid                   139264  2 usbhid,hid_generic
intel_rapl             24576  0
arc4                   16384  2
iwldvm                159744  0
nls_ascii              16384  1
nls_cp437              20480  1
vfat                   20480  1
mac80211              835584  1 iwldvm
fat                    86016  1 vfat
x86_pkg_temp_thermal    16384  0
intel_powerclamp       16384  0
crct10dif_pclmul       16384  0
crc32_pclmul           16384  0
rtsx_pci_sdmmc         28672  0
rtsx_pci_ms            20480  0
ghash_clmulni_intel    16384  0
mmc_core              176128  1 rtsx_pci_sdmmc
intel_cstate           16384  0
memstick               16384  1 rtsx_pci_ms
iwlwifi               249856  1 iwldvm
i915                 1736704  5
nouveau              2179072  1
iTCO_wdt               16384  0
efi_pstore             16384  0
snd_hda_intel          49152  4
iTCO_vendor_support    16384  1 iTCO_wdt
snd_hda_codec         151552  4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
cfg80211              774144  3 iwldvm,iwlwifi,mac80211
snd_hda_core           94208  5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
intel_uncore          135168  0
xhci_pci               16384  0
snd_hwdep              16384  1 snd_hda_codec
snd_pcm               114688  5 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
xhci_hcd              266240  1 xhci_pci
ehci_pci               16384  0
snd_timer              36864  1 snd_pcm
mxm_wmi                16384  1 nouveau
ehci_hcd               94208  1 ehci_pci
alx                    53248  0
sr_mod                 28672  0
ttm                   126976  1 nouveau
intel_rapl_perf        16384  0
snd                    94208  15 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm
cdrom                  65536  1 sr_mod
pcspkr                 16384  0
efivars                20480  1 efi_pstore
pcc_cpufreq            16384  0
i2c_i801               28672  0
usbcore               299008  5 xhci_hcd,ehci_pci,usbhid,ehci_hcd,xhci_pci
drm_kms_helper        208896  2 i915,nouveau
rfkill                 28672  3 cfg80211
mei_me                 45056  0
soundcore              16384  1 snd
mdio                   16384  1 alx
rtsx_pci               73728  2 rtsx_pci_sdmmc,rtsx_pci_ms
sg                     36864  0
mei                   118784  1 mei_me
lpc_ich                28672  0
i2c_algo_bit           16384  2 i915,nouveau
battery                20480  0
mfd_core               16384  2 rtsx_pci,lpc_ich
usb_common             16384  1 usbcore
toshiba_haps           16384  0
wmi                    28672  2 mxm_wmi,nouveau
ac                     16384  0
video                  49152  2 i915,nouveau
button                 20480  1 nouveau
drm                   495616  9 drm_kms_helper,i915,ttm,nouveau
coretemp               16384  0
fuse                  122880  3
configfs               53248  1
efivarfs               16384  1
autofs4                49152  2
ext4                  745472  2
crc16                  16384  1 ext4
mbcache                16384  1 ext4
jbd2                  122880  1 ext4
crc32c_generic         16384  0
fscrypto               32768  1 ext4
ecb                    16384  0
sd_mod                 61440  5
crc32c_intel           24576  4
ahci                   40960  3
libahci                40960  1 ahci
libata                270336  2 libahci,ahci
aesni_intel           200704  4
scsi_mod              249856  4 sd_mod,libata,sg,sr_mod
aes_x86_64             20480  1 aesni_intel
crypto_simd            16384  1 aesni_intel
cryptd                 28672  3 crypto_simd,ghash_clmulni_intel,aesni_intel
evdev                  28672  10
glue_helper            16384  1 aesni_intel
serio_raw              16384  0
thermal                20480  0
fan                    16384  0


    j'avais fais la manip de blacklister les modules en rapport avec l'interface Intel et Nvidia, mais ça n'avait rien changé.

    Pour VLC, j'ai réussi à résoudre le problème de perte de son.
    Dans les préférences, j'ai mis le cache fichier à 300 ms, et nickel ça a l'air de tenir.
    Si je mets + pour le cache fichier je retrouve à nouveau le bug.

    Du coup le problème a l'air d'être un soucis de cache et de tampon propre à chaque logiciel.
    Le pourquoi du comment, là je ne sais, je ne suis pas assez calée, mais une chose est sûre, en utilisant pulseaudio le problème n'existait pas, donc c'est en rapport avec alsa, le mode "bitperfect" et les logiciels à configurer autrement.

    Mais je vais faire des tests d'utilisation sur plusieurs jours pendant plusieurs heures d'écoute de musique et/ou visionnage de films/vidéos, pour être sûre que tout soit résolu !
    Envoyé par bda le Sun 18 Jul 2021 21:36 France
    Si ça fonctionne, tant mieux.
    Je viens de voir que tu as un portable équipé d'une CG nvidia en plus du GPU Intel intégré (techno optimus).
    Le pilote libre "nouveau" a ses limites et nvidia n'aide pas beaucoup à améliorer les choses. Mais le pilote proprio est très performant et résout un grand nombre de problème. En particulier si ta CG est assez récente (à partir des 10x0).

    En attendant, bonne écoute et bon visionnage. Tiens nous au courant.
    Envoyé par lablonde le Sun 18 Jul 2021 22:37
    La nvidia est très vieille, le pilote proprio qu'elle a besoin n'est plus dans les dépôts debian, du coup j'utilise le pilote nouveau, mais je me sers quasiment jamais de la nvidia, donc ça ne me dérange pas.

    Pour les premiers tests d'écoute et visionnage, ça a l'air de tenir.
    Pour le moment aucune perte de son, ça sent plutôt bon 😊

    Merci pour l'aide.
    De toute façon je viendrais clôturer le topic, je me donne quelques jours supplémentaires pour tout tester comme il se doit, et être sûre des réglages etc.
    Page: 1/2  [Suivant]
    1  2