Modérateurs: Staff DIY, Staff Installations, Staff Juridique • Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité

RPI --> DSPiy

Message » 12 Mai 2015 21:54

Ce topic part de là ; (j'ai du désactiver les smiley... pas plus de 15 par poste... :-( )

alkasar a écrit:on pourrait faire un sujet a part RPi avec DSpiy ? pacapona tu t'y colles ?
ca intéresse du monde (cf quelques pages plus haut sur le sujet) et j'ai peur que ces discussions intéressantes soient perdues en page 346 d'un long topic.

pour moi, comme déjà dit plus haut je vois 3 niveaux de cohabitation, de complexité croissante :
1- Rpi comme source. A priori en I2S. Prévoir les cas DSPiy1, Dspy2 avec et sans ADAU1452

2- Rpi est aussi controleur : le Rpi pilote le DSPiy par exemple en envoyant les codes IR dans le trigger_in du dspiy. Dans ce cas, le Rpi devient la tour de controle, on peut utiliser ses interfaces, GPIos, écran tactile,etc. Misu a déjà commencé a réfléchir a la question pour la partie codes IR.

3 - Rpi remplace DStudio. Le must : le Rpi dialogue avec le µC du dspiy (par l'interface série ? I2C ?). On pourrait aller jusqu'à remplacer DStudio par une interface web sur un serveur hébergé sur le Rpi. Le Rpi+DSpiy devient un appareil complètement autonome.



1)
L'idée est d'utiliser l'interface i2s du RPI,
Il y a déjà pas mal de DAC et sortie digitale qui utilise cette interface donc pas de soucis à l'activer, Runeaudio ou sa copie Volumio propose un moyen simplifier d'activer l'i2s… Mais ça peut facilement être activé sur n'importe qu'elle distribution Linux.

Par contre si on veut que RPI sois le slave il vaut mieux partir sur les distributions dédiées à l'audio.

J'utilise MPD depuis des années, ma bibliothèque a 68500 titres, le tout en flac mais y a quelques ogg mp3 aac et dsf qui traîne. Même avec le rpi de première génération la recherche est rapide et il utilise très peu de ressource. J'utilise également sa sortie en streaming, a ce moment là il me convertis à la volée ce que j'écoute, ce qui fait que même loin de chez moi j'ai accès à l’ensemble de ma bibliothèque. MPD utilise directement la carte audio sans intermédiaire… enfin presque il passe par alsa mais en gros il nous sort du bitperfect.

Il peut aussi être utiliser comme sortie pour shairport (aiplay) et pour un serveur audiocast/UPNP, du coup pas de conflit avec la carte son utilisée par plusieurs soft...

Choubidou c'est lancé et il a branché la sortie i2s du RPI sur le DSPiy ;

choubidou a écrit:Alors je me lance

il faut donc récupérer l'image de volumio la https://volumio.org/get-started/

Puis suivre les intruction du lien

En principe a la fin on a volumio qui fonctionne

La dans volumio dans le menu system choisir le driver I2S Hifiberry

C'est fini pour la config
Maintenant connection du Pi sur le DSP

-------Pi GPIO------DSP

DATA----40-------J17(1)
GND-----39-------J17(2)
Clk------12-------J17(3)
Lrck-----35-------J17(5)

Dans le DSP choisir entrée USB-I2S et c'est parti !


Il a utiliser un bout de cordon USB (4 fils + blindage) avec le blindage relie au GND


Par contre le RPI a ces limitations, le seul moyen d'avoir une sortie propre serait de l'utiliser en slave ;


outre le problème de la clock il y l’isolation de l'interface i2s, le DSPiy v2 n'as plus d'isolation intégrée...

De plus l'idéale serait de conserver toute les entrée du DSPiy


Voici un article qui explique le problème de la clock ;
https://hifiduino.wordpress.com/2014/11 ... tal-audio/
réaction ;

thierryvalk a écrit:Cet article est pour un Rpi connecté à un DAC.
Le DSPiy est un peu plus qu'un DAC, le Cs8426 est déjà tolérant, l'ADAU1452 A un réducteur de jitter ainsi que les ES9023.

A mon avis, mais il faudrait vérifier, soit on se paye des plocs ou des mutes, soit sa fonctionne correctement.

Si nécessaire, avec l'ADAU1452 on peut imaginer d'avoir une entrée I2S configurée en Master pour du 48KHz.


Tazz28 a écrit:Le problème est la master clock, pas le jitter.
Soit on passe par un ASRC et on s'en tape, soit master I2S externe comme tu propose, soit driver Rpi qui va bien pour sortir une master clock a peu près correcte sur une GPIO.
Le moins foireux et le plus simple étant donné les possibilité de l'adau est d'utiliser un de ses 8 bloc asrc.



thierryvalk a écrit:Via le CS8426 on passe aussi par un ASRC.



Il parle ensuite d’éventuellement utiliser windows 10… J'ai censuré se passage ;-) :siffle: :siffle: :siffle:


thierryvalk a écrit:Pour la pollution du Rpi vers le DSPiy, faut voir s’il y a des problèmes.
Un isolateur d’I2S peut limiter cette pollution, mais c’est une carte en plus.
Mais qui pourrait se monter sur le Rpi en facilitant la connectique vers le DSPiy.

Envoyer du Master clock au Rpi est possible avec DSPiy V2 mais pas simple d’envoyer du 24MHz dans des fils, c’est plus que risqué.
De toute manière si j’ai bien lu le Rpi ne peut recevoir du master clock.

La perte de l’USB du DSPiy ne peut-elle être compensée par l’USB du Rpi ? (je ne le connais pas)
Avec l’ADAU1452, il est envisageable d’utiliser l’une de ses entrées I2S qui permet (normalement, car pas testé) de faire du master ou Slave.
Et dans ce cas on conserve l’USB du DSPiy.
Mais il faut une appli spéciale.


Pacapona a écrit:J'ai retrouvé un passage ou une personne de hifiberry parle du rpi en slave;

"the Digi doesn’t reclock the signal. The Raspberry Pi is a clock slave to the Digi. That means it does not use its own clock, but the clock from the Digi.
There are no parameters that can be adjusted by external parameters. This would need patching the wm8804 driver and recompiling the kernel.

We did not do specific clock measurements. In general the Digi provides the master clock to the DAC. Even if the clock is completely “wrong”, the DAC should sync onto this clock. Usually a PLL at the input stage of a DAC is used for this."

et un article plutot basique sur la connexion de rpi vers l'adau;
Connecting a Raspberry Pi and an ADAU1701 DSP; http://www.crazy-audio.com/2013/09/raspberry-pi-auda1701-dsp/

Mais si je suis le seul intéressé pas la peine de se prendre la tête...


thierryvalk a écrit:
J'ai pas encore trouvé de carte "prête à l'emploie" afin d'isoler l'i2s. Mais je fouille... Si ça en intéresse quelques-uns je peux ouvrir un poste afin qu'on y collecte les infos/possibilité et futur développement à envisager au branchement en en i2s d'un mini pc... genre le raspberrypi
http://www.pavouk.org/hw/modulardac/en_i2sisolator.html

C’est bien quelque chose du genre, mais pas besoin du DC/DC mais il faudra 2 alims, l’une pour le Rpi et l’autre pour le DSPiy.
Et tant qu’à faire un PCB autant qu’il s’enfiche directement sur le RPi et sorte avec un connecteur pour câble plat.
Et aussi voir s’il ne faut pas l’un ou l’autre composant en plus pour d’autres fonctions.

Pour le moment, on a différents travaux et idées sur le RPi, sur différents fils, faudra à un moment les remettre en commun.

ça ce serait intéressant conservé l'USB du DSPiy et entré directement en I2s sur l’ADAU1452
Moi cette appli m’intéresse

Rentrer en direct sur l’ADAU1452 a des avantages et inconvénients, il faut que je m’y plonge un peu plus pour voir les possibilités.

On annonce de la pluie pour le week-end prochain. :lol:


Un article interressant sur les isolateurs i2s
https://hifiduino.wordpress.com/2011/11/24/which-digital-isolators-for-i2s-or-not/

Philby a écrit:Entrer directement sur l'adau1452 est la seule solution pour utiliser l'amanero (ou tout autre convertisseur USB/I2S) en V2 je crois non?
Ou sinon supprimer l'adau1452?



thierryvalk a écrit:Non, l’adau1452 à 3 entrées I2S (de mémoire) avec ASRC (programmable et débrayable)
L’une de ces I2S est connectée à l’ADAU1701 qui lui reçoit de l’I2S du CS8426 qui lui-même reçoit de l’I2S en passant par ASRC de l’USB ou autre en entrée I2S.

Faut suivre le chemin … :zen:

Il nous reste donc 2 entrées I2S sur l’ADAU1452 .
Et toutes les entrées peuvent fonctionner en même temps.

Par contre si l’on utilise un Amanero, on n’a plus l’USB audio du DSPiy.


thierryvalk a écrit:
Philby a écrit:Si on dévalide l'entrée I2S venant de l'usb (avec les trois straps), on peut mettre l'amanero à la place?
Et ça correspondrait toujours à l'entrée intitulée : "Input USB - I2S" dans l'onglet config?

Bhen oui Philby pourquoi je me suis amusé à mettre des starps ? :mdr:
Je pense que c’est dans la doc, mais sais plus où.


thierryvalk a écrit:
Pacapona a écrit:Si les liens externes gènes dites le et j'enlève...
Concernant l’isolation de l'i2s, apparemment ceci amène du jitter.
La solution serait un isolateur + fifio + reclock. Mais c'est tout de suite + compliqué

Par contre ça existe déjà chez nos voisins DIYER;
http://www.diyaudio.com/wiki/Ians_I2S_FIFO_Project
http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-356.html

Sinon il existe aussi l'isolateur de diyinhk mais il amène du jitter... Et ce n'est que le PCB, faut trouver les différents smd et les souder
http://www.diyinhk.com/shop/audio-kits/19-amanero-isolator-bare-pcb.html

Diyaudio n’est pas dérangeant, dommage qu’ils ne parlent pas français comme tout le monde. :ko:
Par contre pas le temps pour le moment de les lire.

I2S isolé du jitter ?
Décidément on peut tout lire sur le net.
Regarde sur ton DSPiy V1, il y en a un d’isolateur pour l’Amanero.

Tout comme pour le Rpi qui amène du jitter, on passe par un ASRC qui fonctionne avec sa propre horloge pour reconstituer un I2S à bonne fréquence et synchro avec le DSP.
Donc s’il devait y avoir du jitter, il serait de toute manière anéanti.


Philby a écrit:Oui, je l'ai lu dans la doc de cablage, mais ce n'était pas très clair pour moi.
On se connecte sur les pins laissées libres par les straps je suppose...



thierryvalk a écrit:oui, décalé pour ne prendre que les IN du CS.
Je pense qu'il doit y avoir des photos quelque part ....






Philby a écrit:On rentre sur les pins du milieu ? (sdin, isclk, et ilrck) :

Image





Tazz28 a écrit:Sans aucune animosité envers les gars de Diyaudio, c'est carrément du pignolage ces histoires de jitter et de reclocking, ils vont carrément trop loin.
Il faut être cohérent, a moins d'avoir des oscillateur locaux de psychopathes, on parle de niveau de jitter complètement ridicules.
Le niveau de jitter final ne dépend donc (si il reste à un niveau raisonnable / classique sur le reste de la chaine) que de la qualité de l'horloge du 9023 et du DSP.
Tout en restant raisonnable et peu couteux, le DSPiy ne comporte que des composants de qualité que tu retrouvera rarement ailleurs (asrc, dac, regulateurs, oscillateurs) de manière aussi cohérente.
ATTENTION par contre l'asrc ne va pas supprimer le jitter, il va au contraire l'intégrer au signal I2S de manière irréversible, donc faut pas déconner non plus.
Le CS intègre un anti jitter sur la partie SPDIF, avant de rentrer dans la partie ASRC.
L'amanero a d'excellents oscillateurs locaux avec très peu de jitter.
Les Rpi et autres qui ne savent faire que du fractionnaire de la clock principale du CPU sont par contre à fuir en I2S master devant un ASRC (ça le fait bien par contre sur un ESS9023 en direct), il faut nécessairement qu'ils soient en slave car là on va être très très loin des quelques centaines de picosecondes PP introduites par un isolateur genre SiliconLabs.



choubidou a écrit:
Tout a fait d'accord
C'est pourquoi je voulais essayer un PI direct sur le 1452 (en master) en I2S.



Philby a écrit:Tu veux dire quoi Emmanuel?
Que l'entrée USB est aussi bonne que l'amanero?


Tazz28 a écrit:Philippe, tu parle de l'entrée USB du DSPiy V2 ? J'ai pas trop regardé comment elle est foutu, mais l'amanero est un peu une Rolls.
Le truc a retenir, c'est que le jitter n'est plus corrigeable post ASRC.



Philby a écrit:oui, je parle du V2.
Je pensais qu'un convertisseur usb.I2S était mieux que l'usb à CP2114, mais je peux me tromper!!! :D


thierryvalk a écrit:Ils sont tous 2 USB -> I2S.
Mais la comparaison s’arrête là.
Le CP2114 c’est exclusivement du 16bits à 48KHz, mais a le grand avantage de ne pas nécessiter de driver et surtout de couter moins de 2€. :D
Et vu qu’il nous sert aussi pour la programmation, c’est gratuit.


Tazz28 a écrit:
alkasar a écrit:on pourrait faire un sujet a part RPi avec DSpiy ? pacapona tu t'y colles ?
ca intéresse du monde (cf quelques pages plus haut sur le sujet) et j'ai peur que ces discussions intéressantes soient perdues en page 346 d'un long topic.

pour moi, comme déjà dit plus haut je vois 3 niveaux de cohabitation, de complexité croissante :
1- Rpi comme source. A priori en I2S. Prévoir les cas DSPiy1, Dspy2 avec et sans ADAU1452

2- Rpi est aussi controleur : le Rpi pilote le DSPiy par exemple en envoyant les codes IR dans le trigger_in du dspiy. Dans ce cas, le Rpi devient la tour de controle, on peut utiliser ses interfaces, GPIos, écran tactile,etc. Misu a déjà commencé a réfléchir a la question pour la partie codes IR.

3 - Rpi remplace DStudio. Le must : le Rpi dialogue avec le µC du dspiy (par l'interface série ? I2C ?). On pourrait aller jusqu'à remplacer DStudio par une interface web sur un serveur hébergé sur le Rpi. Le Rpi+DSpiy devient un appareil complètement autonome.


1- DSPiyV1, il faut compléter la DINv1 avec l'isolateur pour le mode maitre et revoir le soft, DINDS, pas prévu sans modif hard. DSPiyV2, y a plus d'isolateurs je crois donc soft uniquement.


thierryvalk a écrit:Oui, exact, dans le cas où le Rpi est en Slave.
Vu que l’on parlait du CP2114, à la base je voulais l’utiliser avec son oscillateur interne.
C’est techniquement possible, mais cet oscillateur fait 48MHz.
Donc soucis similaire au Rpi, une division d’horloge qui n’est sur des entiers , mais de mémoire Silabs se vantait d’avoir une méthode de division qui allait bien.
Le constat : n’a jamais fonctionné avec le CS8422. Cela me fait dire qu’il faudrait analyser un peu mieux le Rpi en Master vu qu’il semble fonctionner.

Je me méfie de plus en plus des lectures du Net. :oldy:

PS j'espère que ces posts seront replacés lorsque le sujet aura été créé.


Tazz28 a écrit:
mais de mémoire Silabs se vantait d’avoir une méthode de division qui allait bien.
Oui, pour leurs oscillateurs programmables, c'est leur spécialité. Par contre je pense pas pour le CP2114.






Conscernant la commande du DSPiy via l'i2c du RPI ;

thierryvalk a écrit:On en parle ici :
post178430236.html#p178430236

L’I2C n’est en effet pas une très bonne idée dans le sens où il n’est pas isolé et pourrait créer des problèmes avec les autres intervenants.

La telco via les triggers est bien mieux mais demande un peu de code.

On peut utiliser le Rpi pour envoyer des codes, ce que compte faire Misu ou le contraire utiliser le DSpiy pour envoyer des codes.

Dans les 2 cas sans porteuse 36KHz.
Dans le sens DSPiy -> Rpi, d’une certaine manière on utilise juste le capteur IR du DSpiy.

Mais en utilisant le codage NEC, on peut aussi utiliser les codes MultiDSpiy qui donnent Preset, volume et balance.

Je ferais une petite doc sur l’ensemble.


Alcasar propose de simplement utiliser l'usb ;

thierryvalk a écrit:Oui, apriori ce sont les mêmes câbles USB sur le Rpi. :ane:

Je ne connais rien au Rpi, mais s’il peut communiquer à un HID oui.
Et idem sans doute pour l’audio.

Par contre, « aller plus loin » oui, mais demande alors un bon paquet de code.

Quelqu’un connait Visual Studio Community ?
Semble être gratuit et complet. Actuellement en version 2013 et bientôt la 2015. Devrait supporter des plateformes non Windows.


alkasar a écrit:merci :)
sans toucher a ce qui existe, on pourrait avoir un Rpi branché
- sur trigger in pour passer les commandes,
- sur le port usb pour envoyer des applis ou modifier des paramètres,
- sur le port I2S pour envoyer de l'audio.
Le Rpi deviendrait le point de controle complet de ce qui se passe dans le DSPiy.
L'avantage c'est que sont les interfaces du Rpi qui servent. Et comme elles sont nombreuses, ca manquera pas de boutons, écrans tactiles, wifi etc. et on ajoute la lecture audio et streaming audio autonome :) Ca ouvre plein de perspectives.

