Et si l’on rajoutait du FIR au DSPiy ?

[Tazz28]

Le driver i2s c'est pour l'IP ASP des anciens davinci. Là faut utiliser le driver McASP qui est interfacé avec la couche ALSA au travers de davinci-pcm.
La "déclaration" de ce que l'on colle derrière les ports du McASP reviens à écrire un drivers ASOC. Un exemple est dans davinci-evm qui interface la chose avec le codec présent sur une carte d'éval.
Comme je l'ai déjà évoqué ailleurs, ça reviens ici a définir un driver minimaliste qui décrit la conf statique que l'on veut en sortie des ports i2s/tdm.
Pour pas tâtonner, faut partir des sources d'un kernel d'une distrib pour BBB. Vérifier que l'initialisation "platform data" ou "device tree" suivant la modernité des sources en question configure le µP dans la conf I/O voulue pour les pinoches intéressantes et au besoins ajuster. Et faire ce driver ultra minimaliste.
Le lien sur les sources git de Linus reflète ce qui est actuellement intégré. La convertion full dma-engine, device tree conf I/O (layer GPIO) device tree mcasp et j'en passe n'est pas encore intégré. Les patch en dev actuels et les liens vers les repos git correspondant se trouvent dans les mailling list. Mais avec une arbo pour BBB récente, on doit pouvoir déjà bien exploiter le truc sans que ce soit non plus trop compliqué.
Avec la full gestion du DMA et des fifos du McASP, c'est fait pour tenir les plein débits sur tous les canaux simultanés.

[Dagda]

En te lisant Tazz, j'ai l'impression de regarder "BFM Business"

[Tazz28]

désolé

[alkasar]

sois pas désolé... du moment que ceux qui doivent comprendre comprennent, nous les autres on se cultive

TTT se préparent. BBB n'a qu'a bien se tenir

[Kro]

En te lisant Tazz, j'ai l'impression de regarder "BFM Business"

[thierryvalk]

J’ai un peu joué avec une application toute simple qui fait clignoter une LED.
On écrit sur une GPIO et l’on fait une boucle de comptage qui ne fait rien pour générer du délai.
Je trouvais que la valeur de ce compteur était relativement faible.
L’application étant simplement en RAM j’ai activé les caches pour qu’elle soit directement dans le processeur. Et là oui, grande différence ma séquence tourne 52x plus vite.
Tout en sachant que l’accès à la GPIO dure normalement le même temps quel que soit le mode et que le cœur processeur est en mode normal, il existe un mode turbo en augmentant la tension du cœur et sa vitesse. D’un autre coté je suis en mode debug, peut être que l’émulateur ralenti l’exécution en RAM.
Je ne sais pas comment le cache se gère sous Linux, mais me semble primordial. Il faut aussi voir niveau taille, peut être que le Celeron fait mieux.
Par contre j’ai un gros problème, lorsque je lance une appli en cache ma sonde JTAG plante.
Je vais tout reprendre depuis le début car j’ai aussi un doute sur la gestion du NEON avec le compilateur TI et vais donc essayer de passer directement sous gcc.

[thierryvalk]

Je ne compte pas persévérer dans cette voie.
Prend trop de temps et le résultat est incertain et en plus je n’en ai pas vraiment besoin du FIR.

J’ai commencé à étudier Linux, mais ce sera pour d’autres applications, en dehors de l’audio.

[maxidcx]

uhm uhm, de mon coté je viens de commander 2 exemplaire du nouveau Teensy3.1 (just released) qui est un cortex M4 à 150mhz(2xoverclok) avec un seul I2S , plein de ram et de flash.

le projet/idée : recevoir de l'i2s, le bufferiser genre fifo et le renvoyer vers 2 (voire 4 ou 6) dac 24bits R2R (pcm1704) avec un filtrage type IIR et FIR.
sachant que l'instruction SMLAL et UMLAL font MAC (32x32+64 -> 64) en 1 cycle, on peux faire environ 700 instructions à 96khz avec calcul en double precision. pour l'instant je vois ce module en complement d'un dispiy (car il me manque un DAC), et selon la qalité des 2 ADC 16bits, j'envisage une correction/feedback dynamique, mais bon c'est juste du brainstorming

[tcli]

