|
| API pointeur sur procédure callback |
| Débuté par Damien, 15 déc. 2013 09:47 - 24 réponses |
| |
| | | |
|
| |
Membre enregistré
281 messages
Popularité : +24 (26 votes) |
|
Posté le 15 décembre 2013 - 09:47 |
Bonjour,
Je manipule avec les fonctions API de Windev la DLL Bass et je rencontre un soucis avec une fonction particulière de cette DLL.
HSYNC BASS_ChannelSetSync(
DWORD Handle,
DWORD type,
QWORD param,
SYNCPROC *proc,
void *user
);
([url]http://www.un4seen.com/doc/…[/url])
Cette fonction appel une procédure callback de cette forme :
void CALLBACK SyncProc(
HSYNC Handle,
DWORD channel,
DWORD Data,
void *user
);
([url]http://www.un4seen.com/doc/…[/url])
J'ai donc créé une procédure SyncProc comme ceci :
Procedure SyncProc(Handle_Stream, Channel, Data, User)
Et je tente d'appeler la fonction BASS_ChannelSetSync comme ceci :
API("bass", "BASS_ChannelSetSync", Handle_Stream_FX_P2, OUBinaire(BASS_SYNC_ONETIME, BASS_SYNC_POS), 10000, &SyncProc, 0)
Mais plantage direct de l'application avec le message d'erreur suivant :
Erreur à la ligne 1 du traitement Clic sur Bouton4.
Vous avez appelé la FONCTION API.
La FONCTION 'BASS_ChannelSetSync' de la DLL bass a provoqué une Erreur d'exécution.
Projet : media
Appel WL :
Traitement de 'Clic sur Bouton4' (Player.Bouton4), ligne 1, thread 0
FONCTION 'API', syntaxe 0
Que s'est-il passé ?
La FONCTION 'BASS_ChannelSetSync' de la DLL bass a provoqué une Erreur d'exécution.
Code Erreur : 2805
Niveau : Erreur fatale (EL_FATAL)
Dump de l'Erreur du module 'WD160VM.DLL' (16.0.150.6).
Identifiant des informations détaillées (.err) : 2805
Informations de débogage :
Détails techniques :
Module : WD160VM.DLL
Version du module : 16.0.150.6
VI : 01F160057k
Adresse de base : 25E60000
Erreur système : Access violation (GPF)
EIP = 25EDBC14
OS : Windows 2008 R2 Service Pack 1(6.1.7601)
Registres :
EIP = 25EDBC14 EBP = 0018F10C
EAX = 00000000 EBX = 00000000
ECX = 0018EDE0 EDX = 0000027D
ESI = ABCDABCD EDI = 0018F144
Pile des appels :
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25EC3CC0 : Execution() + 98132 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25EC3CC0 : Execution() + 94673 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]2600E250 : TermLibrary() + 358848 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 413280 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F4D060 : TermDLL() + 8144 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25EB46D0 : pQueryProxy() + 176 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25EB46D0 : pQueryProxy() + 176 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25EB46D0 : pQueryProxy() + 176 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 420864 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 420800 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 419216 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 419264 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 419056 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 419280 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 419440 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 419920 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 420288 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 419360 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 420304 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 526736 bytes
[WD160VM.DLL (25E60000), 16.0.150.6, 01F160057k]25F67870 : InfoVersionWeb() + 529472 bytes
FONCTION (0,90)
Informations supplémentaires :
EIT_PILEWL :
Clic sur Bouton4 (Player.Bouton4), ligne 1
EIT_DATEHEURE : 15/12/2013 00:10:26
Assistance
- Vérifiez les paramètres passés
- Vérifiez que le type des paramètres passés correspond bien à ceux attendus
- Vérifiez que les valeurs nulles sont bien tolérées par la FONCTION appelée
- Vérifiez les appels précédents à d'autres fonctions de cette DLL (ils ont pu la mettre DANS un état instable)
- SI le problème persiste, contactez le fournisseur de la DLL OU se trouve la FONCTION.
Je dois mal m'y prendre pour appeler la callback non ?
Merci d'avance ! |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
511 messages
Popularité : +18 (18 votes) |
|
Posté le 16 décembre 2013 - 13:57 |
Bonjour WDKyle,
Avec les API il n'y a pas de mystère :
il est plus prudent de typer les valeurs passés en paramètres, conformément à la signature des fonctions appelées.
Et comme le WLangage ne permet pas de typer explicitement des valeurs littérales, il vaut mieux passer par des variables qui elles seront clairement typées, et quii sont ensuite passés à la fonction de l'API.
(à partir de Windev 16, une alternative aux variables est l'utilisation du type "description d'API")
Sur les types de données:
• après un rapide coup d'oeil à certains fichiers BASS, je crois comprendre que tous les types HANDLE de BASS sont identiques à un DWORD (c'est vrai au moins pour une application 32 bits).
• DWORD est un entier non signé sur 4 octets.
• QWORD est un entier non signé sur 8 octets.
• Un pointeur est un entier système.
hSync, Handle_Stream_FX_P2, nType est un entier sans signe sur 4 octets
nParam est un entier sans signe sur 8 octets
pSyncProc, pUser est un entier système
nType = OUBinaire(BASS_SYNC_ONETIME, BASS_SYNC_POS)
nParam = 10000
pSyncProc = &SyncProc
pUser = 0
hSync = API("bass","BASS_ChannelSetSync",Handle_Stream_FX_P2, nType, nParam, pSyncProc, pUser)
De même pour une fonction de rappel :
mieux vaut clairement typer les paramètres de la fonction (les paramètres formels).
Procedure SyncProc(Handle_Stream est un entier sans signe sur 4 octets, Channel est un entier sans signe sur 4 octets, Data est un entier sans signe sur 4 octets, pUser est un entier système)
Ça peut sembler lourd, mais au moins c'est rigoureux.
--
Pour me contacter par courrier électronique, cliquez sur le lien ci-dessous (protection antispam): http://cerbermail.com/… |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
281 messages
Popularité : +24 (26 votes) |
|
Posté le 16 décembre 2013 - 15:34 |
Bonjour =JBO= !
Merci pour ton aide, je test ton code dès que je peux 
Concernant la description d'API, j'en utilise mais je suis passé par la fonction API() car je ne savais pas en quoi déclarer le pointeur de structure... entier système donc ?
Merci  |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
281 messages
Popularité : +24 (26 votes) |
|
Posté le 16 décembre 2013 - 19:06 |
Je reviens vers toi =JBO=, cela ne fonctionne pas mieux 
L'application crash avec la même erreur...
EDIT : Je viens de passer l'appel APi() en déclaration d'API et cela fonctionne...
BASS_ChannelSetSync est une Description d'API
BASS_ChannelSetSync.NomDLL = "bass.dll"
BASS_ChannelSetSync.NomFonction = "BASS_ChannelSetSync"
BASS_ChannelSetSync.TypeRetour = apiEntier_4
BASS_ChannelSetSync.Paramètre[1].Type = apiEntier_4
BASS_ChannelSetSync.Paramètre[2].Type = apiEntier_4
BASS_ChannelSetSync.Paramètre[3].Type = apiEntier_8
BASS_ChannelSetSync.Paramètre[4].Type = apiEntierSystème
BASS_ChannelSetSync.Paramètre[5].Type = apiEntierSystèmeMessage modifié, 16 décembre 2013 - 20:43 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
511 messages
Popularité : +18 (18 votes) |
|
Posté le 16 décembre 2013 - 21:24 |
WDKyle a écrit :
EDIT : Je viens de passer l'appel APi() en déclaration d'API et cela fonctionne...
Je suis content pour toi.
Mais quand même, c'est bizarre que l'appel direct via la fonction API ne fonctionne pas alors que la Description d'API fonctionne elle, pour une même "signature" ....
--
Pour me contacter par courrier électronique, cliquez sur le lien ci-dessous (protection antispam): http://cerbermail.com/… |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
281 messages
Popularité : +24 (26 votes) |
|
Posté le 16 décembre 2013 - 22:38 |
Merci
Par contre, Windev le roi de la latence !
La fonction est censé faire une boucle du son mais ce n'est pas propre, çà lag...
Faut que je regarde en créant peut-être une DLL externe dédié à cette manipulation... Une idée ? |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
148 messages
Popularité : +3 (3 votes) |
|
Posté le 17 décembre 2013 - 08:44 |
WDKyle a écrit :
Merci
Par contre, Windev le roi de la latence !
La fonction est censé faire une boucle du son mais ce n'est pas propre, çà lag...
Faut que je regarde en créant peut-être une DLL externe dédié à cette manipulation... Une idée ?
tu veux dire que tu n'arrives pas à écouter de la musique ou la radio ?
car de mon côté il y a qq années, j'avais réussi à lire mp3,ogg... ou des flux radios sans aucun problème.
la bizarrerie venait du fait que des fois, pas moyen d'écouter la radio (pour une même radio qui fonctionnait la veille par ex).
je n'ai jamais réglé ce problème.
je n'ai pas le code sous les yeux, mais je pourrais t'aider prochainement. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
281 messages
Popularité : +24 (26 votes) |
|
Posté le 17 décembre 2013 - 09:47 |
Non, la fonction BASS_ChannelSetSync sert à faire une action lorsque la durée précisé est arrivé dans le fichier son qu'on joue. On peux donc s'en servir pour faire une boucle pour lui dire comme action de revenir en avant dans le fichier son mais sous Windev c'est lent, j'ai un blanc d'une seconde avant que çà revienne en avant... |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
511 messages
Popularité : +18 (18 votes) |
|
Posté le 17 décembre 2013 - 15:35 |
Bonjour tout le monde !
WDKyle a écrit :
> Non, la fonction BASS_ChannelSetSync sert à faire une action lorsque la durée précisé est arrivé dans le fichier son qu'on joue. On peux donc s'en servir pour faire une boucle pour lui dire comme action de revenir en avant dans le fichier son mais sous Windev c'est lent, j'ai un blanc d'une seconde avant que çà revienne en avant...
Pas de réponse... que des questions.
As-tu essayé en ajoutant BASS_SYNC_MIXTIME ?
Cette latence peut-elle s'expliquer par le fonctionnement de l'application :
par exemple des timers en cours, des procédures automatiques, des fenêtres avec des effets graphiques, etc.
Bref y-a-t-il des traitements en cours qui s'exécutent dans le même thread que la fonction de rappel ?
As-tu fait des essais dans une application "allégée" afin de tester la réactivité dans des conditions optimales ?
Est-ce que l'application est multithread ?
Si oui, l'utilisation de la DLL BASS se fait-elle dans un thread dédié ?
--
Pour me contacter par courrier électronique, cliquez sur le lien ci-dessous (protection antispam): http://cerbermail.com/… |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
511 messages
Popularité : +18 (18 votes) |
|
Posté le 17 décembre 2013 - 15:48 |
Dans la documentation en ligne, il y a une explication intéressante ("thread" et "loop") pour la fonction de rappel SyncProc.
«User defined synchronizer callback function.»
http://www.un4seen.com/doc/…
Documentation DLL BASS :
Remarks
BASS creates a single thread dedicated to executing sync callback functions, so a callback function should be quick as other syncs cannot be processed until it has finished. Attribute slides (BASS_ChannelSlideAttribute) are also performed by the sync thread, so are also affected if a sync callback takes a long time.
"Mixtime" syncs are not executed in the sync thread, but immediately in whichever thread triggers them. In most cases that will be an update thread, and so the same restrictions that apply to stream callbacks (STREAMPROC) also apply here, except that BASS_ChannelStop can be used in a BASS_SYNC_POS sync's callback to stop a channel at a particular position.
BASS_ChannelSetPosition can be used in a mixtime sync to implement custom looping, eg. set a BASS_SYNC_POS sync at the loop end position and seek to the loop start position in the callback.
--
Pour me contacter par courrier électronique, cliquez sur le lien ci-dessous (protection antispam): http://cerbermail.com/… |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
511 messages
Popularité : +18 (18 votes) |
|
Posté le 17 décembre 2013 - 15:50 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
281 messages
Popularité : +24 (26 votes) |
|
Posté le 17 décembre 2013 - 16:36 |
Salut =JBO=,
Non rien de compliqué mon appli, c'est un appli de teste très basic. Il n'y a qu'un seul thread de lancé qui gère les défilement d'une jauge...
J'ai testé avec MIXTIME et ONETIME, aucun changement à part que l'un boucle à l'infini et le second ne fais qu'une boucle.
c'est çà le texte de 'laide que tu me parle ?
BASS creates a single thread dedicated to executing sync callback functions, so a callback function should be quick as other syncs cannot be processed until it has finished. Attribute slides (BASS_ChannelSlideAttribute) are also performed by the sync thread, so are also affected if a sync callback takes a long time.
"Mixtime" syncs are not executed in the sync thread, but immediately in whichever thread triggers them. In most cases that will be an update thread, and so the same restrictions that apply to stream callbacks (STREAMPROC) also apply here, except that BASS_ChannelStop can be used in a BASS_SYNC_POS sync's callback to stop a channel at a particular position.
BASS_ChannelSetPosition can be used in a mixtime sync to implement custom looping, eg. set a BASS_SYNC_POS sync at the loop end position and seek to the loop start position in the callback. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
281 messages
Popularité : +24 (26 votes) |
|
Posté le 17 décembre 2013 - 16:41 |
Il faudrait que je lance la callback dans un thread séparé ? |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
511 messages
Popularité : +18 (18 votes) |
|
Posté le 17 décembre 2013 - 17:05 |
L'aide de BASS explique que la fonction de rappel est exécutée dans un thread dédié aux fonctions de rappel: le "sync thread".
Si tu paramètres avec BASS_SYNC_MIXTIME, la fonction de rappel n'est pas exécutée dans le "sync thread", mais elle est exécutée dans le même le thread que celui où BASS a déclenché l'événement.
BASS_SYNC_MIXTIME peut s'utiliser avec BASS_SYNC_ONETIME.
Donc je pensais à ...
nType = OUBinaire(BASS_SYNC_MIXTIME, OUBinaire( BASS_SYNC_ONETIME, BASS_SYNC_POS))
ou à son équivalent
nType = BASS_SYNC_MIXTIME | BASS_SYNC_ONETIME | BASS_SYNC_POS
Que fait ta fonction SyncProc qui gère la boucle (on peut voir le code ?).
WDKyle a écrit :
Non rien de compliqué mon appli, c'est un appli de teste très basic. Il n'y a qu'un seul thread de lancé qui gère les défilement d'une jauge...
Je te suggère de faire une "application jetable" sans interface utilisateur, juste pour tester ta boucle et avec BASS_SYNC_MIXTIME.
Et si le résultat est décevant, alors tu pourras t'orienter vers un autre langage, sans regret.
--
Pour me contacter par courrier électronique, cliquez sur le lien ci-dessous (protection antispam): http://cerbermail.com/… |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
281 messages
Popularité : +24 (26 votes) |
|
Posté le 17 décembre 2013 - 17:21 |
D'ac, je vais tester dès que je peux ! Merci. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
281 messages
Popularité : +24 (26 votes) |
|
Posté le 17 décembre 2013 - 18:31 |
Je viens te tester en désactivant le thread de défilement et BASS_SYNC_MIXTIME | BASS_SYNC_ONETIME | BASS_SYNC_POS
J'ai toujours de la latence |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
38 messages |
|
Posté le 29 juillet 2015 - 11:08 |
Bonjour,
Je reviens sur ce post car je travaille exactement sur la même fonction de Bass.dll. Je souhaite utiliser la fonction BASS_ChannelSetSync pour programmer la lecture de playlist avec Windev17.
En fait, j'ai un problème avec la procédure callback que j'ai déclarée comme procédure globale
PROCEDURE callback_playlist(Handle_Stream est un entier sur 4 octets, Channel est un entier sur 4 octets, Data est un entier sur 4 octets, puser est un entier système, P_Filename est une chaîne)
L_FileName est une chaîne = parcour_playlist(P_Filename)
SI L_FileName = "" ALORS RETOUR
(suite du traitement....)
....
....
J'ai déclaré la fonctions de l'API BASS.DLL comme suit :
BASS_ChannelSetSync est une Description d'API
BASS_ChannelSetSync.NomDLL = "bass.dll"
BASS_ChannelSetSync.NomFonction = "BASS_ChannelSetSync"
BASS_ChannelSetSync.TypeRetour = apiEntier_4
BASS_ChannelSetSync.Paramètre[1].Type = apiEntier_4
BASS_ChannelSetSync.Paramètre[2].Type = apiEntier_4
BASS_ChannelSetSync.Paramètre[3].Type = apiEntier_8
BASS_ChannelSetSync.Paramètre[4].Type = apiEntierSystème // *proc callback function
BASS_ChannelSetSync.Paramètre[5].Type = apiEntierSystème // void *user
J'ai un problème avec le code suivant car je ne sais pas comment appeler la fonction callback_playlist dans la fonction BASS_ChannelSetSync. Malgré lee informations présentent dans le post sur lequel nous sommes, je ne trouve pas la solution. 
BASS_ChannelSetSync(L_HdMixer, BASS_SYNC_END|BASS_SYNC_MIXTIME, 0, callback_playlist,0) cette ligne provoque une erreur de compilation : La fonction callback_playlist n'a pas de syntaxe ne prenant aucun paramètre.
BASS_ChannelSetSync(L_HdMixer, BASS_SYNC_END|BASS_SYNC_MIXTIME, 0, callback_playlist(),0) cette ligne provoque une erreur de compilation : Le traitement 'callback_playlist' attend au moins 5 paramètres et vous n'en passez que 0.
Si vous avez une solution ou un début de piste, je suis preneur car cela fait plusieurs jours de je recherche une solution.
Merci et bonne journée à tous
--
Un passionné d'informatique mais pas que ... |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
38 messages |
|
Posté le 31 juillet 2015 - 11:07 |
Bonjour,
j'ai porté mon projet sur Windev20 pour voir si je trouvais une solution mais sans succès. Le code reste le même que ci-dessous à l'exception de l'appel de la procédure callback qui semble mieux convenir comme ceci :
BASS_ChannelSetSync(L_HdStream, BASS_SYNC_END|BASS_SYNC_MIXTIME, 0, &callback_playlist,&L_Puser)
Passage des 2 derniers paramètres par adresse.
J'ai aussi modifié la procédure callback comme suit pour la rendre conforme à ce qu'attend la DLL Bass (suppression du dernier paramètre de la fonction). Ce qui donne :
PROCEDURE callback_playlist(Handle_Stream est un entier sur 4 octets, Channel est un entier sur 4 octets, Data est un entier sur 4 octets, puser est un entier système)
Les données utilisateur comme le chemin et le nom de la playlist sont passées par adresse via puser.
Par contre, je bute toujours sur comment passer les paramètres à la procédure callback. Si vous avez des infos la dessus je suis preneur
Cordialement
--
Un passionné d'informatique mais pas que ... |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
394 messages
Popularité : +12 (12 votes) |
|
Posté le 31 juillet 2015 - 16:07 |
Salut Fabien, je te passe des bouts de code, pour un callback d'une DLL. A priori, j'ai utilisé une structure, que je remplis avec les informations voulues.
ABS_DEFAULT_CALLBACK_CONTEXT est une structure
nVersion est un entier
nParentWindow est un entier
nFlags est un entier
FIN
stABS_DEFAULT_CALLBACK_CONTEXT est un ABS_DEFAULT_CALLBACK_CONTEXT
Puis, je passe l'adresse du pointant sur la structure :
Procedure PRO_ABSDefaultCallback(nOperation est un entier système, nMsg est un entier, nProgressData est un entier système)
sMessageStatus est une chaîne = ""
sImageToUse est une chaîne = ""
nPercentage est un entier
nLenght est un entier
gnCallbackFunctionAddress = &PRO_ABSDefaultCallback
InitHasard()
nRandomNumber est un entier sans signe sur 4 octets = 0
nRandomNumber = Hasard(1,294967294)
stABS_DEFAULT_CALLBACK_CONTEXT.nVersion = 1
stABS_DEFAULT_CALLBACK_CONTEXT.nParentWindow = Null
stABS_DEFAULT_CALLBACK_CONTEXT.nFlags = 0
stABS_OPERATION.nOperationID = nRandomNumber
stABS_OPERATION.nContext = &stABS_DEFAULT_CALLBACK_CONTEXT
stABS_OPERATION.nCallback = nCallbackFunctionAddress
stABS_OPERATION.nTimeout = 10000
stABS_OPERATION.nFlags = ABS_OPERATION_FLAG_LL_CALLBACK
J'espère que cela te mettra sur la piste.
Cordialement, Michel.
--
If it works, don't touch it, don't look at it, AND don't fix it ! No patches, no SP ! JUST DONT FIX IT. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
281 messages
Popularité : +24 (26 votes) |
|
Posté le 31 juillet 2015 - 21:07 |
Bonsoir,
De mon coté, j'ai laissé totalement tomber la gestion de la DLL Bass avec Windev. J'ai développer une DLL en C# qui elle manipule Bass. C# est bien plus adapté pour ce genre de DLL de traitement en temps réel. Je te conseil de faire de même |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
38 messages |
|
Posté le 01 août 2015 - 14:47 |
Bonjour WDKyle,
Je te remercie pour l'info. J'ai fait de même avec du C++ pour la fonction callback pour la gestion du record (micro) mais là, pour enchaîner deux lectures de fichiers Audio les temps de réponses sont biens moins critiques.
Je pensais ne pas avoir besoin de passer par une DLL en C# ou C++. (la barbe ...)
En fait, avec Windev je suis arrivé à créer le mixer et le stream pour lire le premier fichier audio extrait de la playlist mais la fonction callback n'arrive pas à lire les fichiers suivants. La callback se lance bien à la fin du premier morceau comme prévu mais la function BASS_StreamCreatFile retourne systématiquement l'erreur N°2 (BASS_ERROR_FILEOPEN). Pour info j'ai contrôlé tous les chemins, noms et extensions des fichiers audios de la playlist.
Le code suivant permet de lire le premier fichier extrait de la playList mais pas les suivants.
//Main program
//----------------
G_HdMixer, G_HDStream, L_Flags est une entier de 4 octets //DWORD
L_Offset, L_Length est un entier de 8 octets //QWORD
L_First_Audio_File est une chaine
G_HdMixer = BASS_Mixer_StreamCreate(44100, 2, BASS_MIXER_END)
BASS_ChannelSetSync(G_HdMixer, BASS_SYNC_MIXTIME|BASS_SYNC_END, 0, &callback_playlist,0) //& = address of
// Find first audio file in playlist (m3u ou pls)
L_First_Audio_File = parcour_playlist(L_FileName)
G_HdStream=BASS_StreamCreateFile(L_Mem,L_First_Audio_File,L_Offset,L_Length,L_Flags) // open 1st source
BASS_Mixer_StreamAddChannel(G_HdMixer, G_HdStream, BASS_STREAM_AUTOFREE)
....
BASS_ChannelPlay(G_HdMixer,False)
//--------------------
// CallBack function
//--------------------
Procedure callback_playlist(Handle_Stream est un entier sans signe sur 4 octets, Channel est un entier sans signe sur 4 octets, Data est un entier sans signe sur 4 octets, puser est un entier systeme)
L_Mem est un booléen = Faux
L_Offset est un entier sans signe sur 8 octets = 0
L_Length est un entier sans signe sur 8 octets = 0
L_Flags est un entier sans signe sur 4 octets
L_FileAudio est une chaîne = ""
L_FileAudio = parcour_playlist(G_FileName)
G_HdStream = BASS_StreamCreateFile(L_Mem, L_FileAudio, L_Offset, L_Length, BASS_STREAM_DECODE|BASS_SAMPLE_FLOAT) // open next source
BASS_Mixer_StreamAddChannel(G_HdMixer, G_HdStream, BASS_STREAM_AUTOFREE|BASS_MIXER_NORAMPIN) // plug it in
BASS_ChannelSetPosition(G_HdMixer, 0, BASS_POS_BYTE) // reset the mixer
Bien que cela fasse plusieurs jours que je sois bloqué par ce problème et avant de m'orienter vers une DLL en C++ ou #, je voudrais être certain de ne pas passer à côté de quelque chose de simple ou d'évident. D'autant plus, que l'erreur générée ne semble pas être liée à d'éventuels problèmes de temps de réponse du framework de Windev. Ce qui est vraiment troublant c'est que la même function (BASS_StreamCreateFile) fonctionne lorsqu'elle est lancé depuis une procédure "standard" et qu'elle ne fonctionne plus lorsqu'elle est lancée depuis une procédure Callback.
Dans l'attente de vos retour, idées, avis,.... (qui sont très attendus .......)
Cordialement,
--
Un passionné d'informatique mais pas que ... |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
38 messages |
|
Posté le 01 août 2015 - 16:41 |
Bonjour Michel,
Je te remercie de ton retour. Comme tu le verras ci-dessus j'ai fais un grand pas en avant avec ton aide. Je passe l'adresse de la procédure Callback en argument de la procédure appelante.
A ce jour, je pense que le dysfonctionnement n'est oas forcement lié à Windev. Je regarde la fonction BASS_ChannelSetSync car à priori j'ai passé des paramètres dont le format n'est pas tout à fait correcte.
http://www.un4seen.com/doc/…
En corrigeant les paramètres comme ceci
BASS_ChannelSetSync(G_HdMixer, BASS_SYNC_MIXTIME, BASS_SYNC_END, &callback_playlist,0) //& = address of
au lieu de
BASS_ChannelSetSync(G_HdMixer, BASS_SYNC_MIXTIME|BASS_SYNC_END, 0, &callback_playlist,0) //& = address of
la Stream se crée dans la callback mais les 2 morceaux sont joués en même temps puis plus rien.....
Toutes la matière grises et la bienvenue
--
Un passionné d'informatique mais pas que ... |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
394 messages
Popularité : +12 (12 votes) |
|
Posté le 01 août 2015 - 19:56 |
Salut, c'est déjà un bon début... Les infos arrivent à la Callback, et cette dernière y réagit. J'avais eu un problème du genre... mais pas sur des morceaux de musique... Soit la structure qui contient les morceaux à jouer est mal remplie, soit il faut passer les morceaux un par un, des la fin du morceau jouer, envoyer le suivant, dans une boucle ...
A+, Michel.
--
If it works, don't touch it, don't look at it, AND don't fix it ! No patches, no SP ! JUST DONT FIX IT. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
394 messages
Popularité : +12 (12 votes) |
|
Posté le 01 août 2015 - 20:07 |
Je viens de regarder à nouveau... ton 0 (void * User) en fin de ligne, il s'agit une zone mémoire à passer en pointeur ... Tu devrais aussi définir l'utilisateur quelque part, lui donner une valeur, puis passer le pointeur, ...
Tentes voir de cette manière.
A+.
--
If it works, don't touch it, don't look at it, AND don't fix it ! No patches, no SP ! JUST DONT FIX IT. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
38 messages |
|
Posté le 03 août 2015 - 21:37 |
Bonsoir,
Après une nouvelle journée perdue à ronger mon nonos et à essayer de faire fonctionner ces fichues Callback, il faut bien que je me rende à l'évidence. Les callback avec Windev sont problématiques. Je vais donc suivre le conseil avisé de WDKyle et entreprendre l'écriture d'une dll en C++ pour palier aux problèmes rencontrés dans les Callback avec Windev.
Pour exemple, lorsque je lance BASS_StreamCreateFile dans une procédure "standard" (non callback) tout fonctionne normalement. Lorsque j'exécute cette même commande dans une procédure callback, la fonction BASS_StreamCreateFile retourne systématiquement une erreur N°2 (impossible d'ouvrir le fichier pour lecture ou décodage). Pourtant le fichier existe de façon certaine car je fais un fouvre et un fferme juste avant sans la moindre erreur....
Cela commence a être un peu pointu et, à mon avis, seul un expert ou le support Pcsoft pourrait répondre : L'exécution d'une procédure Callback dans le framework PCSoft permet-elle de faire appel à des API externes ?
Bref.... les arcanes des frameworks sont impénétrables ......
--
Un passionné d'informatique mais pas que ...
f.lesenne@idsinformatique.com |
| |
| |
| | | |
|
| | | | |
| | |
|