C'est sur qu'il y a du soft a écrire sur le Rpi et aussi comprendre le protocole d'échange avec DSPiy sur l'USB. Mais bon, les développeurs ne manquent pas de talent :)
Si foobar vient un jour avec W10 sur le Rpi tu penses bien que je serais hyper motivé pour tout mettre ensemble.



Visual Studio Community c'est le nouveau nom de VS Express depuis 2013. C'est la version gratuite avec quelques limitations. L'ouverture vers d'autres plateformes c'est nouveau en revanche. microsoft n'ignore plus les autres mondes, c'est bien. Le Rpi est dans leur cible, tant mieux si tout converge dans le bon sens.


thierryvalk a écrit:Hello tifou19,

@alain :
VS Community 2013 installé.
Selon mes infos c’est pas juste Express qui lui était limité.
Import du projet DSPiy qui est en VS2005 sans trop de problèmes, fonctionne sauf le programme d’installation qui devra sans doute être refait.
Pas grande différences après quelques minutes dessus si ce n’ait que l’interface est plus austère que 2005.
Comme je lisais cet aprem, en 2020 on aura l’interface de WIN 3.11 :mdr:

Pour la doc IR, voici un début avec les codes du multidspiy.
N’hésitez pas à demander des infos.
Edit cette doc doit être corrigée, lire code Sony et non NEC
DSPiy Codes IR en mode MultiDSpiy.pdf