uhm uhm, de mon coté je viens de commander 2 exemplaire du nouveau Teensy3.1 (just released) qui est un cortex M4 à 150mhz(2xoverclok) avec un seul I2S , plein de ram et de flash.

le projet/idée : recevoir de l'i2s, le bufferiser genre fifo et le renvoyer vers 2 (voire 4 ou 6) dac 24bits R2R (pcm1704) avec un filtrage type IIR et FIR.

Interessant, mais comment as tu prévu de connecter tes nombreux DAC, si il 'n y qu'un I2S ?
C'est ce qui pour l'instant me fait hésiter à acheter une BBB. J'ai pas trop envie d'essuyer les plâtres cotés connections a plusieurs DAC ...

sachant que l'instruction SMLAL et UMLAL font MAC (32x32+64 -> 64) en 1 cycle, on peux faire environ 700 instructions à 96khz avec calcul en double precision.

Parfait pour du IIR, un peu limite pour du FIR (mais tu es sur qu'il fonctionne à 150Mhz ?)

PS: par contre, au niveaux, projets, il réuni une belle bande d'allumés : http://www.pjrc.com/teensy/projects.html

[maxidcx]

il n'y a qu'un seul I2S et c'est pour cela qu'il faut choisir des dac qui vont bien que tu peux cascader. je m'explique:
tu prends 3 PCM1704 par exemple, tu injectes le DATA sur les 3 dac en meme temps, tu injectes le frame_sync (=LRCLK) sur les 3 dac en meme temps. maintenant vient be BCLK : le premier recoit les 25 premiers bits de clock, le second le 49 premiers, et le dernier accepte tout.
CF une petite image que je viens juste de faire.

il suffit de mettre une porte AND entre BCLK et une des pattes du uP qui pourra etre piloté soit en mode "timer compare" soit par un DMA ki va bien avec une synchro sur BCLK et LRCLK of course (bon y a encore des trucs à vérifier bien sur)

avec ce principe, on peux piloter 2 dac à 192khz avec un BCLK = 9.2mhz, ou 4 en 96khz ou 8 en 48khz (la clock prevue = SI570)

[maxidcx]

... pas encore vérifié si Paul à integré l'overclocking pour T3.1 mais c'est "standard" sur T3 qui tourne à 2x48 sans probleme

en fait l'énorme bénéfice d'utiliser un T3 c'est les librairies et la facilité de dévlopement, plug-compile-n-play, pour l'avoir vérifié!

[maxidcx]

je continue un peu sur ce fil pour partager mes progres, meme si il n'y a pas de vrai rapport avec le sujet original

recu recemnet 2 modules teensy3.1 . assez incroyable le travail d'integration fait par Paul.S. pour faire tourner le cortexM4 dans l'ide arduino.

j'ai codé un objet biquad (ordre2 donc) "optimisé" et il faut compter 25 instruction assembleur/CPU au total soit une capacité d'execution de 40 biquads sur une interruption à 96khz. pas trop mal. mais pas mieux qu'un SigmaDSP qui à besoin seulement de 10cycles à 50mhz et qui peux en faire environ une cinquantaine.

struct biquad_s {
int32_t a1,a2,b0,b1,b2;
int32_t xn,xn1,xn2,yn,yn1,yn2;

void calc(int32_t x) {
int64_t acc;
//acc = b0 * x[n] + b1 * x[n-1] + b2 * x[n-2] + a1 * y[n-1] + a2 * y[n-2]
xn2=xn1; xn1=xn; xn=x; yn2=yn1; yn1=yn;
acc = (uint64_t) b0 * xn;
acc += (uint64_t) b1 * xn1;
acc += (uint64_t) b2 * xn2;
acc += (uint64_t) a1 * yn1;
acc += (uint64_t) a2 * yn2;
yn = acc >> 32; };
} ;

et ca donne ca en assembleur

<_ZN8biquad_s4calcEl>:
4d8: b5f0 push {r4, r5, r6, r7, lr}
4da: 6942 ldr r2, [r0, #20]
4dc: 68c7 ldr r7, [r0, #12]
4de: 6986 ldr r6, [r0, #24]
4e0: 6182 str r2, [r0, #24]
4e2: fb82 2307 smull r2, r3, r2, r7
4e6: 6907 ldr r7, [r0, #16]
4e8: 6a05 ldr r5, [r0, #32]
4ea: 61c6 str r6, [r0, #28]
4ec: fbc7 2306 smlal r2, r3, r7, r6
4f0: 6806 ldr r6, [r0, #0]
4f2: 6a44 ldr r4, [r0, #36] ; 0x24
4f4: 6847 ldr r7, [r0, #4]
4f6: 6284 str r4, [r0, #40] ; 0x28
4f8: fbc6 2305 smlal r2, r3, r6, r5
4fc: fbc7 2304 smlal r2, r3, r7, r4
500: 6884 ldr r4, [r0, #8]
502: 6141 str r1, [r0, #20]
504: fbc4 2301 smlal r2, r3, r4, r1
508: 6245 str r5, [r0, #36] ; 0x24
50a: 6203 str r3, [r0, #32]
50c: bdf0 pop {r4, r5, r6, r7, pc}

concernant les DAC, je pars sur 4 x AD1862 (20bits R2R commandés sur la baie), conversion I/V par AOP avec resistance de feedback et pont diviseur pour reglage de volume 0/-10/-20/-30db avec un DG413 dans la boucle de contre reaction.

chaque module (Teensy3 + 4 dac+Aop+volume) sera utilisé en mono, 1 par enceinte. Liaison spdif optique, avec un DSPiy en front end pour l'instant ...
les 2 ADC 16 bits (13 bits en vrai) permetront de lire la FCEM des bobine (Bl) ainsi qu'un capteur acceleration. histoire de faire quelques calculs temps reel sur le deplacement de la membrane et la temperature de la bobine

[maxidcx]

Bonjour,
ll y avait un bon fil de discussion concernant la BBB et les McASP mais d'un seul coup plus rien
ca reste quand meme une bonne option cette carte pour aller plus loin dans les traitement audio.
Aussi le récent "volumio" tourne sur BBB alors l'idée d'un LinuxDSPiy avec fonction Airplay integrée et quelques DAC ES9023 en sorties ca donne envie

[alkasar]

L'idée de sous-traiter des traitements DSP du DSPiy à un SoC est une option. Ca part de l'idée que le DSPiy est le chef et la BBB l'esclave.
Pour l'évolutivité future, je partirai plutot dans l'autre direction : un "co-processeur DSP" pour un SoC. Une sorte de DSPiy dont le µC serait remplacé par un SoC.

Concevoir une carte qui porte un DSP puissant compatible sigmastudio comme le récent ADAU1442A à $15 , les E/S audio spdif+I2S et analogiques , voire un réceveur USB, et bien sur les DACs. Le tout pilotable par I2C et I2S par un SoC comme la BBB par exemple.
On garde la logique du DSPiy : le µC charge dans le DSP les programmes a exécuter (preset). La BBB a suffisamment de GPIO pour tout le reste et gérer des triger, BPs et compagnie.
Le firmware est remplacé par un soft qui tourne sur la BBB.
DSPiyStudio remplacé par une appli web qui tourne directement dans la BBB. Donc mise a jour des paramètres à distance puisque les connexions réseau sont dispo. On peut envisager pilotage & paramétrage par clavier/souris ou par appli web depuis un mobile ou tablette ou même une appli dédiée android.
Avec un player audio intégré à la BBB, on en fait un lecteur audio réseau+préamp+filtrage actif numérique de course.

Sur le papier, c'est faisable. Cette architecture me trotte dans la tete depuis presque un an et en dehors d'écrire les specs, je n'ai pas la compétence pour le faire

et pas d'airplay please!!!! parlons système ouverts. UPnP av suffit et ce doit etre dispo dans linux

[Pacapona]

Oups trompé de toppic... désolé les gars...
parlons système ouverts... dispo dans linux...
Là tu fait plaisir alkasar!!! Projet ambitieux...

J'ai une mini question pour le raccord numérique du multidspiy.
La doc que tu as fournies est très claire, cependant y a une infos que j'arrive pas à trouver, pour le j17 ou j4, tu donne les infos dans quelle ordre?
1 GND
2 LRCK
3 BCK
4 SIN0
5 +3V3
C'est dans quelle sense?
Par exemple, je regarde la carte DinDS en ayant les connecteurs numérique sur le dessus, la prise toslink en-bas à gauche et les picos J5 sur le côté droit, vu sous cette angle les indications ci-dessus 1,2,3,4,5 vont de gauche à droite ou de droite à gauche?

Merci d'avance!!!!