J'ai un petit PC (p200/64mo) sous OpenBSD 3.5 depuis quelques jours et
j'ai voulu tester quelques jeux disponibles dans les packages. L=E0 je
parle principalement de prboom-2.2.4 et de lbreakout2-2.2.2p0, les deux
jeux utilisent SDL et SDL_Mixer et j'ai le m=EAme probl=EAme avec les deux :
un d=E9lai de quasiment une seconde entre le moment ou je fais une action
et le moment ou le son associ=E9 =E0 celle-ci se d=E9clanche. O=F9 ce probl=
=E8me
serait moindre pour lire un OGG, c'est tout de m=EAme assez g=E9nant
pour une partie de Doom ;) Ma carte son est compatible SB128 (es1371) :
eap0 at pci0 dev 11 function 0 "Ensoniq AudioPCI97" rev 0x08: irq 10
ac97: codec id 0x83847609 (SigmaTel STAC9721/23)
ac97: codec features 18 bit DAC, 18 bit ADC, SigmaTel 3D
Je n'ai pas l'impression d'avoir ce d=E9lai quand je lance ogg123.
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
espie
On a deja vu ca. C'est helas complique a resoudre comme probleme, si c'est bien celui auquel je pense.
L'idee, c'est que les programmes `temps reel' utilisent certains appels systemes pour savoir ou ils en sont cote son, histoire de se synchroniser avec le reste. Typiquement, l'ioctl AUDIO_GETINFO, histoires de recuperer le nombre de samples deja joues.
Le probleme, c'est que AUDIO_GETINFO fournit plein d'infos, en particulier le volume... et pour la spec AC97, cette info n'est stockee nulle part ailleurs que dans les registres de la carte... sur certaines cartes, l'obtenir se fait tres vite. D'autres cartes sont un peu plus lentes.
La vraie bonne solution, ca serait de revoir l'interface audio pour qu'elle soit moins absurde, et s'eloigner ainsi du vieux modele sunaudio.
Dans l'interim, tu dois pouvoir hacker un petit bout de AUDIO_GETINFO pour lui expliquer que tu n'en as rien a battre du volume... Genre, tu vires les appels a au_get_gain() et le petit bout qui gere sc_monitor_port dans audiogetinfo dans /usr/src/sys/dev/audio.c et tu vois si ca marche moins mal...
On a deja vu ca. C'est helas complique a resoudre comme probleme,
si c'est bien celui auquel je pense.
L'idee, c'est que les programmes `temps reel' utilisent certains
appels systemes pour savoir ou ils en sont cote son, histoire de
se synchroniser avec le reste. Typiquement, l'ioctl AUDIO_GETINFO,
histoires de recuperer le nombre de samples deja joues.
Le probleme, c'est que AUDIO_GETINFO fournit plein d'infos, en particulier
le volume... et pour la spec AC97, cette info n'est stockee nulle part
ailleurs que dans les registres de la carte... sur certaines cartes,
l'obtenir se fait tres vite. D'autres cartes sont un peu plus lentes.
La vraie bonne solution, ca serait de revoir l'interface audio pour qu'elle
soit moins absurde, et s'eloigner ainsi du vieux modele sunaudio.
Dans l'interim, tu dois pouvoir hacker un petit bout de AUDIO_GETINFO pour
lui expliquer que tu n'en as rien a battre du volume... Genre, tu vires les
appels a au_get_gain() et le petit bout qui gere sc_monitor_port dans
audiogetinfo dans /usr/src/sys/dev/audio.c
et tu vois si ca marche moins mal...
On a deja vu ca. C'est helas complique a resoudre comme probleme, si c'est bien celui auquel je pense.
L'idee, c'est que les programmes `temps reel' utilisent certains appels systemes pour savoir ou ils en sont cote son, histoire de se synchroniser avec le reste. Typiquement, l'ioctl AUDIO_GETINFO, histoires de recuperer le nombre de samples deja joues.
Le probleme, c'est que AUDIO_GETINFO fournit plein d'infos, en particulier le volume... et pour la spec AC97, cette info n'est stockee nulle part ailleurs que dans les registres de la carte... sur certaines cartes, l'obtenir se fait tres vite. D'autres cartes sont un peu plus lentes.
La vraie bonne solution, ca serait de revoir l'interface audio pour qu'elle soit moins absurde, et s'eloigner ainsi du vieux modele sunaudio.
Dans l'interim, tu dois pouvoir hacker un petit bout de AUDIO_GETINFO pour lui expliquer que tu n'en as rien a battre du volume... Genre, tu vires les appels a au_get_gain() et le petit bout qui gere sc_monitor_port dans audiogetinfo dans /usr/src/sys/dev/audio.c et tu vois si ca marche moins mal...
Bertrand Janin
Marc Espie a écrit (20/07/04) :
Dans l'interim, tu dois pouvoir hacker un petit bout de AUDIO_GETINFO pour lui expliquer que tu n'en as rien a battre du volume... Genre, tu vires les appels a au_get_gain() et le petit bout qui gere sc_monitor_port dans audiogetinfo dans /usr/src/sys/dev/audio.c et tu vois si ca marche moins mal...
Okay, alors je vais installer les sources du système pour la première fois et mettre les mains dans le cambouis ! Dans le cas où je n'arrive pas a supprimer le délai, ou si je ne le réduit pas considérablement, est-ce qu'une SB16 PnP serait plus rapide que sa frangine sois-disant surdouée ?
Dans l'interim, tu dois pouvoir hacker un petit bout de AUDIO_GETINFO
pour lui expliquer que tu n'en as rien a battre du volume... Genre, tu
vires les appels a au_get_gain() et le petit bout qui gere
sc_monitor_port dans audiogetinfo dans /usr/src/sys/dev/audio.c et tu
vois si ca marche moins mal...
Okay, alors je vais installer les sources du système pour la première
fois et mettre les mains dans le cambouis ! Dans le cas où je n'arrive
pas a supprimer le délai, ou si je ne le réduit pas considérablement,
est-ce qu'une SB16 PnP serait plus rapide que sa frangine sois-disant
surdouée ?
Dans l'interim, tu dois pouvoir hacker un petit bout de AUDIO_GETINFO pour lui expliquer que tu n'en as rien a battre du volume... Genre, tu vires les appels a au_get_gain() et le petit bout qui gere sc_monitor_port dans audiogetinfo dans /usr/src/sys/dev/audio.c et tu vois si ca marche moins mal...
Okay, alors je vais installer les sources du système pour la première fois et mettre les mains dans le cambouis ! Dans le cas où je n'arrive pas a supprimer le délai, ou si je ne le réduit pas considérablement, est-ce qu'une SB16 PnP serait plus rapide que sa frangine sois-disant surdouée ?