thierryvalk a écrit:A y regarder de plus près, j’ai raconté grosse bêtise dans mon PDF, le codage utilisé ne serait le pas NEC mais du Sony. :oops:


Voilà j’arrête pour ce soir...
Pacapona
 
Messages: 347
Inscription: 02 Jan 2014 19:33
Localisation: CH
  • offline

Annonce

Message par Google » 12 Mai 2015 21:54

 
 
Publicite

 
Encart supprimé pour les membres HCFR

Message » 13 Mai 2015 11:03

merci :thks: ça c'est un post!
alkasar
Contributeur HCFR 2015
 
Messages: 11495
Inscription: 29 Nov 2005 22:47
Localisation: Neuf deux
  • offline

Message » 13 Mai 2015 11:22

j'essaie de comprendre.
si je lis bien cette phrase
Les Rpi et autres qui ne savent faire que du fractionnaire de la clock principale du CPU sont par contre à fuir en I2S master devant un ASRC (ça le fait bien par contre sur un ESS9023 en direct), il faut nécessairement qu'ils soient en slave car là on va être très très loin des quelques centaines de picosecondes PP introduites par un isolateur genre SiliconLabs.

c'est notre cas puisque l'entrée I2S du DSPiy est sur l'asrc du CS8422.

Or choubidou a branché en direct le Rpi en I2S sur le DSPiy2, donc Rpi en master et I2S non isolé, et ça semble marcher.

