Et si l’on rajoutait du FIR au DSPiy ?

[thierryvalk]

Je pense que c'est temporaire, pas de stock chez DIGIKEY, mais devraient rentrer semaine prochaine.
Je présume qu'il en serra de même chez les autres fournisseurs.
Noël c'est dans un mois.

[thierryvalk]

J’ai un peu avancé et j’arrive à faire transiter un signal I2S par la BBB.
Ce qui aurait dû être simple, mais m’a pris un bon paquet d’heures.

Etape suivante, étudier NEON et voir pour implémenter le filtrage FIR.
J’ai trouvé une doc que je n’ai parcouru qu’en diagonale. http://www.arm.com/files/pdf/neon_support_in_the_arm_compiler.pdf
Il y a un exemple de routine FIR en page 14, mais il me semble qu’elle utilise des samples et coef. en 16bits seulement.

Pour le nombre de canaux disponibles il faut bien regarder s’il n’y a pas de conflits avec d’autres matériels sur la carte.
Les tableaux suivants donnent les signaux disponibles, on y voit les différents Mode qui sont assignables à chaque PIN.
http://elinux.org/Beagleboard:Cape_Expansion_Headers
Une ligne data I2S s’appelle mcaspX_axrY x=0 ou 1 selon l’unité et Y le sérialiseur. Chaque unité utilisée demande au minimum un signal fsx et aclk.
Bien sûr avec le mode TDM on peut faire passer plus que 2 canaux sur une ligne data.

Apparemment on peut aussi générer du SPdif sur une ligne data. Il faudrait juste rajouter un buffer de sortie et un transfo.

[tcli]

J’ai un peu avancé et j’arrive à faire transiter un signal I2S par la BBB.
Ce qui aurait dû être simple, mais m’a pris un bon paquet d’heures.

m’étonne pas. C'est toujours le plus long.

Etape suivante, étudier NEON et voir pour implémenter le filtrage FIR.

T'embête pas trop.
Ecris déjà une convolution simple et laisse le compilo faire le boulo.
Je ne sais pas quel compilo tu utilises. Mais gcc sait produire du code NEON.
Après tu pourras toujours arranger ton code source pour aider le compilo, voir passer en assembleur, mais ca m’étonnerait beaucoup qu'il faille aller jusque là.
De toute façon, si tu veux aller vite, il faut faire une convolution via FFT. Plus compliqué, mais pas terrible non plus.
Une petite lib comme http://kissfft.sourceforge.net/ devrait aider et il en existe des optimisés pour NEON.

Pour le nombre de canaux disponibles il faut bien regarder s’il n’y a pas de conflits avec d’autres matériels sur la carte.

