DAC / lecteur réseau à base de Raspberry Pi

» 27 Mar 2014 11:47

A priori ce DAC n'intègre pas d'horloge. Hors il en faut une obligatoirement.

» 27 Mar 2014 21:32

le port usb type B c'est pour se servire du dac via un pc sa n'a pas d’autre intérêt ?

» 27 Mar 2014 23:26

benjiv a écrit:A priori ce DAC n'intègre pas d'horloge. Hors il en faut une obligatoirement.

donc cette configuration la ?

WM8741 + AMANERO

j'ai choisie une config en 32bit y a t il un intérêt ?
A part celle présenté sur le poste et celle ci dessus vous d'autres idée de config dac + horloge ?

» 28 Mar 2014 11:23

Salut, vu la qualité de la puce Sabre ESS9023, il y a un bon candidat chez Hifimediy : Hifimediy ES9023 DAC, I2S and left justified input, 192Khz/24bit, moins de 15 € avec l'oscillateur en sus.

Edit : on en avais discuté sur ce post parallèle, Tazz semble penser que la mise en oeuvre de l'I2S avec le Rpy est pas si simple. J'ai pas les compétence pour comprendre pourquoi...

» 28 Mar 2014 15:38

Bonjour,

de ce que j'ai compris de mes lectures si on utilise l'I2S sortant du raspberry au lieu du port USB, l'inconvénient est que le raspberry ne génère pas le signal MCK (master clock).

Donc soit il faut ajouter ce signal avec une horloge externe, soit il faut un DAC qui est capable de fabriquer ce signal "proprement" à partir des autres (le PCM5102A de l'HIFIBERRY par exemple).

Si l'on injecte une horloge externe (256 fois la fréquence LRCK) je n'ai pas encore tout compris sur la façon donc le DAC est capable de la resynchroniser. Par ailleurs si la fréquence d'échantillonnage du signal lu change pour moi il faudrait changer cette MCK, comment faire dans ce cas ?

» 28 Mar 2014 16:06

C'est surtout que je pense que de base ça n'a aucun intérêt pour de la "qualité".
Pas de possibilité de driver le port I2S en mode slave, on est obligé de s'en remettre au clocks internes du RP-I pour le 44.1khz et le 48khz. La PLL est capable de générer le 44 et 48 selon la méthode par division fractionnelle ce qui normalement est très bien, mais dépendant de la qualité de la master clock globale qui n'est très certainement pas tip top et surement très mauvaise en bruit de phase.
Pas de master clock synchrone pour l'I2S pour les dacs qui en ont besoin.

La seule option rationnelle et qualitative pour un RPI est l'ESS :
- Master clock indépendante et asynchrone donc on peu avoir une clock de qualité avec un bruit de phase et une stabilité correcte. Pour les fous furieux qui veulent se ruiner, un hifimedy sans clock + 20~30€ dans un oscillateur crystek et c'est le top (a ce prix là je veut bien me ruiner régulièrement...)
- Du coup le R-PI ayant une clock fractionnelle pour l'I2S, on a du 44khz et 48khz EXACT même si bruité ou avec du jitter. Mais on s'en fout avec l'ESS, la seule chose qui compte c'est l'exactitude de la fréquence (contrairement à pas mal de soc qui font que de l'approchant, division entière oblige ...).

Après, on peu faire beaucoup beaucoup plus compliqué et beaucoup plus cher, mais avec quasiment aucun intérêt.
Pour faire plus compliqué (nécessaire avec un chip synchrone) sans faire n'importe quoi, l’absence de mode slave est rédhibitoire (et y a plein d'autres super cartes autres que la PI).
Et si c'est pour repasser par de l'USB/ethernet ou autre, ça reviens à re-déporter la problématique sur un autre élément : retour à la case départ, mais avec un R-PI en plus dans la chaine...

» 28 Mar 2014 16:16

shinzuka a écrit:donc cette configuration la ?

WM8741 + AMANERO

A tester pour le Amanero. Sur le même principe, il y a celui ci : http://www.diyinhk.com/shop/audio-kits/ ... lator.html

» 28 Mar 2014 18:54

Tazz28 a écrit:Et si c'est pour repasser par de l'USB/ethernet ou autre, ça reviens à re-déporter la problématique sur un autre élément : retour à la case départ, mais avec un R-PI en plus dans la chaine...