:wtf:

il y a du jitter mais il est imperceptible ?
alkasar
Contributeur HCFR 2015
 
Messages: 11495
Inscription: 29 Nov 2005 22:47
Localisation: Neuf deux
  • offline

Message » 13 Mai 2015 12:23

Il faudrait que Choubidou fasse aussi des testes avec différents rate, genre 88,96,192... Suivant la fréquence le jitter sera plus élevé et du coup il aura peut-être des coupures. Ces testes doivent être fait en vérifiant via l'output de /proc/asound/... que la carte envoie effectivement le rate originale de la piste et qu'elle n'est pas ressamplée. ça se voit aussi directe sur l'utilisation du cpu.

Avec le drivers qu'il utilise je ne sais pas si c'est la clock principale du cpu qui est utilisée (500mhz) ou le cristal du rpi qui lui est à 19.2 mhz. Suivant l'horloge et le rate le coefficient sera plus ou moins précis.

Mais vu que le rpi est en master a mon avis la sortie est ressamplée, son cpu doit sûrement bouriner quand il lit du 192... Vu qu'il utilise la conf prévu pour le dac hifiberry qui devrait mettre le rpi en slave...

Choubi, tu nous faits quelques testes?
Pacapona
 
Messages: 347
Inscription: 02 Jan 2014 19:33
Localisation: CH
  • offline