Ca ne reste pas clair pour moi :
y a t il moyen de sortir 2 signaux I2S ? (soit 4 canaux) ?
SI tu pouvais me le confirmer (ou m'infirmer), ça m'aiderait.
Si c'est oui, il y a des chances que je me lance.

[thierryvalk]

Je ne sais pas quel compilo tu utilises. Mais gcc sait produire du code NEON.

C’est le compilateur de TI par défaut, mai en alternative il y GNU v4.7.3

Ca ne reste pas clair pour moi :
y a t il moyen de sortir 2 signaux I2S ? (soit 4 canaux) ?
SI tu pouvais me le confirmer (ou m'infirmer), ça m'aiderait.
Si c'est oui, il y a des chances que je me lance.

Je pense que oui, en mode synchrone aves donc les mêmes horloges et vitesse ça doit être simple.
Je testerais pour être certain.
Tu comptes rentrer comment aussi en I2S ?
Et ton I2S serait en Master (donc avec clocks générées par la BBB) ou en Slave (avec des clocks externes).
Car là il y a une petit incertitude quant aux fréquences qu’il est possible de générer.

Bien sûr je te donnerais le code source, mais je compte travailler en polling ce qui sera un handicap sous Linux. J’ai aussi une version en DMA qui fonctionne, mais c’est juste une adaptation d’un exemple et je n’ai pas trop envoie de trop me lancer dans le DMA.

Pour plus d’infos et les plus claires selon moi, la meilleure doc est le Technical Reference Manual du AM335X.
Il y a juste le mux des entrées qui lui est dépendant de la carte.

[tcli]

Tu comptes rentrer comment aussi en I2S ?
Et ton I2S serait en Master (donc avec clocks générées par la BBB) ou en Slave (avec des clocks externes).
Car là il y a une petit incertitude quant aux fréquences qu’il est possible de générer.

Pour l'instant, je me renseigne seulement, donc rien est défini et je ne suis même pas sur d'avoir vraiment envie de me lancer, mais l'idée c'est un BBB , suivit d'un ES9018 en multi canaux ou de 2 ES9023. Donc a priori pas de MCLK a générer.
Pour l'entrée, j'en sais rien : il me faudra de l'analogique. (j'ai un ADC qui sort en S/PDIF , on doit pouvoir récupérer l'I2S) et aussi du numérique S/PDIF ou USB .
De tout ce que j'ai pu lire , pour l'instant, la BBB et l'I2S en Linux c'est pas simple ...
Y a pas vraiment les drivers ALSA (sauf pour l'I2S vers le chip HDMI)

[thierryvalk]

Pour la MCLK c’est une bonne nouvelle, toujours ça en moins.
Restent deux clocks : le bit CLK et frame CLK qui en I2S fait la différence entre L et R.
Si ton ADC est Master il sort ces 2 CLK et donc le BBB est Slave.
Vu le circuit SPdif de ton DAC ils existent.
BBB sait générer ces CLK, mais vu qu’il fonctionne avec un oscillateur de 24MHz a la base je ne suis pas certain qu’il sache générer du 48 ou 96K qui sont issus de divisions de cet oscillateur.
Le DSPiy par exemple tourne avec 24.576MHz.

extait de la config d'un connecteur :

bbb pin.JPG (38.78 Kio) Vu 677 fois

Pour le moment j’utilise les PIN comme pour la carte d’extension existante pour la BBB.
PIN 31 en Mode0 on a le signal mcasp0_aclkx, ce signal est en Mode0 donc connecté par défaut, il suffit de l’activer. X veut dire sortie, mais l’on configure+- comme on le souhaite les PIN au niveau du MCASP. Et donc on la configure comme entrée pour faire de la BBB du salve.
Idem pour la PIN 29.
En PIN28 on a mcasp0_axr2 qui elle se trouve en Mode2, il faudra configurer le multiplexeur pour assigner à mcasp0_ahclr qui est le mode par défaut le mode2 actif pour que mcaps0_axr2 soit connectée a la PIN28. Il s’agit d’un serialiseur et vu qu’il est connecté sur la carte à la sortie son HDMI on la configure en sortie.
On fait de même pour la PIN25 mais configurée en entrée pour recevoir le signal de l’ADC.
On aurait pu aussi utiliser la PIN27 qui a la même fonction en Mode2.
Pour une deuxième sortie data I2S, il y la PIN30, mcasp0_axr0 que l’on pourrait sans doute utiliser.
En très bas niveau il faut 2 opérations pour ces configurations, par contre sous Linux apparemment une seule suffit.
On retrouve aussi ces signaux sur l’autre connecteur, principalement en Mode3. Si l’on désire utiliser l’une d’elle on doit « commuter » une ligne LCD et donc dans ce cas plus de vidéo en HDMI.
Et sous Linux il faudra sans doute voir pour ne pas avoir de conflit.
Tout cela est très souple, un peu trop même on s’y perd vite. Mais je pense qu’il relativement facile de modifier un driver Alsa.
Le tout est de voir coté Hardware pour ne connecter 2 sorties ensemble.

C’est vrai qu’il a très peu d’infos sur les possibilités audio de ce genre de carte, somme nous trop vieux Thierry ?

[tcli]

C’est vrai qu’il a très peu d’infos sur les possibilités audio de ce genre de carte, somme nous trop vieux Thierry ?

C'est une possibilité.
Une autre est que avec ces cartes par chères et puissantes, la doc n'est pas au niveau de la complexité du bazar.
L'info est dans les forum , il faut juste trier.
De plus la BBB est très récente, donc tout n'est pas forcement dispo du point de vue soft.

[Tazz28]

Le TI dispose de PLLs dédiée/utilisables pour le McASP normalement permettant de générer des clocks exactes et non des multiples/diviseurs entiers de l’oscillateur principal. C'est ce qui fait que c'est un Soc "haut de gamme" par rapport à beaucoup d'autres apparent concurrents.
Les derniers drivers Asoc pour le McASP sont en cours d'intégration dans les kernels Linux actuels (futur 3.13 et 3.14). Et on est très prêt d'un kernel mainline (non patché) 100% fonctionnel en device-tree sur BBB. Mais c'est pas encore du tout cuit.

[tcli]

Les derniers drivers Asoc pour le McASP sont en cours d'intégration dans les kernels Linux actuels (futur 3.13 et 3.14). Et on est très prêt d'un kernel mainline (non patché) 100% fonctionnel en device-tree sur BBB. Mais c'est pas encore du tout cuit.

Ce ce que je disais, la peinture n'est pas tout à fait sèche ..
Aurais tu un lien vers les dev en cours dans ce domaine ?

[Tazz28]

les mailling list linux-kernel , linux-arm-kernel et alsa-devel

[thierryvalk]

J’ai testé de sortir sur 2 lignes data de l’I2S.
Sortir sur l’un ou sur l’autre fonctionne, mais pas les 2 ne même temps.
Mais je pense avoir un très gros souci de vitesse d’exécution, soit un problème de configuration ou avec la sonde JTAG.
Mais suis donc certain à 99% que l’on peut sortir deux I2S synchrones et entrer un I2S au grand minimum.

Pour les driver Linux, la BBB n’est qu’une évolution de la BB White, processeur plus rapide et mémoire. Je pense que pour le reste tout est similaire.

Pour les docs, cela devient une habitude, un petit morceau par ci et un autre par là et avec les erreurs en prime.
Je suis retombé sur un livre qui fut ma bible pendant des années :

_MG_6647.jpg (99.49 Kio) Vu 626 fois

J’ai toujours été fasciné par l’illustration de la couverture, une idée futuriste de ce que pourraient amener les microcontrôleurs. (1989)

[thierryvalk]

En activant le cache sa tourne un peu plus vite et permet bien de gérer les 2 sorties I2S.

[mtf]

Bravo

[tcli]

:-? les mailling list linux-kernel , linux-arm-kernel et alsa-devel

Ok, merci
D'apres ce que j'ai vu , il y a le code pour une I2S et multi channel en TDM (ci j'ai bien compris en lisant rapidement le code ) :
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/soc/davinci
C'est un bon début .

[thierryvalk]

L'I2S c'est du TDM mais limité à 2 canaux (slots) et avec une syncro frame sur un canal à la place d'un bit.