Je n'ai pas besoin de tout dans Alsa, seulement lister les cartes et quelques unes de leurs caractéristiques (format binaire, échantillonnage, nombre de canaux, et c'est tout je crois). Si je trouve un moyen d'obtenir tout ces informations simplement en lisant /proc ou /sys, je me ferai plutôt un pyalsa-light plutôt que de faire dépendre mon projet de Python 3 ET Python 2. L'idée de l'export dbus présentée dans le journal est seulement une idée rigolote mais que je n'envisage pas du tout sérieusement.
En gros j'ai plusieurs possibilité :
régresser tout le projet en Python 2
rester en Python 3 et ajouter une compilation manuelle en dépendance
rester en Python 3 et ajouter PyRO et Python 2 en dépendance, et devoir gérer un process supplémentaire.
réinventer la roue parce que je n'ai besoin que d'une roue, pas d'une voiture complète.
Je préfèrerai (en attendant la disponibilité de python3-pyalsa dans nos distros bien-aimées) la dernière solution (lire /proc ou /sys), sauf qu'en fait tout ça me semble inutilisable, c'est spécifique à chaque carte et chaque chipset. En gros /proc ou /sys ça ressemble à un faire un strings sur le charabia binaire que crache la carte, sans abstraction.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pyro
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Exposer un ou des modules Python sur D-Bus [proof of concept]. Évalué à 2.
Je n'ai pas besoin de tout dans Alsa, seulement lister les cartes et quelques unes de leurs caractéristiques (format binaire, échantillonnage, nombre de canaux, et c'est tout je crois). Si je trouve un moyen d'obtenir tout ces informations simplement en lisant /proc ou /sys, je me ferai plutôt un
pyalsa-lightplutôt que de faire dépendre mon projet de Python 3 ET Python 2. L'idée de l'export dbus présentée dans le journal est seulement une idée rigolote mais que je n'envisage pas du tout sérieusement.En gros j'ai plusieurs possibilité :
Je préfèrerai (en attendant la disponibilité de python3-pyalsa dans nos distros bien-aimées) la dernière solution (lire /proc ou /sys), sauf qu'en fait tout ça me semble inutilisable, c'est spécifique à chaque carte et chaque chipset. En gros /proc ou /sys ça ressemble à un faire un
stringssur le charabia binaire que crache la carte, sans abstraction.ce commentaire est sous licence cc by 4 et précédentes