Message » 13 Mai 2015 12:24

Pour ce qui est du manque d'isolateur il semblerait que ce ne soit pas un problème;
https://hifiduino.wordpress.com/2011/11/24/which-digital-isolators-for-i2s-or-not/
Pacapona
 
Messages: 347
Inscription: 02 Jan 2014 19:33
Localisation: CH
  • offline

Message » 13 Mai 2015 12:35

On peut aussi utiliser le BBC qui lui peut utiliser une horloge externe...
Pacapona
 
Messages: 347
Inscription: 02 Jan 2014 19:33
Localisation: CH
  • offline

Message » 13 Mai 2015 12:48

Image
Pacapona
 
Messages: 347
Inscription: 02 Jan 2014 19:33
Localisation: CH
  • offline

Message » 13 Mai 2015 12:59

Pacapona a écrit: Vu qu'il utilise la conf prévu pour le dac hifiberry qui devrait mettre le rpi en slave...
elle met l'I2S du Rpi en slave cette config ? comprend pas trop comment ça marche alors. Des choses m'échappent faut que je retourne a mes études :oops:

Choubi, tu nous faits quelques testes?
oui un petit retour n'est pas superflu ;)
alkasar
Contributeur HCFR 2015
 
Messages: 11495
Inscription: 29 Nov 2005 22:47
Localisation: Neuf deux
  • offline

