Et si l’on rajoutait du FIR au DSPiy ?

[alkasar]

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!!!!

Ne te fie pas à la gauche et la droite, notions fluctuantes selon le sens dans lequel tu tiens la carte
La pin 1 des connecteurs est marquée sur le pcb en principe. C'est celle avec une pastille carrée. Les autres pastilles sont rondes.

[maxidcx]

Je remonte ce fil, et je partage les meme idée qu'Alkasar;

l'idée d'utiliser une carte BBB en tant que plateforme de pilotage d'un pre-amp avec cross over et FIR intégrée est assez séduisante.

en jetant un oeil sur le driver ASoC (ALSA) dans le kernel linux/davinci qui est fournit par TI, on voit que tout ce qui est DMA - I2S est déjà parfaitement au point (jusqu'à 96khz...). Il est possible de modifier tout cela pour ajouter des "codec" qui pourrait supporter un chip SigmaDSP en aval. Par contre si on veux faire du multicanal, genre 6 pour du 5.1, ou idéalement 8 pour le 7.1 ca se complique car il faut soit tout passer en TDM, ce qui reduit la frequence d'echantillonage, soit utiliser plusieur "serialiser" mais dans ce cas il faut reconfigurer tout le DMA pour pouvoir gerer plusieurs flux audio simultanement... y a une paires d'heure à passer.

si on reste en stereo, ca devient hyper cool. on balance le SPI1 vers une entrée du DSP, on le controle en I2C pour mettre à jour les coefs biquads IIR, et on peux envisager d'implementer une routine FIR quelque part à l'inetrerieur du codec Alsa, par exemple dans le fichier qui gere le DMA ou le PCM. Une sorte de verrue qui intercepte le sample et le passe à la moulinete avant de le mettre dans le buffer prevu à l'origine.

D'après ce que j'ai vu , le codec peux travailler sans soucis en I2S slave donc on peut avoir la master clock coté DSP ou DAC.

avec l'environement intégré Cloud 9 IDE, il est super simple de mettre le code JavaScript sur la carte et donc on peux repartir de l'application jEQ de tcli et se faire un truc pas mal.
par contre, il faudrait revoir l'appli du sigmaDSP pour permettre une allocation dynamique des biquad par voies (multiplexers...) pour eviter d'avoir trop d'applications.

pendant ces 12 derniers mois on a beneficié du leadership de thierryvalk et quelque part on s'est laissé aller à prendre tout cru ce qui tombait, faut peut être se reprendre en main, avec un vrai travail d'équipe ou chacun apporte une contribution concrète?

je vois sur mouser que les cartes BBB vont etre en stock dans les jours qui vienne puisqu'ils on un arrivage de 3000+ prevu fin fevrier. à 36€ht, je me lance, on verra bien! y a til des volontaires pour creuser ce truc ?

[tcli]

Je remonte ce fil, et je partage les meme idée qu'Alkasar;
l'idée d'utiliser une carte BBB en tant que plateforme de pilotage d'un pre-amp avec cross over et FIR intégrée est assez séduisante.

Si vous arrivez a trouver une BBB quelque part ...
Tous les sites sont en rupture depuis plusieurs mois.

[maxidcx]

normalement il y en a 3940 qui arrivent chez mouser:
http://www.mouser.fr/search/include/aoo ... B-BBLK-000

[Pacapona]

M'y connait plus sur Linux qu'en éléctronique, pt-être que je peux être utile... Je vais suivre ce file attentivement.

[maxidcx]

bienvenu
tu saurais recompiler le kernel linux d'une BBB, avec modif du device tree et des codec asla ?

pour simplifier
si on part du principe que le DSPIY est bon pour faire des IIR et que ces 3 DACs sont satisfaisants, alors la question c'est est ce que ca pourrait avoir un interret d'utiliser un BBB en front end, qui envoie le I2S et le I2C au SigmaDSP, et qui en profite pour faire une convolution stereo en amont, entre la reception upnp/dlna/airplay, et la sortie McBSP I2S.
avec la possibilité d'embarquer une application en JS, moins fermée que dsstudio et son LPC avec firmware de telechargement des parametres SigmaDSP. et si on arrive à faire cela, combien de taps FIR peut on faire à 96k sur un signal stereo..?
y a til un interret a utiliser les PRU qui contiennent quand meme 2 procs 32bits 200mhz...? pas sur.

[Pacapona]

Bon vous êtes plus dans le Diy du dimanche avec vos projets vous...

A mon sens je trouve la direction de l'idée D'Alkasar excellente, rien de tel qu'un proco spécifique dédié pour le traitement du signal audio, Linux est pas top pour ça...

Que la BBB serve de frontend à la modife du firmware et de source supplémentaire me parait réaliste et géniale...
Ensuite aiplay n'est qu'un détail là au milieu, c'est juste un service à utiliser ou non. Perso j'y associerais le mini serveur de son mpd, du coup le tout deviens paramétrable depuis sa tablette au salon; Choix de la music, playlists, visu des pochettes et avec accès/modifs des filtres, choix des entrées... LA Jukebox parfaite...

J'ai déjà compiler pas mal de Kernel patchés sur différentes architectures... Mais modifier alsa? est-ce bien nécessaire? Maintenir ce genre de modifs me parait difficile sur le long terme...

Faudrait 2-3 Tazz + 2-3 maxidcx + 2-3 Alkasar et autre pour ce projet... Faut vous lire les gars...

[Pacapona]

Bon je sens qu'il y en a qui vont pas m'aimer mais...

Y en a un qui pourrait m'expliquer pourquoi vous tenez tant au 96khz? Je vois pas ce que ça apporte dans les fréquence audibles... Le 48khz n'a pas un seul "bit d'information" en moins dans la gamme des fréquences audibles... Disons même que le 96khz est bien plus susceptible d'amener du bruit voir même des "sons parasites" parfaitement audible si toute la chaine ne suis pas.
A moins d'avoir des super pouvoir je vois pas...

[alkasar]

Bon je sens qu'il y en a qui vont pas m'aimer mais...

Y en a un qui pourrait m'expliquer pourquoi vous tenez tant au 96khz? Je vois pas ce que ça apporte dans les fréquence audibles... Le 48khz n'a pas un seul "bit d'information" en moins dans la gamme des fréquences audibles... Disons même que le 96khz est bien plus susceptible d'amener du bruit voir même des "sons parasites" parfaitement audible si toute la chaine ne suis pas.
A moins d'avoir des super pouvoir je vois pas...

96k c'est la fréq d'échantillonage, pas la bande passante. Sur-échantillonner améliore la précision.
Philby avait montré des images explicites il y a quelques temps faut que je mette la main dessus.

[Pacapona]

Tu veux dire qu'une information à 96k va améliorer la précision à 48k...? J'avoue que ça me plairait bien de voire les images dont tu parles, car mes notions doivent être incomplètes.

Petit exercice intellectuelle de transposition à un écran avec ces pixels, plus de pixels plus d'infos... ok mais.

Imaginons que du 96k corresponde à une dalle de 2550x1440, le 48k à une de 1280x800, que chaque dalle possède le même nombre de pixel par pouce(24bit). Dans cette "image" le 96k afficherait une dalle plus grande que celle du 48k, mais la précision des pixels elle, reste là-même... Donc si mon regard ne couvre que du 1000x600 pixel (fréquence audible -20000hz) je verrais exactement la même chose sur chaque dalle.

[alkasar]

l'analogie avec les pixels c'est du binaire tout le long donc pas sur qu'elle convienne.
Si tu veux une analogie avec de l'image, imagine plutot un scanner. Plus la résolution du scanner est élevée plus l'image scannée sera fidèle à l'original.

Sur-échantilloner a un intéret quand tu convertis d'analogique en digital et inversement. Plus on échantillonne fin, plus on gagne en précision et il y a des limites évidemment.
Même lors du traitement purement numérique, il y a un intérêt a sur-échantillonner aussi. Mais c'est plus subtil. Tazz s'était lancé dans une grande explication la dessus et j'ai pas tout suivi et mes cours de traitement du signal sont loin, loin, loin

les images de Philby pour comparer l'échantillonnage a 48, 96 et 192k sont là :
post177349306.html#p177349306

[Pacapona]

Merci pour le lien! Mais je suis toujours pas convaincu, dans son image les points qui représentent les échantillons représente plus les bits à mon sens, je sais "testa dura"...

L'analogie avec le scanner, elle se déroule à l'enregistrement... Donc si mon scanner à plus de résolution c'est comme si j’enregistrai en 16 ou 24 bits. Si je mets du 48k dans du 24 bits sur que la résolution sera meilleur qu'a 16... Mais si je mets du 96k dans du 24 bits, comparativement j'ai le même nombre de bits à disposition pour coder chaque résolution, et là je vois pas en quoi le 96 serait plus précis (dans le registre du 48k) que le 48k qui lui a plus de bit à disposition pour moins de fréquences à encoder, mon avis est que du 48k enregistré à 24bits est plus précis que du 96k enregistré à 24 aussi.

[Pacapona]

Pour transposer à la photos;

L’objectife photos, grand angle ou téléobjectif représente les "k" ;
grand angle=96k (grand spectre/image grande, large)
téléobjectif=48k (moins de fréquence/ qu'une portion de cette image)

La résolution les bits;
16 millions de pixel = 16bits
24 millions de pixel = 24bits

Si au finale je ne m'intéresse qu'a une portion de cette grande image, vaut mieux que je la photographie avec un téléobjectif et 24 millions de pixels, plutôt qu'avec un grand angle qui me demanderait de recadrer la photos pour retrouver la même seine...

Ouais ok je vais voir ailleurs si j'y suis...

[alkasar]

on est plutot HS là...

Merci pour le lien! Mais je suis toujours pas convaincu, dans son image les points qui représentent les échantillons représente plus les bits à mon sens, je sais "testa dura"...

L'analogie avec le scanner, elle se déroule à l'enregistrement... Donc si mon scanner à plus de résolution c'est comme si j’enregistrai en 16 ou 24 bits. Si je mets du 48k dans du 24 bits sur que la résolution sera meilleur qu'a 16... Mais si je mets du 96k dans du 24 bits, comparativement j'ai le même nombre de bits à disposition pour coder chaque résolution, et là je vois pas en quoi le 96 serait plus précis (dans le registre du 48k) que le 48k qui lui a plus de bit à disposition pour moins de fréquences à encoder, mon avis est que du 48k enregistré à 24bits est plus précis que du 96k enregistré à 24 aussi.

je savais en l'écrivant que l'analogie était moyenne et ca n'a pas loupé !
Allons plus loin : pour un scanner il y a bien les deux dimensions : profondeur de bits et résolution. L'un va déterminer le nb de pixels et l'autre le nb de couleurs reconnues.
En audio aussi on a les deux dimensions: dynamique et bande passante. Tout ça c'est la faute a Shannon et son théorème !

mon avis est que du 48k enregistré à 24bits est plus précis que du 96k enregistré à 24

non, 24/96 sera plus précis*. mais il y a un coût : un fichier 24/96 est 2x plus gros qu'un fichier en 24/48. Ou, si c'est du streaming, on a deux fois moins de temps pour le traiter.

* il y a débat pour savoir si le gain de précision est utile ou pas et s'il est audible ou pas.

[Pacapona]

Oui le fichier sera 2 fois plus grand, car il contient toute une gamme d'information qu'il m'est impossible d'entendre. Preuve en est que dans le fichier finale, le nbr de bits utilisé à encoder l'information à 48k est la même dans les 2 fichiers...

Non ok c'est sur je vais voir ailleurs...