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) :
thierryvalk a écrit:oui,
post178380130.html?hilit=amanero#p178380130
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:Oui, pour leurs oscillateurs programmables, c'est leur spécialité. Par contre je pense pas pour le CP2114.mais de mémoire Silabs se vantait d’avoir une méthode de division qui allait bien.
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
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...
ça c'est un post!