Message » 13 Mai 2015 13:11

Je dit pt-être quelques connerie :P
Mais hifiberry font des produits plutôt bien pense et pas overkill. Avec le digi+ le rpi est en slave.
Si il n'y a pas moyen qu'il se mette en slave pas impossible qu'il passe en master sans broncher, par contre c'est fort probable que le drivers n'ai pas prévu ,dans ce cas de figure, de calculer toute les fréquences via des coefficients. il va donc ressampler suivant le rate...
Pacapona
 
Messages: 347
Inscription: 02 Jan 2014 19:33
Localisation: CH
  • offline

Message » 13 Mai 2015 13:31

Concernant l'isolation de l'i2s, je m'était trompé d'article avant... :ane:
Je voulais citer celui-ci;
https://hifiduino.wordpress.com/2012/04/01/experiments-with-nve-il715-isolator/

voici la conclusion;

"As discussed earlier, at least in theory, the reason to use a signal isolator is to block any potential noise coming from the I2S lines including ground. If one cannot find other ways to eliminate noise from the source, and it is demonstrated that the noise is real and it is detrimental to the DAC, then one might consider trading off the added jitter with the elimination of noise.

However as shown by these experiment, there is no clear advantage of using the IL715. With “normal” operation (DPLL=LOWEST with 44.1K and DPLL=LOW with 88.2K), there is no real difference between using the IL715 or a direct connection. We know for a fact that there is added jitter. The data also shows that there is NO “noise issue” from the source.