Merci pour les explications Tazz.
Si tu utiilises un DAC USB asynchrone sur la sortie USB du Rpy : je suppose que le Rpy peux gérer le protocole USB standard. Dans ce cas, par exemple avec le DAc Hifimediy UAE3 (acheté avec l'option asynchrone), le DAC fonctionne avec sa propre horloge en maitre et le Rpy est en slave sur l'USB. ça résout le problème et c'est plus simple pour les non fans du fer à souder, non ? Je veux dire pourquoi s'emmerder avec l'I2S si on peut utiliser un DAC USB, niveau logiciel c'est nettement plus simple à mettre en oeuvre ?

Perso je trouve un interet dans le Rpy ou d'autres micro Pc car avec une grosse communauté sur le Net, il y a beaucoup de solutions logicielles faciles à mettre en oeuvre et bien documentées pour les non initiés.

» 28 Mar 2014 19:15

Tu peux repiquer la MCLK sur la bitclock. C'est ce qu'a fait torsten sur le rpy dac, et ca tourne - si le dac le supporte.
si tu veux configurer le PI en mode slave, il faut recompiler soit le kernel soit la lib i2s correspondante, parce que la configuration du module i2s du pi doit etre reconfigurer.
Ca a un interet et uin inconvenient:
-l'interet est que si tu as une clock super propre en Master, tu limites la jigue. Mais tu ne la limitera pas aussi bien qu'un sample rate converter ou un receiver spdif (qui sont sous les 50ps).
-L'inconvenient est que tu es limite sur la clock, tu pourras pas aller plus loin que les 44.1 ou 48Mhz en frequence d'echantillonage, parce qu'il te faudra une clock plus rapide et un switcher de clock qui te permettra de donner la bonne MCLK pour le bon mode...

J'ai trouve les relation MCLK/FS qui sont "minimum" pour que la conversion se passe bien:

Code: Tout sélectionner: SAMPLING RATE(LRCLK) MASTER CLOCK (MCLK) FREQUENCY (MHZ) 128fs 192fs 256fs 384fs 512fs 768fs 32kHz Unav. Unav. 8.192 12.288 16.384 24.576 44.1kHz Unav. Unav. 11.2896 16.9344 22.5792 33.8688 48kHz Unav. Unav. 12.288 18.432 24.576 36.864 88.2kHz 11.2896 16.9344 22.5792 33.8688 Unav. Unav. 96kHz 12.288 18.432 24.576 36.864 Unav. Unav. 176.4kHz 22.5792 33.8688 Unav. Unav. Unav. Unav. 192kHz 24.576 36.864 Unav. Unav. Unav. Unav.

Perso, je vais me contenter de l'i2s du pi car je vais pouvoir mesurer sa jigue. Ensuite, si ca va pas (et si c'est pire a l'oreille) que mon dac usb, soit je tenterai de faire une mini board avec un sample rate converter, soit je laisserai tomber et me contenterai du dac USB (tres bien au demeurant).

Un message de torsten qui est l'auteur du RPI dac:
"RPi is I2S master. Even the SCLK signal is not provided by RPi but needed by the DAC (it is the system clock, used for all operations including sampling the I2S signals itself) - it works via a connection of SCLK with BCK (ndlr: on the RPI DAC). There is a jumper which splits the BCK from RPi and provides it (with same clock frequency) as SCLK on DAC.
The DAC (NDLR: pcm1794A) has internal PLL and is able to generate the system clock needed inside the DAC itself.
It works perfect (BTW: the HiFiBerry, using a PCM5120, works in the same way).
To add an oscillator (e.g. XTAL with 24.576 MHz) will not help really: the clocks are not in sync (I have not tried), it can make it worse if you have an offset between these
free running clocks and the I2S signals will drift and jitter."

» 28 Mar 2014 19:35

Dernier avantage de cette situation (c'est a dire le rpi master), c'est qu'il genere sa propre clock, et fonctionne en mode DMA:
-Lorsque qu'un morceau est commance, il est converti de son format de base en wave par ffmpg en entier
-il est ensuite bufferise en memoire vive
-Un canal DMA est configure pour alimente le module I2S de maniere automatique, cadencee par la LRclock (ou frame synchro), c'est a dire qu'un mini processeur s'occupe de faire la copie des samples depuis la memoire vive jusqu'au buffer d'entree du module i2s, et a chaque fois qu'une case se libere dans le buffer, un nouveau sample est copie dans l'aide du CPU.
Le CPU n'intervenant pas dans la circulation des donnes, la chance de rater des samples est infinitesimale et pas du au CPU.

» 29 Mar 2014 0:23

Pas de possibilité de slave sur la R-PI, c'est le SOC qui est comme ça. Le driver Linux n'a rien avoir avec l'affaire.
Merci pour le DMA :lol:

, c'est un minimum le DMA pour toute interface I2S qui se respecte dans un soc moderne.
Le DMA marche aussi bien en master qu'en slave sur tout soc digne de ce nom. Faut pas mélanger tous les domaines d'horloge.

Oui, si le chip DAC a une PLL interne, on peu commencer à reconstituer les clocks dans tous les sens et ça simplifie les choses.
Il y a toujours des solutions. Et je persiste à penser que le plus adapté qualitativement et économiquement pour un RPI c'est un ES9023.

Ce qui me désole, c'est cet entêtement autour de la R-PI qui est un très mauvais hardware, très limité en terme de fonctionnalités/qualité de ses différents IPcores, peu puissant et bourré d'à coté proprio, fermé, non documenté et médiocre en tout, alors qu'a coté il y a une multitudes de cartes dans les mêmes gammes de prix (de 1/2 à 3 fois le prix soit dans tous les cas moins de 120€), 100% documentés et open ou bien plus open, avec des socs beaucoup mieux foutu. Ces cartes sont souvent un peu moins "passe partout" (quoi que...) et il y en a toujours une parfaitement adapté à ce que l'on veut faire.
Derrière, c'est à chaque fois du Linux donc tout pareil .... Et qu'on me parle pas de communauté... les "producteurs/contributeurs" sont pas en plus grand nombre sur le RPI que sur les autres plateformes.

Pour répondre à greg, oui y a intérêt a avoir un récepteur USB audio asynchrone tellement l'USB de la RPI est calamiteux même si le driver est un poil plus stable maintenant. Je comprend sans pblm ton intérêt pour les micro pc et je le partage ! mais il y a plein de choix maintenant, tous bien meilleurs que la RPI.

Le 9023 a aussi l'avantage d'intégrer tout l'étage de sortie. Ça évite de retrouver n'importe quoi en sortie du DAC et garantie un minimum qualitatif quoi qu'il arrive.
Un hifimedy + une GPIO pour piloter le mute/stanbymode + la modif nécessaire à son utilisation (voir topic DSPiy) + une clock de course et je suis quasi certain que l'on va enterrer en pratique un paquet de truc existant ou a venir spécial RPI. Y en a pour moins de 35€ et je suis sur qu'une carte plug&play développée spécialement pour le RPI su cette base couterai pas plus (ou un poil plus en mettant du reg de compétition) même en toute petite série.

» 29 Mar 2014 10:19

Si j'ai bien compris pas la peine de mettre une fortune Hifimediy ES9023 + une clock de course ?

» 29 Mar 2014 10:58

Bonjour,
vous en pensez quoi de la carte HiFiBerry Digi ?
Ça a l'air simple comme mise en oeuvre pour attaquer un Dac en coaxiale.

» 29 Mar 2014 13:57

Tazz28 a écrit:Pas de possibilité de slave sur la R-PI, c'est le SOC qui est comme ça. Le driver Linux n'a rien avoir avec l'affaire.
Merci pour le DMA , c'est un minimum le DMA pour toute interface I2S qui se respecte dans un soc moderne.
Le DMA marche aussi bien en master qu'en slave sur tout soc digne de ce nom. Faut pas mélanger tous les domaines d'horloge.

Oui, si le chip DAC a une PLL interne, on peu commencer à reconstituer les clocks dans tous les sens et ça simplifie les choses.
Il y a toujours des solutions. Et je persiste à penser que le plus adapté qualitativement et économiquement pour un RPI c'est un ES9023.

Ce qui me désole, c'est cet entêtement autour de la R-PI qui est un très mauvais hardware, très limité en terme de fonctionnalités/qualité de ses différents IPcores, peu puissant et bourré d'à coté proprio, fermé, non documenté et médiocre en tout, alors qu'a coté il y a une multitudes de cartes dans les mêmes gammes de prix (de 1/2 à 3 fois le prix soit dans tous les cas moins de 120€), 100% documentés et open ou bien plus open, avec des socs beaucoup mieux foutu. Ces cartes sont souvent un peu moins "passe partout" (quoi que...) et il y en a toujours une parfaitement adapté à ce que l'on veut faire.
Derrière, c'est à chaque fois du Linux donc tout pareil .... Et qu'on me parle pas de communauté... les "producteurs/contributeurs" sont pas en plus grand nombre sur le RPI que sur les autres plateformes.

Pour répondre à greg, oui y a intérêt a avoir un récepteur USB audio asynchrone tellement l'USB de la RPI est calamiteux même si le driver est un poil plus stable maintenant. Je comprend sans pblm ton intérêt pour les micro pc et je le partage ! mais il y a plein de choix maintenant, tous bien meilleurs que la RPI.

Le 9023 a aussi l'avantage d'intégrer tout l'étage de sortie. Ça évite de retrouver n'importe quoi en sortie du DAC et garantie un minimum qualitatif quoi qu'il arrive.
Un hifimedy + une GPIO pour piloter le mute/stanbymode + la modif nécessaire à son utilisation (voir topic DSPiy) + une clock de course et je suis quasi certain que l'on va enterrer en pratique un paquet de truc existant ou a venir spécial RPI. Y en a pour moins de 35€ et je suis sur qu'une carte plug&play développée spécialement pour le RPI su cette base couterai pas plus (ou un poil plus en mettant du reg de compétition) même en toute petite série.

Perso j'ai opté pour une cubieboard (1), parce qu'on trouve le spdif sur les connecteurs GPIO .... bon choix?

» 29 Mar 2014 15:32

Oui, au même titre que la BBB, la ariaG25, la olinuxino A20 et beaucoup d'autres. Faut faire son marché par rapport au besoin.