DSPiy : Interface audio numérique sans fil et autres idées

[robob]

Ce matin, 10 cm de neige dans le val d'oise : super les sous bois enneigés.

Niveau prix, il ne faut pas comparer des grosses productions du style Smartphone avec les petites production des « mini-ordinateur » qui intéressent beaucoup moins de monde.Et à l’heure actuelle, un écran 800*480 capacitif est introuvable seul ou à un prix bien supérieur à un Smartphone.

Bien sur et cela me donne une autre idée (au reveil ) : on peut modifier l'OS de n'importe quel smartphone ou tablette Android, en la rootant, pour intégrer le protocole USB audio standard. il peut alors servir comme source ou comme renderer en utilisant les applis existantes sur le google store via sa sortie USB.

En désossant un smartphone ZTE blade ou une tablette low cost style Ainol novo (moins de 80€ livrée), on dispose pour ce prix de l'ecran tactile et du hardware qu'on peut réintégré dans un boitier.

Bon on s'éloigne du DSPiy, je vous l'accorde, mais c'est juste l'idée d'avoir un ampli intégré (interface Android avec un ecran capacitif de 7 pouce, réception Wifi, renderer voir serveur DNLA, DAC de qualité, Ampli T-amp)...

Evidement il s'agit de Diy pur jus, pour une production commerciale c'est une autre histoire .

[Tazz28]

Et tu fait comment pour tous les drivers non open-source et uniquement binaire pour toutes ces plateformes ? Ça s'appelle faire du jetable.
Je comprend que cette approche te donne l'impression que tu va pouvoir faire quelque choses tout seul sans trop d'efforts et avec tes connaissances actuelles.
Grande désillusion assurée. C'est limite plus compliqué et demande des connaissances poussées.
Tu perdra moins de temps pour un résultat moins aléatoire en faisant l'effort d’apprendre et d'acquérir le bagage sur des plateformes simples, complètement ouvertes et utilisant les bonnes approches ( une stack USB c'est franchement complexe a coté d'une interface I2S hardware d'un µC ou d'un SOC ).