Since I am a fan for minimal components in the data path, I would side towards NOT using an isolator."
Pacapona
 
Messages: 347
Inscription: 02 Jan 2014 19:33
Localisation: CH
  • offline

Message » 13 Mai 2015 14:30

ok c'est plus clair. Le role d'un l'isolateur est d'isoler galvaniquement (cad electriquement) et c'est ce qu'il fait.

Pacapona a écrit:Since I am a fan for minimal components in the data path, I would side towards NOT using an isolator."
mwouais c'est un réflexe en analogique ou chaque composant additionnel altere le signal, même très peu. En numérique bof bof. De toute façon c'est copié dans des buffers, dans de la mémoire, etc. Tant que ça n'altere pas le signal, on s'en moque.


question bete aux électroniciens chevronnés :
En non isolé, les 0V du RPi et DSpiy deviennent communs et partagent leur bruit.
Pour limiter les soucis lié au bruit, qu'est ce qui est mieux :
- utiliser la même alim 5V pour DSPiy et Rpi
- utiliser des alims séparées
- ca ne change rien
alkasar
Contributeur HCFR 2015
 
Messages: 11495
Inscription: 29 Nov 2005 22:47
Localisation: Neuf deux
  • offline

Message » 13 Mai 2015 19:04

- concernant "Phase noise of I2S sources" : c'est un graphe qui veut faire apparaitre le bruit de phase sur le signal analogique final.
On est à chaque fois dans le cas ESS9023 directement au cul de la source donc on profite pleinement de l'antijitter du ES9023. Vu qu'on sait pas comment est dérivé la clock du 9023 ni son alim dans chaque cas, ça veut potentiellement tout et rien dire.

- L'isolateur est utile, cf les retours des différentes config avec les différents DSPiy

- faut remettre les "test" d'isolateurs de hifiduido dans leur contexte : un autre méga pignolage de diyaudio à propos de la config de la DPLL de l'antijitter du ES9018 et que sur la chaine numérique -> complètement hors du sujet qui nous préoccupe.

