J'ajouterai qu'xwax tourne comme un chef sur ma toute petite config, en l'occurence un eeepc, et s'interface bien avec JACK.
Ca peut aussi être une différence entre Xwax et Digital-Scratch : pour ne pas risquer un crash lié à une allocation mémoire lors de la décompression par buffer des mp3 ou tout bêtement à un memory leak, j'ai décidé d'allouer statiquement la mémoire pour les 2 lecteurs qui ont une représentation non compressé du titre audio. En clair, quand on démarre, le logiciel utilise directement plusieurs centaines de mega de ram (350 environ), mais cela n'évolue plus par la suite. Ca peut être un chiffre trop élevé pour les petites configs, mais sur une machine avec 2go de ram ça tourne bien.
Comme la récurrence d'analyse du timecode est dépendante du buffer que l'on configure dans JACK, c'est ce paramètre qui influe le plus sur la lourdeur du logiciel. Mais c'est important d'utiliser un buffer assez petit pour avoir une latence correcte, il faut donc trouver le bon compromis : chez moi 256 échantillons par buffer est une valeur qui marche très bien.
Ce qu'il lui manque, c'est surtout de fonctionner out-of-the-box, y'a encore trop à mettre les mains dedans pour que ca fasse pro.
Je ne sais pas si Digital-Scratch s’appréhende plus facilement, mais le fait de configurer correctement la carte son ajoute toujours un peu de complexité pour ce type de logiciel. Ceci dit c'est un passage obligé quand on fait de la MAO. J'ai fait un petit topo sur le wiki qui explique le premier démarrage de Digital-Scratch sur une Ubuntu (kernel low latency, config de Jack, etc...). Si ça ne marche pas, ne pas hésitez à me poser des questions sur la mailing list, c'est comme ça qu'il pourra évoluer pour fonctionner out-of-the-box.
[^] # Re: mixxx
Posté par Julien Rosener . En réponse au journal Digital-Scratch : un lecteur audio pour DJ piloté par platine vinyle. Évalué à 1.
Ca peut aussi être une différence entre Xwax et Digital-Scratch : pour ne pas risquer un crash lié à une allocation mémoire lors de la décompression par buffer des mp3 ou tout bêtement à un memory leak, j'ai décidé d'allouer statiquement la mémoire pour les 2 lecteurs qui ont une représentation non compressé du titre audio. En clair, quand on démarre, le logiciel utilise directement plusieurs centaines de mega de ram (350 environ), mais cela n'évolue plus par la suite. Ca peut être un chiffre trop élevé pour les petites configs, mais sur une machine avec 2go de ram ça tourne bien.
Comme la récurrence d'analyse du timecode est dépendante du buffer que l'on configure dans JACK, c'est ce paramètre qui influe le plus sur la lourdeur du logiciel. Mais c'est important d'utiliser un buffer assez petit pour avoir une latence correcte, il faut donc trouver le bon compromis : chez moi 256 échantillons par buffer est une valeur qui marche très bien.
Je ne sais pas si Digital-Scratch s’appréhende plus facilement, mais le fait de configurer correctement la carte son ajoute toujours un peu de complexité pour ce type de logiciel. Ceci dit c'est un passage obligé quand on fait de la MAO. J'ai fait un petit topo sur le wiki qui explique le premier démarrage de Digital-Scratch sur une Ubuntu (kernel low latency, config de Jack, etc...). Si ça ne marche pas, ne pas hésitez à me poser des questions sur la mailing list, c'est comme ça qu'il pourra évoluer pour fonctionner out-of-the-box.