Bonjour,
J'ai regardé un peu la doc... Est-ce que la classe QBuffer dispose d'une fonction qui recherche dans la RAM un buffer crée par un lecteur multimédia externe à mon programme et pas forcément programmé en Qt c++ ? Si oui laquelle ?
Version imprimable
Bonjour,
J'ai regardé un peu la doc... Est-ce que la classe QBuffer dispose d'une fonction qui recherche dans la RAM un buffer crée par un lecteur multimédia externe à mon programme et pas forcément programmé en Qt c++ ? Si oui laquelle ?
Bonjour,
J'ai l'impression que ce que vous voulez faire n'est pas possible tout court. En effet essayer d'accéder à des données en RAM qui n'appartiennent pas au programme courant est totalement exclue (le système d'exploitation nous stoppe avec une jolie segmentation fault)Citation:
Envoyé par gizmo27
Je dois dire que une solution existe: les segments de mémoire partagés. Mais c'est un cas assez précis, qui ne semble pas spécialement fait pour votre cas (à part si le programme source documente ce phénomène)
Bonjour,
Tiens c'est marrant que vous parliez de mémoire partagée car je suis tombé dessus sur le net pas plus tard qu'hier.
En fait je vais essayer de faire simple avec les moyens du bord sinon je sens que je vais me casser la binette ;) et gratuitement en plus ;)
Non non...
Vite fait à propos du QBuffer : en fait j'ai regardé à quoi cela servait : la première explication est que ça permet de régler le problème de 2 périphériques qui ne lisent pas les données à la même vitesse. Puis en fouillant un peu j'ai trouvé une autre explication : si on compare par exemple à un QFile, le QBuffer permet d'utliser la RAM et pas le disque dur : cela permet à long terme d'éviter d'utiliser la pointe de lecture du disque dur et donc d'éviter de l'endommager trop vite.
Bonne journée.
Certes c'est une consequence du buffer, mais pas la raison principale. L'histoire est simplement que la RAM est beaucoup plus rapide que le disque dur (ou autre peripherique). Donc si on a besoin frequement d'information qui se trouve dans un fichier ... il est preferable de faire un chargement (lecture) et de garder le contenu en memoire.Citation:
Envoyé par gizmo27
Ah ok. J'imagine alors que si j'en ai besoin, je ne serai ni le premier ni le dernier à l'utiliser...
Bonjour
Et tu sais sur quel critère faire ta recherche ? tu sais comment le programme externe utilise la mémoire ? quel codage il utilise ?Citation:
une fonction qui recherche dans la RAM un buffer crée par un lecteur multimédia externe
Ça me semble être très difficile de faire ça.
J'ai un doute : tu es sur ? Si on est en lecture seule ?Citation:
En effet essayer d'accéder à des données en RAM qui n'appartiennent pas au programme courant est totalement exclue (le système d'exploitation nous stoppe avec une jolie segmentation fault)
J'espère que... non :) puisque QFile (et en fait tous les QIOdevice) ouvre par défaut en utilisant un buffer (sauf si on spécifie explicitement QIODevice::Unbuffered). Donc l'utilisation de QBuffer n'est pas nécessaire (sauf cas très spécifique)Citation:
Ah ok. J'imagine alors que si j'en ai besoin, je ne serai ni le premier ni le dernier à l'utiliser...
Bonsoir,
Non je vais laisser tomber cette piste n'est pas bonne je vais droit vers le mur : non seulement c'est l'explorateur Windows qui n'est pas codé en Qt c++ mais en plus on peut avoir plusieurs fenêtre ouverte par l'explorer.exe
En vérité c'est dommage qu'on ne puisse pas pour l'instant : interroger la carte son et lui demander l'origine du flux qui la traverse par exemple.
C'est dommage car je trouve Qt vraiment simple comparé à l'API Windows.
Il va falloir que je reconsidère totalement mon projet car je suis parti sur une fausse piste... Je verrai ça il va falloir que ça murisse dans ma tête.
Ou bien je me cogne la tête contre la cuvette des toilettes pour accélérer le processus mdr... Non je rigole ça ça ne marche que dans Retour vers le Futur ;):mrgreen: Bonne soirée à vous et à bientôt. En tout cas merci de votre patience.
Pas compris l'histoire avec explorer.exe
Sinon pour en revenir avec votre égaliseur .. je réitère ce que j'ai déjà dit ... je pense que Qt est loin d'être pratique pour ce cas là ... et qu'il faut mieux utiliser une autre bibliothèque plus spécialisée.
Ouep ... je pense bien ... (j'en avais déjà parlé sur le forum C / C++ ) certes l'OS ne nous stoppe pas de suite de suite (selon la page mémmoire) mais il va nous stopper ...Citation:
J'ai un doute : tu es sur ? Si on est en lecture seule ?Citation:
En effet essayer d'accéder à des données en RAM qui n'appartiennent pas au programme courant est totalement exclue (le système d'exploitation nous stoppe avec une jolie segmentation fault)
Bonjour,
Merci du conseil je pense que je vais faire comme ça. Y'a-t-il une bibliothèque qui vous vient à l'esprit ? La SDL par exemple ?
Bonne journée.
Dernièrement, je dirai portaudio (j'espère que c'est bien le nom). Sinon ... pas d'idée ...
ah oui j'en ai aussi entendu parler. merci je vais regarder de ce côté-ci.
PS : je viens de lire qu'Audacity a été compilé avec cet EDI.
Que EDI ?Citation:
Envoyé par gizmo27
oui pardon c'est une librairie. Est-ce qu'on peut l'intégrer facilement pour continuer à programmer avec Qt Creator ?
Bonjour, comment allez-vous ?
Je reviens avec une question un peu différente : disons que si je cherche à faire un égaliseur audio en temps réel qui égalise n'importe quel fichier lu depuis un autre programme est-ce possible par pointeur ?
Je m'explique cet égaliseur audio permettrait de modifier le son d'un mp3 lu par un programme externe (ex : vlc) dont je ne connais pas le code source.
Je sais que vous m'avez dit que c'est impossible ou alors très difficile à réaliser.
Mais si par exemple je créais un code Qt qui a un sorte d'"agent" qui scanne la RAM ou la RAM partagée et regarde quels fichiers sont chargés : si c'est un mp3 ou extension audio alors je récupère l'adresse mémoire dans un pointeur que j'ai crée dans mon programme.
Et c'est gagné ? (à moins qu'il y ait un os...)
J'avais pensé à une autre solution aussi qui était de communiquer avec Directx pour Windows ou GStreamer pour Linux ? C'est peut-être plus simple ainsi ?
Et ensuite utiliser le bon vieux système de path à la Qt...
Et oui, il y a un OS, ou SE en français.Citation:
Et c'est gagné ? (à moins qu'il y ait un os...)
En fait, la meilleure méthode que je vois, c'est de gérer directement avec le système d'exploitation, afin de pouvoir intégrer votre "filtre/effet" à la chaine de rendu du son du système (juste avant la sortie sur le Master). Du coup, pour Windows, se sera surement dans la WinAPI, pour GNU/Linux, soit Alsa / OSS ou je ne sais jamais le nom des autres.
Merci bien.
Cordialement, Gizmo.
Bonjour,
Pardonnez d'insister sur la méthode pointeur (je suis têtu ;):)), mais cette méthode que j'ai citée est impossible à réaliser dans la pratique ?
Car en définitive, vlc ou tout autre lecteur chargent bien le fichier *.mp3 dans la RAM ? Donc il me suffirait de dire à mon programme de rechercher dans la RAM, de trouver le fichier *.mp3 par exemple, et enfin d'assigner au pointeur MediaObject (ou autre) l'adresse du fichier chargé dans la RAM.
La seule question que je me pose c'est : est-ce réalisable/logique/pas suicidaire de faire pointer un pointeur vers un objet crée par un programme externe inconnu (qui ne communique par avec mon égaliseur Qt) ?
Et aussi j'ai vu que Qt disposait d'une classe QSharedMemory et QSharedPointer.
En vous remerciant d'avance.
Cordialement, Gizmo.
PS : désolé d'avoir mis en "résolu" je me suis un peu précipité.
Vous n'avez pas à rechercher dans la RAM, car déjà, il n'y a aucun moyen fiable de trouver des données et que en plus, cette RAM n'est pas à vous. Lorsque vous avez un programme, vous avez un espace mémoire réservé à vous, soit. Si vous en sortez, le système devient méchant et tue votre programme (erreur de segmentation).
Donc voilà.
Avec ma méthode, vous aurez les données qui passe par le pipeline de rendu du son, donc, un buffer avec les données brute (RAW). C'est ce que vous souhaitez au final, sauf que tout cela est protégé :P
Bonjour,
En passant par l'api directx ou gstreamer c'est encore plus simple non ?Citation:
Envoyé par LittleWhite
Vu que l'api windows n'est pas si simple à prendre en main et au vu de la chose compliquée que je veux faire mieux vaut que j'emprunte ce chemin peut-être moins "boueux" que l'autre.
Je ne sais pas. Tout ce que je sais c'est que je ne sais pas, mais ça au moins j'le sais.
Bonne journée à vous.
Cordialement, Gizmo.