-
c'est notre cas puisque l'entrée I2S du DSPiy est sur l'asrc du CS8422.
Or choubidou a branché en direct le Rpi en I2S sur le DSPiy2, donc Rpi en master et I2S non isolé, et ça semble marcher.
:wtf:
il y a du jitter mais il est imperceptible ?

Là on rentre dans un autre débat. Bien sur ça fonctionne et avec l'asrc, il n'y a pas de raison que ça "décroche". Par contre si on faisait apparaitre le résultat sur le premier graphe évoqué, on pèterai les scores, avec surement les autres courbes qui se confondraient entre elles avec le facteur d’échelle: l'antijitter du 9023 deviendrait totalement inefficient le jitter étant réintégré par l'asrc au signal PCM. On serait dans le cas d'un DAC standard synchrone sans antijiter. Je pense que sur une bonne chaine audio, la différence deviens audible. (tout dépend encore de la fréquence du signal source, le jitter étant plus ou moins important coté rpi suivant le cas "d'indivisibilité", et aussi de la zikmu jouée...).
Tazz28
Membre HCFR
Membre HCFR
 
Messages: 2802
Inscription: 03 Nov 2008 23:47
Localisation: Dreux
  • offline

Message » 14 Mai 2015 0:24

cela concerne le beaglebone black mais dans le principe je pense que c'est la même chose :

http://bbb.ieero.com/

Digital audio chain:

BBB as the source of I2S/DSD digital audio, it requires external clock
Hermes-BBB as the two-way signal isolator (clock signal in, audio data signals out, I2C in-out) and I2S/DSD switch
Cronus as the master clock signal provider and re-locker of data signals from BBB to the master clock; there are two clocks available, one for 44.1kHz and other one for 48kHz frequency families
DAC as consumer of re-locked data signals (and clock if needed)
coOlibry
 
Messages: 216
Inscription: 06 Mar 2011 23:17
Localisation: 85
  • offline

Message » 19 Aoû 2015 11:15

Bonjour,
quelques retours d'experience du rpi branché au hifiberry dac via i2S vs usb.

Usb -- :
d'une façon générale, le bus du raspberry pi est médiocre que cela soit le RPI 1 ou le 2.
En effet, le même bus se partage les ports (ethernet et usb), et en plus il est lent.
Donc plus vous sollicitez le bus moins ça répond.
Un exemple frappant, KODI (XBMC) sur RPI 1 ou 2, ça rame dès qu'on sollicite le disque USB ou le réseau (les 2 ensemble c'est très lent)

I2S: pas mal
l'I2S fonctionne bien, on trouve les codes sources des drivers.
Par contre et la je ne suis pas electronicien donc je laisse le soin aux lecteurs de ce thread de compléter, il est possible que je dise des bétises,
impossible d'adapter correctement la fréquence I2S du RPI.
C'est la raison pour laquelle le minidsp bien que possédant une entrée I2S peut dificielement se brancher sur le RPI.

Le BBB pour l'I2S bien qu'il faille bidouiller a bonne presse.
camelator
 
Messages: 38
Inscription: 19 Mai 2013 18:28
  • offline

Message » 08 Déc 2019 0:53

Petit déterrage : j'envisage de relier directement mon RPI 3B+ à mon DSPIY v2 en I2S
Je lis qu'il faut un isolateur - pensez-vous que ce modèle fasse l'affaire : https://www.audiophonics.fr/fr/single-b ... _search=fs ?

Merci ;)

La configuration dans mon profil


Picrat'chou: 12,5° d'amour...
guyome
Membre HCFR
Membre HCFR
 
Messages: 8577
Inscription: 25 Avr 2001 2:00
Localisation: Savoie
  • offline


Retourner vers Filtrage actif, Equalisation et Processeurs