Je ne pense pas que le sujet ait déjà été abordé ici.
Pour envoyer de la musique depuis une source informatique, on peut
apparemment utiliser le système de transmission Bluetooth.
Il faut que la chaine soit équipée d'un récepteur, par exemple ceci :
http://www.sonymobile.com/fr/products/accessories/bluetooth-music-receiver-bm10/
Et il faut que la source (PC, smartphone, tablette...) soit capable
d'émettre, ce qui est soit présent nativement dans l'appareil, soit
soit
ajouté, par exemple avec un dongle USB.
Si l'appareil est aussi équipé du wi-fi, il peut accéder à toutes
sortes
de sources, soit locales (p.ex. un nas) ou à distance (spotify ou
autres).
Comparé à d'autres appareils comme exemple un disque dur multimédia, ce
système a l'avantage de pouvoir se passer de la télévision, puisque
l'affichage de l'interface se fait sur le téléphone ou la tablette. Ca
s'intègre donc plus facilement dans un système purement stéréo.
Mais cela pose quand même quelques questions.
1) Est-ce que le protocole Bluetooth permet de transmettre de la
musique
proprement, sans endommager le signal ? Même sous forme numérique, cela
peut être problématique, par exemple à cause de désaccord entre
fréquences utilisées. Voir par exemple l'USB.
2) Le récepteur va devoir transformer ça en signal analogique à
injecter
dans l'ampli. Donc il faudra qu'il soit équipé d'un convertisseur N/A
convenable. Quel modèle choisir ? A moins qu'il existe des modèles qui
sortent le signal en SPDIF, qu'on peut ensuite convertir dans un autre
appareil, équipé d'un convertisseur correct ?
3) J'ai vu fonctionner ce système avec une tablette Apple et un
récepteur audio Bluetooth Logitech. Lorsque la tablette détecte la
présence du récepteur audio, elle envoie automatiquement le signal
audio vers le flux bluetooth. Est-ce qu'un système équivalent existe
aussi sous Windows 8 ?
Y-a-t'il déjà ici des gens qui ont expérimenté ce système ?
C'est visiblement un codec qui a avait prévu pour permettre à des appareils mobiles très peu puissants d'encoder et streamer en temps réel. Aujourd'hui ça parait évident, mais il y a quelques années ça ne l'était pas. D'où le "low complexity" : codec nécessitant peu de calculs, mais moins qualitatif qu'un codec MP3 au même débit.
ça semble logique. merci pour toutes ces précisions.
Ceci dit en y réfléchissant le travail d'encodage/décodage doit être effectué par la puce bluetooth et câblé en dur... Bon, ça ne change pas grand-chose, le but devait être de faire une puce simple, pas chère, consommant peu.
Le 15/02/2014 19:24, Alf92 a écrit :
C'est visiblement un codec qui a avait prévu pour permettre à des
appareils mobiles très peu puissants d'encoder et streamer en temps
réel. Aujourd'hui ça parait évident, mais il y a quelques années ça ne
l'était pas. D'où le "low complexity" : codec nécessitant peu de
calculs, mais moins qualitatif qu'un codec MP3 au même débit.
ça semble logique.
merci pour toutes ces précisions.
Ceci dit en y réfléchissant le travail d'encodage/décodage doit être
effectué par la puce bluetooth et câblé en dur... Bon, ça ne change pas
grand-chose, le but devait être de faire une puce simple, pas chère,
consommant peu.
C'est visiblement un codec qui a avait prévu pour permettre à des appareils mobiles très peu puissants d'encoder et streamer en temps réel. Aujourd'hui ça parait évident, mais il y a quelques années ça ne l'était pas. D'où le "low complexity" : codec nécessitant peu de calculs, mais moins qualitatif qu'un codec MP3 au même débit.
ça semble logique. merci pour toutes ces précisions.
Ceci dit en y réfléchissant le travail d'encodage/décodage doit être effectué par la puce bluetooth et câblé en dur... Bon, ça ne change pas grand-chose, le but devait être de faire une puce simple, pas chère, consommant peu.
RVG
Le 15/02/2014 11:59, pehache a écrit :
Le 14/02/2014 23:45, Gerald a écrit :
pehache wrote:
Ce que je veux dire, c'est que si à l'époque Apple s'était "emparé" du FLAC (ce qui était possible, puisque c'est du libre) au lieu de développer et pousser l'ALAC, le FLAC serait aujourd'hui le standard de fait
Ça c'est très vrai et très regrettable, d'autant qu'ils avaient bien commencé dans d'autres domaines (MPEG).
Note qu'il y a eu des cas où ils ont aussi pris un pari sur l'avenir : mise en oeuvre des protocoles wifi "n" puis "ac" avant qu'ils soient généralisés ni même standardisés, de l'AAC, du Firewire... même l'USB était exotique quand ils l'ont installé en série sur les premiers iMacs...
Que ce soit l'USB, le FireWire, les Wifi n et ac, l'AAC, il s'agissait de normes impliquant des consortiums de fabricants et/ou des organismes tiers, normes soit déjà publiées soit bien avancées. Donc pas comparables au cas d'un format propriétaire développé par un fabricant unique dans son coin.
Et il y a eu des ratés. Je me souviens de lecteurs ioméga de série sur les Powermac G3 destinés à remplacer les disquettes à terme... vite tombés dans l'oubli.
Dans le cas de l'ALAC je soupçonne une histoire de DRM plutôt qu'une histoire propriétaire... Le FLAC permettait-il ce contrôle ?
Probablement pas. C'est sans doute une explication possible. Encore un effet néfaste des DRM.
Flac est un format ouvert et libre, comme Ogg. AAC est devenu la norme de l'industrie audiovisuelle (BluRay vidéos et audios) justement parce qu'il peut intégrer des DRM...
Ce que je veux dire, c'est que si à l'époque Apple s'était
"emparé" du FLAC (ce qui était possible, puisque c'est du libre)
au lieu de développer et pousser l'ALAC, le FLAC serait
aujourd'hui le standard de fait
Ça c'est très vrai et très regrettable, d'autant qu'ils avaient
bien commencé dans d'autres domaines (MPEG).
Note qu'il y a eu des cas où ils ont aussi pris un pari sur
l'avenir : mise en oeuvre des protocoles wifi "n" puis "ac" avant
qu'ils soient généralisés ni même standardisés, de l'AAC, du
Firewire... même l'USB était exotique quand ils l'ont installé en
série sur les premiers iMacs...
Que ce soit l'USB, le FireWire, les Wifi n et ac, l'AAC, il
s'agissait de normes impliquant des consortiums de fabricants et/ou
des organismes tiers, normes soit déjà publiées soit bien avancées.
Donc pas comparables au cas d'un format propriétaire développé par un
fabricant unique dans son coin.
Et il y a eu des ratés. Je me souviens de lecteurs ioméga de série
sur les Powermac G3 destinés à remplacer les disquettes à terme...
vite tombés dans l'oubli.
Dans le cas de l'ALAC je soupçonne une histoire de DRM plutôt
qu'une histoire propriétaire... Le FLAC permettait-il ce contrôle
?
Probablement pas. C'est sans doute une explication possible. Encore
un effet néfaste des DRM.
Flac est un format ouvert et libre, comme Ogg.
AAC est devenu la norme de l'industrie audiovisuelle (BluRay vidéos et
audios) justement parce qu'il peut intégrer des DRM...
Ce que je veux dire, c'est que si à l'époque Apple s'était "emparé" du FLAC (ce qui était possible, puisque c'est du libre) au lieu de développer et pousser l'ALAC, le FLAC serait aujourd'hui le standard de fait
Ça c'est très vrai et très regrettable, d'autant qu'ils avaient bien commencé dans d'autres domaines (MPEG).
Note qu'il y a eu des cas où ils ont aussi pris un pari sur l'avenir : mise en oeuvre des protocoles wifi "n" puis "ac" avant qu'ils soient généralisés ni même standardisés, de l'AAC, du Firewire... même l'USB était exotique quand ils l'ont installé en série sur les premiers iMacs...
Que ce soit l'USB, le FireWire, les Wifi n et ac, l'AAC, il s'agissait de normes impliquant des consortiums de fabricants et/ou des organismes tiers, normes soit déjà publiées soit bien avancées. Donc pas comparables au cas d'un format propriétaire développé par un fabricant unique dans son coin.
Et il y a eu des ratés. Je me souviens de lecteurs ioméga de série sur les Powermac G3 destinés à remplacer les disquettes à terme... vite tombés dans l'oubli.
Dans le cas de l'ALAC je soupçonne une histoire de DRM plutôt qu'une histoire propriétaire... Le FLAC permettait-il ce contrôle ?
Probablement pas. C'est sans doute une explication possible. Encore un effet néfaste des DRM.
Flac est un format ouvert et libre, comme Ogg. AAC est devenu la norme de l'industrie audiovisuelle (BluRay vidéos et audios) justement parce qu'il peut intégrer des DRM...
C'est visiblement un codec qui a avait prévu pour permettre à des appareils mobiles très peu puissants d'encoder et streamer en temps réel. Aujourd'hui ça parait évident, mais il y a quelques années ça ne l'était pas. D'où le "low complexity" : codec nécessitant peu de calculs, mais moins qualitatif qu'un codec MP3 au même débit.
ça semble logique. merci pour toutes ces précisions.
Ceci dit en y réfléchissant le travail d'encodage/décodage doit être effectué par la puce bluetooth et câblé en dur... Bon, ça ne change pas grand-chose, le but devait être de faire une puce simple, pas chère, consommant peu.
le codec utilisé a t-il un rapport avec les profils Bluetooth HSP, HFP, A2DP et AVRCP ?
pehache <pehache.7@gmail.com> a formulé :
Le 15/02/2014 19:24, Alf92 a écrit :
C'est visiblement un codec qui a avait prévu pour permettre à des
appareils mobiles très peu puissants d'encoder et streamer en temps
réel. Aujourd'hui ça parait évident, mais il y a quelques années ça ne
l'était pas. D'où le "low complexity" : codec nécessitant peu de
calculs, mais moins qualitatif qu'un codec MP3 au même débit.
ça semble logique.
merci pour toutes ces précisions.
Ceci dit en y réfléchissant le travail d'encodage/décodage doit être effectué
par la puce bluetooth et câblé en dur... Bon, ça ne change pas grand-chose,
le but devait être de faire une puce simple, pas chère, consommant peu.
le codec utilisé a t-il un rapport avec les profils Bluetooth HSP, HFP,
A2DP et AVRCP ?
C'est visiblement un codec qui a avait prévu pour permettre à des appareils mobiles très peu puissants d'encoder et streamer en temps réel. Aujourd'hui ça parait évident, mais il y a quelques années ça ne l'était pas. D'où le "low complexity" : codec nécessitant peu de calculs, mais moins qualitatif qu'un codec MP3 au même débit.
ça semble logique. merci pour toutes ces précisions.
Ceci dit en y réfléchissant le travail d'encodage/décodage doit être effectué par la puce bluetooth et câblé en dur... Bon, ça ne change pas grand-chose, le but devait être de faire une puce simple, pas chère, consommant peu.
le codec utilisé a t-il un rapport avec les profils Bluetooth HSP, HFP, A2DP et AVRCP ?
pehache
Le 20/03/2014 13:05, Alf92 a écrit :
pehache a formulé :
Le 15/02/2014 19:24, Alf92 a écrit :
C'est visiblement un codec qui a avait prévu pour permettre à des appareils mobiles très peu puissants d'encoder et streamer en temps réel. Aujourd'hui ça parait évident, mais il y a quelques années ça ne l'était pas. D'où le "low complexity" : codec nécessitant peu de calculs, mais moins qualitatif qu'un codec MP3 au même débit.
ça semble logique. merci pour toutes ces précisions.
Ceci dit en y réfléchissant le travail d'encodage/décodage doit être effectué par la puce bluetooth et câblé en dur... Bon, ça ne change pas grand-chose, le but devait être de faire une puce simple, pas chère, consommant peu.
le codec utilisé a t-il un rapport avec les profils Bluetooth HSP, HFP, A2DP et AVRCP ?
A priori pas directement, non.
Le 20/03/2014 13:05, Alf92 a écrit :
pehache <pehache.7@gmail.com> a formulé :
Le 15/02/2014 19:24, Alf92 a écrit :
C'est visiblement un codec qui a avait prévu pour permettre à des
appareils mobiles très peu puissants d'encoder et streamer en temps
réel. Aujourd'hui ça parait évident, mais il y a quelques années ça ne
l'était pas. D'où le "low complexity" : codec nécessitant peu de
calculs, mais moins qualitatif qu'un codec MP3 au même débit.
ça semble logique.
merci pour toutes ces précisions.
Ceci dit en y réfléchissant le travail d'encodage/décodage doit être
effectué par la puce bluetooth et câblé en dur... Bon, ça ne change
pas grand-chose, le but devait être de faire une puce simple, pas
chère, consommant peu.
le codec utilisé a t-il un rapport avec les profils Bluetooth HSP, HFP,
A2DP et AVRCP ?
C'est visiblement un codec qui a avait prévu pour permettre à des appareils mobiles très peu puissants d'encoder et streamer en temps réel. Aujourd'hui ça parait évident, mais il y a quelques années ça ne l'était pas. D'où le "low complexity" : codec nécessitant peu de calculs, mais moins qualitatif qu'un codec MP3 au même débit.
ça semble logique. merci pour toutes ces précisions.
Ceci dit en y réfléchissant le travail d'encodage/décodage doit être effectué par la puce bluetooth et câblé en dur... Bon, ça ne change pas grand-chose, le but devait être de faire une puce simple, pas chère, consommant peu.
le codec utilisé a t-il un rapport avec les profils Bluetooth HSP, HFP, A2DP et AVRCP ?
A priori pas directement, non.
Alf92
pehache :
Alf92 :
pehache :
Alf92 :
C'est visiblement un codec qui a avait prévu pour permettre à des appareils mobiles très peu puissants d'encoder et streamer en temps réel. Aujourd'hui ça parait évident, mais il y a quelques années ça ne l'était pas. D'où le "low complexity" : codec nécessitant peu de calculs, mais moins qualitatif qu'un codec MP3 au même débit.
ça semble logique. merci pour toutes ces précisions.
Ceci dit en y réfléchissant le travail d'encodage/décodage doit être effectué par la puce bluetooth et câblé en dur... Bon, ça ne change pas grand-chose, le but devait être de faire une puce simple, pas chère, consommant peu.
le codec utilisé a t-il un rapport avec les profils Bluetooth HSP, HFP, A2DP et AVRCP ?
A priori pas directement, non.
je déterre ce thread car je viens d'acheter un bidule Bluetooth à 4euros sur ebay comme celui-ci : http://ci.lnwfile.com/_/ci/_raw/6c/rt/cd.jpg
résultat : à l'écoute sur une vraie chaine hifi, pas de différence notable de qualité sonore entre la sortie casque et le bluetooth de ma source (Samsung Galaxy Ace / MP3 128kbps). => satisfait du produit.
pehache :
Alf92 :
pehache :
Alf92 :
C'est visiblement un codec qui a avait prévu pour permettre à des
appareils mobiles très peu puissants d'encoder et streamer en temps
réel. Aujourd'hui ça parait évident, mais il y a quelques années ça ne
l'était pas. D'où le "low complexity" : codec nécessitant peu de
calculs, mais moins qualitatif qu'un codec MP3 au même débit.
ça semble logique.
merci pour toutes ces précisions.
Ceci dit en y réfléchissant le travail d'encodage/décodage doit être
effectué par la puce bluetooth et câblé en dur... Bon, ça ne change
pas grand-chose, le but devait être de faire une puce simple, pas
chère, consommant peu.
le codec utilisé a t-il un rapport avec les profils Bluetooth HSP, HFP,
A2DP et AVRCP ?
A priori pas directement, non.
je déterre ce thread car je viens d'acheter un bidule Bluetooth à
4euros sur ebay comme celui-ci :
http://ci.lnwfile.com/_/ci/_raw/6c/rt/cd.jpg
résultat : à l'écoute sur une vraie chaine hifi, pas de différence
notable de qualité sonore entre la sortie casque et le bluetooth de ma
source (Samsung Galaxy Ace / MP3 128kbps).
=> satisfait du produit.
C'est visiblement un codec qui a avait prévu pour permettre à des appareils mobiles très peu puissants d'encoder et streamer en temps réel. Aujourd'hui ça parait évident, mais il y a quelques années ça ne l'était pas. D'où le "low complexity" : codec nécessitant peu de calculs, mais moins qualitatif qu'un codec MP3 au même débit.
ça semble logique. merci pour toutes ces précisions.
Ceci dit en y réfléchissant le travail d'encodage/décodage doit être effectué par la puce bluetooth et câblé en dur... Bon, ça ne change pas grand-chose, le but devait être de faire une puce simple, pas chère, consommant peu.
le codec utilisé a t-il un rapport avec les profils Bluetooth HSP, HFP, A2DP et AVRCP ?
A priori pas directement, non.
je déterre ce thread car je viens d'acheter un bidule Bluetooth à 4euros sur ebay comme celui-ci : http://ci.lnwfile.com/_/ci/_raw/6c/rt/cd.jpg
résultat : à l'écoute sur une vraie chaine hifi, pas de différence notable de qualité sonore entre la sortie casque et le bluetooth de ma source (Samsung Galaxy Ace / MP3 128kbps). => satisfait du produit.
