Le Topic de la Squeezebox Touch de Logitech

[Pilru]

Même si FLAC est « asymétrique » (il va beaucoup plus vite en lecture), la grande complexité des fichiers -8 finit par avoir un impact négatif en lecture.

Ah bon ? Quel est l'impact ?

[Gandalflux]

que le CPU en charge de la décompression ne suffise pas comme sur certain périphérique portable ou sur le Transporter !

[Pilru]

D'après http://flac.sourceforge.net/features.html

Fast: FLAC is asymmetric in favor of decode speed. Decoding requires only integer arithmetic, and is much less compute-intensive than for most perceptual codecs. Real-time decode performance is easily achievable on even modest hardware.

Sur mon ReadyNAS DUO (une brouette, donc), le % CPU utilisé par flac pour décoder un fichier stéréo à 44.1kz et encoder avec le flag --best, ne dépasse pas 10% (de mémoire).
Sur la Touch idem, par remarqué non plus de pic d'usage du CPU lors du décodage d'un fichier FLAC.

[Gandalflux]

Prend un Archos, un baladeur Sony ou ce genre de truc et tu verra

[Pilru]

Pour compléter, cette page http://flac.sourceforge.net/comparison_all_cpudectime.html montre qu'entre un encodage -0 et un encodage -8 le gain de place reste assez marginal et le temps CPU nécessaire pour le décodage reste assez stable.

[Pilru]

Prend un Archos, un baladeur Sony ou ce genre de truc et tu verra

J'ai un iRiver H340 et il bouffe mes flac -8 sans problème.

[Gandalflux]

moi j'dis ça j'dis rien j'ai lue sur pas mal de forum que le 8 pouvait crée pb et que al diff entre temps de création FLAC, gain de place, risque de pb de lecture n'étais aps en faveur du -8. Et que le -6 étais avais un très bon rapports.


Après chacun fais comme il veut on est d'accord

[sebp]

Sur Touch idem, par remarqué de pic d'usage du CPU lors du décodage d'un fichier FLAC.

Les problèmes évoqués ici ne concernent que la lecture de fichiers FLAC 24/96 sur Transporter et Touch.

Les Squeezebox n'auront sans doute aucun mal à lire des fichiers 16/44,1 ou 24/48 encodés en niveau 8, mais il existe incontestablement des cas de figure où leurs processeurs embarqués sont trop justes pour suivre le rythme avec des fichiers 24/96 : cf. le lien que j'ai donné ou l'expérience de pem avec ses fichiers 5.1.
Dans le lien que j'ai donné, les utilisateurs de Transporter indiquent clairement que le réencodage des fichiers qui leur posaient problème à un niveau de compression inférieur a suffit à résoudre leurs problèmes de lecture.

C'est donc bien la preuve que cet écart "négligeable" ne l'est pas tant que ça ...

[Pilru]

Les problèmes évoqués ici ne concernent que la lecture de fichiers FLAC 24/96 sur Transporter et Touch.

Précisions importante.

moi j'dis ça j'dis rien j'ai lue sur pas mal de forum que le 8 pouvait crée pb et que al diff entre temps de création FLAC, gain de place, risque de pb de lecture n'étais aps en faveur du -8. Et que le -6 étais avais un très bon rapports.

J'ai eu aussi quelques soucis de lecture, fut un temps. Mais c'était uniquement en utilisant Amarok qui refusait de lire certains fichiers. Ces mêmes fichiers était parfaitement lus en utilisant un autre media player. Si je réencodais un fichier problèmatique sur un taux compression inférieurs, Amarok le lisait sans problème.
Tout ceci pour dire que l'environnement logiciel, les librairies d'abstractions peuvent jouer bien plus de tour que le simple taux de compression utilisé.

[Pilru]

Dans le lien que j'ai donné, les utilisateurs de Transporter indiquent clairement que le réencodage des fichiers qui leur posaient problème à un niveau de compression inférieur a suffit à résoudre leurs problèmes de lecture.

Un intervenant indique que le problème était aussi résolu en faisant décoder le fichier sur le serveur et non plus localement sur le Transporter. Le taux de compression n'est donc pas le problème.

