Une sortie audio du séquenceur pour chacun des signaux à spatialiser?

[belangeo]

Salut,

Suite aux discussions avec Robert et David, je réfléchi au sujet de rendre l'échange d'échantillons audio entre le séquenceur et le spatialiseur transparent (éliminer jack de l'équation). Juste pour être certain que je comprend bien la routine, voici un cas de figure: Si on a 2 pistes octo dans une séquence où chacun des 16 canaux doit être spatialiser selon des trajectoires différentes, on doit utiliser 16 sorties audio pour connecter les signaux entre le daw et le spatialiseur, vrai? Et on aura 2 plugins, un par piste, chaque plugin gère les trajectoires des canaux sur sa piste?

Si ma compréhension est bonne, 8 pistes octo requièrent 64 canaux de sorties?

Mon point ici est que ce procédé, d'une part, nécéssite un driver audio qui permet la gestion de tous ces canaux (beaucoup plus nombreux que les sorties réelles au final) et qu'un driver audio, par définition, doit être visible et accessible pour le système.

Pour rendre transparente la communication audio entre les deux parties (plugin et spatialiseur), il faudrait éliminer la nécéssité d'un driver audio et faire en sorte que le plugin achemine lui-même les signaux à spatialiser (avec une addresse permettant de le lier à sa trajectoire) au spatialiseur via la mémoire partagée du système (c'est ce que je fais dans pyo pour passer de l'audio entre différents processus dans un contexte multi-coeur). De cette façon, on élimine l'intermédiaire et le plugin parle directement au spatialiseur...

Ai-je manqué quelque chose? Commentaires?

[Normandeau]

Je pense que ta description est assez précise. Actuellement, il faut juste faire la distinction entre les deux modes de fonctionnement principaux de SpatGRIS: Audio ou OSC. Audio Les pistes audio sont spatialisées par SpatGRIS et envoyées directement à l'interface audio. Si on travaille en octophonie (c'était le mandat premier de Octogris), il n'y a que 8 sorties à gérer. La limite du nombre de canaux par piste est déterminée par les séquenceurs: la plupart sont limités à 8 sorties par pistes; sauf Reaper: à 64 (et en fait DP à 12). Le nombre total de sources audio à spatialiser est ici déterminé par le CPU. Par exemple, la version 2X8 (2 sourcesX8 sorties) semble demander pas mal moins de jus que la version 8X8. Mais en réalité, quatre versions 2X8 demandent la même quantité de CPU qu'une seule version 8X8. Je viens de faire le test dans DP: 7X(8X8)=56 canaux (maximum possible actuellement sur mon Mac) =± 28X(2X8)=56 canaux. Pour être très précis, en fait c'est plutôt 26X(2X8). Donc la somme de canaux possibles en 2X8 est moindre qu'en 8X8. Mais cela devrait être amélioré dans une nouvelle version, bientôt disponible chez votre fournisseur préféré! OSC Ici c'est différent, car SpatGRIS ne gère pas la spatialisation, donc l'audio est envoyé au Zirkonium via Jack (ou Soundflower). Je n'ai pas testé les valeurs maximales, mais j'ai une session DP avec 64 pistes octophoniques qui jouent sans problèmes (dans DP9.12). L'insertion de SpatGRIS en mode OSC ne semble pas ajouter de CPU de façon notable. Cependant le nombre maximum de canaux possibles avec le Zirkonium est de 64 pour le moment (ou 8X8 par exemple).

[belangeo]

Je viens de faire des tests avec la mémoire partagée. J'ai partagé 256 signaux audio entre deux processus pyo indépendants pour à peine 5% de CPU sur mon modeste Thinkpad, sans un glitch. Ce n'est pas exactement le même contexte mais ça me semble une solution prometteuse pour retirer Jack et Soundflower de l'équation...

[vberthiaume]

Je dois dire que je n'étais pas familier avec le concept de mémoire partagée, mais @theRedMercury m'a expliqué ce que c'était et on en a discuté un peu. Je vois plusieurs problèmes potentiels avec cette approche:

1. Si on envoit directement les sorties du plugin ailleurs, il va falloir se retaper le mixage que le séquenceur se tape de toute façon (ie, avec ton exemple de 8 pistes octo, passer de 64 sorties de plugins à 8 sorties réelles).
2. On va aussi perdre toutes les fonctionnalités de mixage du séquenceur. Les sliders, boutons mute, solo, tous les plugins suivant spatgris, seront ignorés.
3. Et finalement, comme l'a si bien dit Nicolas, il va être difficile de faire mieux que jack, qui utilise du lock-free programming pour passer les buffers entre les clients, mais assez facile de faire pire :). Le seul problème qu'on a avec jack pour l'instant est la gestion dynamique de clients, ce qui ne devrait pas être compliqué à gérer en utilisant un wrapper.

[belangeo]

Salut Vincent,

1. Mon exemple impliquait justement qu'il y avait 64 canaux (8x8) à spatialiser indépendamment. Ce qui implique justement que le daw envoit 64 pistes. Si je comprend bien, c'est donc le zirkonium qui fait le mix de tous les canaux (mono) spatialisés en mutli.

2. Là, par contre, ça tue! J'avais pas pensé qu'il y avait du processing "après" le plugin...

3. C'est sur que jack est bien foutu! Est-ce qu'on ferait mieux ou pire... Sais pas! Mon système aussi est lock-free, tant qu'il n'y a qu'un seul processus qui écrit dans la mémoire, il n'y a pas lieu de protéger l'accès en écriture. Un test rapide sur ma machine ne donne pas de différence de CPU notable entre 250 signaux en mémoire partagée et 250 ports dans jack.

Mais bon, ton point 2 semble clore la discussion... Mon idée reposait justement sur le fait que le signal ne dépasse pas le plugin dans la chaîne de processing du daw!

[vberthiaume]

Salut Oliver,

Malade que tu as implémenté un système lock-free... wow! Mais ouais, c'est assez critique, je pense de pouvoir utiliser le processing post-plugin...