Perso, me lancer dans de la modif de hardware fermé low cost et ce qui va avec, très peu pour moi.
Le coup du système de transmission filaire et sans fil d'audio numérique m’intéresse (surtout le truc du sans fil, pour le fun et le défit technique multicanal, car sinon le wifi chez moi c'est banni) tout comme un renderer audio (DLNA ou autre) simple et je partirai clairement sur une base d'ARIA.
Reste a voir pour le endpoint multicanal (>2), ARIA en TDM + électronique TDM -> I2S ou autre plateforme.
Pour le DSPiy, le DSP bouffe directement du TDM donc pas de soucis normalement (à la grosse problématique près de l'asrc ...)

[Tazz28]

Pour compléter et illustrer mon propos : 99% des µC et SOC sortent de l'audio avec une bitclock et frame clock complètement approximative (division entière de la masterclock interne) sauf sur les SOC très haut de gamme (division fractionnaire de la masterclock -> pll).
Pour faire quelque chose de correct sans sortir l'artillerie USB qui ne fait que déporter le problème, il faut une masterclock externe et mettre la sortie I2S/TDM en slave. Ça implique une clock programmable (SI570 au pif ...) ou deux oscillateurs.
Ça vous le trouverez pas sur vos truc tout fait ou sur vos devices à bas prix bidouillés. Donc pour avoir un truc correct faut à un moment ou un autre mettre les mains dans le cambouis, à moins de faire des assemblages plus que conséquents de truc "tout" prêt pour un coût au final élevé et une taille pas très discrète.

[robob]

la bidouille à partir d'une tablette low cost, c'est du tout fait niveau software : j'ai une tablette Ainol et il existe une rom alternative qui, avec quelques bidouilles software téléchargées, permet d'avoir l'USB audio standard. Il est donc possible; en intégrant cette tablette dans le boitier avec une interface USB vers I2S, de se connecter au DSPyi. Concernant l'utilisation de la tablette, il suffit de télécharger un des programmes existant sur le google store pour en faire un renderer ou de l'utiliser directement comme source avec un player quelconque. Il n'est évidement pas question pour moi d'aller faire ses bidouilles logicielles, mais bon, on oublie...

Tu perdra moins de temps pour un résultat moins aléatoire en faisant l'effort d’apprendre et d'acquérir le bagage sur des plateformes simples, complètement ouvertes et utilisant les bonnes approches

C'est pourquoi une solution à base de mini board sous linux (voir Android pour être à la mode ) m'intéresse plutôt que d'attendre patiemment que tu fasses le boulot avec l'Aria . Mais autant je me sens d'acheter, par exemple un module Olimex qu'il suffit de connecter à un ecran et un clavier pour pouvoir commencer à l'utiliser, autant l'aria est hors de portée pour moi : il me faudrait la planche d'évaluation pour pouvoir l'utiliser.

Si tu penses qu' un A10-OLinuXino de Olimex est une solution envisageable, au regard des spécifications du chipset Allwinner A10 et en espérant que l'ensemble des broches nécessaires soient exposées, alors je sauterais bien le pas, en achetant le module des qu'il est disponible et en essayant d'installer dessus ce qu'il faut pour en faire un récepteur WIFI (voir CPL) et un renderer, ainsi que de le configurer, avec ton aide, pour la connexion I2S en stéréo vers DSPiy. Le multicanal on verra plus tard...

J'ai quelques connaissances en programmation dans un domaine totalement étranger à l'audio, et de préhistoriques études en micro-electronique (1983), jamais exploitées, devrait me permettre de trouver ma route...

[thierryvalk]

Les tablettes low-cost sont alléchantes, j’ai testé la chose y il a quelques mois.
Premier soucis, elles ne disposent en général que d’un seul pour USB.
Pour faire du développement, on utilise un port USB pour l’émulation et donc problème.
Il est possible de faire l’émulation via le Wi-fi, mais çà complique.
Finalement j’ai passé l’éponge._{Android pas pour moi. Je préfère WINCE tout simple à mettre en œuvre…}
La grande différence entre un produit grand public et une carte de développement est qu’avec cette dernière tu reçois (normalement) le SDK qui te donne accès aux drivers avec la possibilité de re-compiler l’ensemble. Avec une tablette, on utilise +- ressemblant avec toujours une incompatibilité à un endroit.
Si l’ A10-OLinuXino supporte bien chipset Allwinner A10 c’est tout bon.
Page 70 de ta doc : "I2S support 8 channel output and 2 chanel input"
Donc l’I2S en sortie supporte le TDM.

[Tazz28]

l'A10-OLinuXino est en effet très prometteuse.

[robob]

bon bah yapluka attendre que le module sorte, qu'il soit accessible en prix et bien entendu que tous les possibilités du chipset soient accessibles sur le module Optimex.

Un peu de lecture :

20. Digital Audio Interface
20.1. Overview
The Digital Audio Interface can be configured as I2S interface or PCM interface by software. When configured as I2S interface, it can support the industry standard format for I2S, left-justified, or right-justified ...

It includes the following features:
 I2S or PCM configured by software
 Full-duplex synchronous serial interface
 Configurable Master / Slave Mode operation
 Support Audio data resolutions of 16, 20, 24
 I2S Audio data sample rate from 8Khz to 192Khz
 I2S Data format for standard I2S, Left Justified and Right Justified
 I2S support 8 channel output and 2 channel input
 PCM supports linear sample (8-bits or 16-bits), 8-bits u-law and A-law compressed sample
One 128x24-bits FIFO for data transmit, one 64x24-bits FIFO for data receive
 Programmable FIFO thresholds
 Support Interrupt and DMA
 Two 32-bits Counters for AV sync application

Bon, pour moi c'est un peu de l’hébreu , mais "Configurable Master / Slave Mode opération" et " Support Interrupt and DMA", est-ce à dire qu'on pourra théoriquement gérer l'I2S de l'A10 avec, par exemple, l'interface D-IN et éliminer le problème évoqué par Tazz (clock approximative) du module optimex ? une connexion asynchrone gérée coté D-IN en fait...

[Tazz28]

Oui et non. Le re-sampling asynchrone change rien à l’approximation du bitrate. Pas confondre re-sampling et reclocking. Jouer à 43.xx une truc qui est enregistré à 44.1, ça le fait pas, ASRC ou pas.
La bonne nouvelle c'est Configurable Master / Slave Mode operation
Donc moyennant une clock externe (le D-IN doit pouvoir en partie jouer ce rôle, mais il n'est pas fait pour à la base) on a 4 canaux I2S (8 voies) de dispo avec une bonne fifo de 128 échantillons.
Avec le DSPiy comme on a besoin d'un asrc, si on reste en deux voies, le D-IN suffit, pour plus de deux voies, il faut développer une carte avec soit un SRC4194 , soit quatre CS8421. Et cela aussi bien si on a 4 canaux I2S qu'un unique canal TDM.

Espérons qu'ils soient à 100% exposés.

[robob]

bon, j'essaye de résumer, vous me dites si j'ai compris :
-le DSPiy fonctionne en 96 ou en 48 khz , avec une possibilité d'entrée I2s master mais pas d'ASRC : si on lui balance du 44.1, ça collera pas.
-Tazz propose le D-IN, qui permet d'entrer en SPDIF ou en I2S, intègre un ASRC qui permet de rentrer dans n'importe quel Sample rate. Ceux qui sortent d'un PC en USB vont mettre une interface USB vers I2S, connectée sur le D-IN en I2S. Si l'A10-OLinuXino le permet, on se connecte aussi en I2S sur le D-IN, sans se soucier du sample Rate. Je parlerais de l'A10, des fois que l'A10- olinuxino ne soit pas l'élu mais un autre µPC dans le même genre avec toutes les broches I2S nécessaires exposées.
-L'A10 permet de sortir de L'I2S en mode slave, c'est à dire que l'horloge est externe : le DSPiy possède une entrée I2S master, c'est donc lui qui "donne" l'horloge au D-IN et au A10 (Question : directement ou par l’intermédiaire du D-IN ?).
-Avantage de L'I2S, on travaille avec la même horloge. Question : si on sortait en SPDIF d'un PC ou du µPC et que l'horloge du SPDIF ne soit pas terrible, que se passerait-il au niveau de l'entrée SPDIF du D-IN ?

Multicanal avec un µPC servant de renderer. L'idée étant d'utiliser les 6 voix du DSPiy et les 3 DAC en configuration 5.1 (dans un premier temps) :
-l'A10 permet de sortir les 6 canaux en I2S.
-le DSPiy peut recevoir les 6 canaux en I2S (?).
-Question : si les canaux sortent du A10 dans le bon sample rate, celui utilisé par le DSPiy, est-il nécessaire de développer une carte avec des ASRC ?

[thierryvalk]

Normalement l’I2S c’est 2 canaux, mais il existe le mode TDM qui en fait 8. Et le DSPiy dispose d’une entrée I2S compatible TDM.
Si l’A10 est en slave, pas besoin d’ASRC, et c’est bien le DSP qui donne directement l’horloge, mais faut bien voir si ça fonctionne, vu que la fs est donnée par la source ou par l’encodage du fichier.

[Tazz28]

Si l’A10 est en slave, pas besoin d’ASRC, et c’est bien le DSP qui donne directement l’horloge

A l'unique condition que le fichier soit dans le bon sample-rate ou qu'il y ait conversion à la volée avant de sortir en I2S/TDM.

Mélangez pas la problématique de changement de sample-rate et la problématique d'horloge approximative.
Changement de sample-rate à la volée -> ASRC
Source avec clock approximative -> utilisation/détournement du mode slave pour fournir à la source une horloge plus précise/juste/stable.

[Tazz28]

-L'A10 permet de sortir de L'I2S en mode slave, c'est à dire que l'horloge est externe : le DSPiy possède une entrée I2S master, c'est donc lui qui "donne" l'horloge au D-IN et au A10 (Question : directement ou par l’intermédiaire du D-IN ?).

Le DSPiy "donne" l'horloge à l'asrc qui de toute manière réalise un changement de domaine d'horloge (d'où le "a" pour asynchrone de asrc).
Il y a plusieurs options pour que le D-IN donne l'horloge au A10, en lien ou pas avec le DSPiy, mais c'est pas très optimal, on ne pourra pas gérer toutes les possibilités d'horloge (multiples de 44.1 ou multiples de 48 pas les deux à la fois).
Donc soit horloge programmable i2C genre Si570 soit deux oscillateurs et une inverseuse + GPIO. Cette dernière solution est peut être envisageable sur une D-IN V2, mais pas très universelle, autant le prévoir à part.

-Avantage de L'I2S, on travaille avec la même horloge. Question : si on sortait en SPDIF d'un PC ou du µPC et que l'horloge du SPDIF ne soit pas terrible, que se passerait-il au niveau de l'entrée SPDIF du D-IN ?

Tout dépend de ce que l'on entend pas pas terrible :
- niveau jitter, le D-IN va pas mal nettoyer les choses pour obtenir quelque chose de plus que correct.
- niveau fréquence de base, on est 100% dépendant de l'implémentation dans la source : soit c'est des bitrates conformes et exacts, soit c'est de l’approximatif. Sur tous les chips/soc "de base" ça va être de l’approximatif, d'où ma préférence à de l'I2S en slave d'une clock externe.

Multicanal avec un µPC servant de renderer. L'idée étant d'utiliser les 6 voix du DSPiy et les 3 DAC en configuration 5.1 (dans un premier temps) :
-l'A10 permet de sortir les 6 canaux en I2S.
-le DSPiy peut recevoir les 6 canaux en I2S (?).

Oui, mais comme le dis Thierry, il faut passer en TDM car les ports I2S IN sont utilisés entre autre par les ADC auxiliaires.

-Question : si les canaux sortent du A10 dans le bon sample rate, celui utilisé par le DSPiy, est-il nécessaire de développer une carte avec des ASRC ?

Non en effet. Je vois que tu a bien saisis la chose.

[Tazz28]

Bon j'ai réfléchi au pblm.
J'ai légèrement modifié le D-IN pour pourvoir gérer tous les cas.
C'est un peu tordu car il n'y a pas la place pour mettre deux oscillateurs à moins de tout refaire.
Donc il faut les empiler... c'est un peu délicat à monter, mais ça se fait, même sans pcb d'adaptation.
Également, on est short en GPO, donc une unique gpo commune pour piloter les deux oscilateurs.
Il faut donc un oscillateur avec un output enable niveau haut et un avec le output enable niveau bas.
On peut faire ça avec des Si510

Un Si510 ref 510CBA24M5760AAG pour le 24.576Mhz (+/-25ppm soit grade 50ppm)
Un Si510 ref 510CBB22M5792AAG pour le 22.5792Mhz (+/-25ppm soit grade 50ppm)
Ça coute dans les 4$ pièce commandable chez mouser et fait sur mesure (deux semaines de délais de fabrication).
Ils sont à 0.7ps RMS de jitter.

Avec ça on peu gérer n'importe quel soc du moment que son I2S peu marcher en slave et qu'il a de l'I2C pour piloter le D-IN.
L'avantage est que c'est le D-IN qui dérive automatiquement la bonne bitclock et LRclock.

La modif est mineure donc on peu tester la chose même si le proto est déjà parti en fab.

[Tazz28]

Voilà pour l'adaptateur, pinoches ref 3121-1-00-15-00-00-08-0 chez mouser:

adapt.JPG (13.99 Kio) Vu 1897 fois

[robob]

Bon, reste plus qu'a trouver le µPC qui va bien :

Le A10-olinuxino n'est toujours pas dispo et pas de date prévu. Dans ces commentaires, Olimex confirme la disponibilité de l'I2S, mais toutes les broches sont-elles dispo ?

Olimex va ausi sortir un A10s-olinuxino : Allwinner A10s, donc entre le A10 et a13 d'apres ce que j'ai compris, avec seulement 2 canaux I2S dispos (contre 8 sur le A10), slave/master mode inside.

Sur le github, il y a pas mal de doc dispo, dont le datasheet du a10s et les schématics des 2 boards : pour moi c'est du chinois, peut-être peut-on savoir si les broches I2S seront exposées.

A force de parcourir Internet, je me rends compte que beaucoup recherchent la même chose que nous (I2S) sur les micro PC. Je pense qu'on va donc assez rapidement voir sortir des solutions. De même pour le software, car avoir un µC avec une possibilité de connexion I2S est une chose, mais il reste à le mettre en oeuvre :
-configurer l'I2S
-installer un renderer qui sorte sur l'I2S
-configurer le réseau
-etc...
Je ne connais pas linux, je crois que je vais bien me marrer.