Sachant que sur la Touch ce n'est pas flac qui est utilisé nativement pour décoder (aucun processus flac n'apparait lors de la lecture d'un morceau), j'imagine que sur Transporter c'est pareil. Le problème se loge sans doute dans l'implémentation de décodage mis en place.

[pem]

Sur Touch idem, par remarqué de pic d'usage du CPU lors du décodage d'un fichier FLAC.

Les problèmes évoqués ici ne concernent que la lecture de fichiers FLAC 24/96 sur Transporter et Touch.

Les Squeezebox n'auront sans doute aucun mal à lire des fichiers 16/44,1 ou 24/48 encodés en niveau 8, mais il existe incontestablement des cas de figure où leurs processeurs embarqués sont trop justes pour suivre le rythme avec des fichiers 24/96 : cf. le lien que j'ai donné ou l'expérience de pem avec ses fichiers 5.1.

Perso, je ne suis pas sur que pour le coup , c'était un fichier compressé en niveau 8 (fichier de test) ...
Je pense plutôt que c'est la SBT qui atteint ses limites (CPU) avec l'envoi d'un fichier 5.1 en 24/96 avec le Vu-Metre ou l'analyseur de spectre.
En affichage standard (pochette + titre) pas de problème.

[pem]

Un intervenant indique que le problème était aussi résolu en faisant décoder le fichier sur le serveur et non plus localement sur le Transporter. Le taux de compression n'est donc pas le problème.

Si un peu quand même ... si tu décodes sur le serveur, c'est le CPU du serveur qui est utilisé, pas celui du transporteur.
Même si le temps de décompression supplémentaire est "négligeable", si tu étais limite en niveau 7, tu peux dépasser cette limite en 8.
La goutte d'eau qui fait déborder le vase ^^

[sebp]

Sachant que sur la Touch ce n'est pas flac qui est utilisé nativement pour décoder (aucun processus flac n'apparait lors de la lecture d'un morceau), j'imagine que sur Transporter c'est pareil. Le problème se loge sans doute dans l'implémentation de décodage mis en place.

Pourquoi voudrais-tu que la Touch exécute explicitement la commande flac pour décoder les flux, alors que tout le nécessaire au décodage (et à l'encodage) est fourni dans la bibliothèque libflac (en v1.2.1 pour tout ce qui tourne sous SqueezePlay, je viens de le voir dans les sources) ?

Le cas du transcodage de flux par le Squeezebox Server est particulier, et pas du tout représentatif de ce qui se passe dans les Squeezebox elles mêmes ...

[sebp]

Perso, je ne suis pas sur que pour le coup , c'était un fichier compressé en niveau 8 (fichier de test) ...

Je le sais bien, j'essayais juste d'expliquer que dans certaines circonstances un peu extrêmes, le processeur embarqué dans les Squeezebox n'arrivait plus à suivre.
Même si le processeur de la Touch est bien plus puissant que celui du Transporter, il est évident qu'il a ses propres limites, et qu'il convient de ne pas les dépasser pour profiter convenablement du système.

[Pilru]

Sachant que sur la Touch ce n'est pas flac qui est utilisé nativement pour décoder (aucun processus flac n'apparait lors de la lecture d'un morceau), j'imagine que sur Transporter c'est pareil. Le problème se loge sans doute dans l'implémentation de décodage mis en place.

Pourquoi voudrais-tu que la Touch exécute explicitement la commande flac pour décoder les flux, alors que tout le nécessaire au décodage (et à l'encodage) est fourni dans la bibliothèque libflac (en v1.2.1 pour tout ce qui tourne sous SqueezePlay, je viens de le voir dans les sources) ?

Le cas du transcodage de flux par le Squeezebox Server est particulier, et pas du tout représentatif de ce qui se passe dans les Squeezebox elles mêmes ...

CQFD : Le problème est, à mon avis, plus à chercher dans l'implementation du décodage qui a été faite autour de libflac. Mes problèmes avec Amarok prouvent bien que sur une même machine, un logiciel peut rencontrer un problème pour lire un fichier flac, alors qu'un autre le lira sans soucis.

S'il y a un problème de CPU pas assez puissant, autant le vérifier : Se connecter en ssh sur la Touch, lancer top et ensuite lire le morceau 24/96. Mais s'il sagit d'un problème de CPU, le fichier serait, prirori décodé correctement, il y aurait des coupures de sons...