Open philippe44 opened 2 years ago
Bonjour Philippe ! 1-- We already talked about this on your site a long time ago (KheperV3)
2-- Yes, the buttons are indeed created by an NVS variable... 3-- For the battery, we must of course read the value... but we have to link a conditional action (here the color of the Neopixel LED)... 4-- RMT sends the serial signal that turns on the Neopixel(s)
Thanks Philippe !
On va y arriver !
Louis
Hi Louis
1- So it should be fine now b/c the MCLK as an option is also built-in 2- We should see if/how you want that to be integrated. My recommendation is a lock with a special build and so the possibility to have exactly the same through NVS in the I2S build. This is how SqueezeAMP works 3- I might be able to have the built-in code do the averaging. It depends exactly how you want to do it, but today there is already some flexibility - it takes one measure every 10s, scales it and then every 30 counts calls a handler. The idea is that there is a callback void (*battery_handler_svc)(float value) in monitor.h. Just set it with what you want, play nice, meaning that if it is not NULL, chain it. Of course, ultimately that callback is dedicated code, but it can be minimized and identified in a dedicated place 4- so same as 3-
Hi Philippe, So if I understand correctly, the best is to treat it like SqueezeAmp with a specific menuconfig. I agree and I can try to work on it...
In addition - but this is secondary - there are 2 features of Muse that we could try to integrate:
I can take care of the menuconfig and submit a PR, what we'd need to discuss is the rest and maybe how you want the battery calculation to be done. Maybe we can discuss that on gitter
Hi, I'm also interested into the way to use codecs of Squeezelite-ESP32 in another way than lms only. The idea is to keep the squeezelite capabilities but have a more versatile/autonomous player which doesn't necessarily requires lms server to be usable. Read from SD card or USB is an idea, I've also in mind to be able to control the player to read online streams ordered by MQTT (or any other protocol like a web api).
If you look at the latest commit of the cmake version, I've integrated most of Muse components. There is a targets/muse/muse.c file that you need to tweak to your needs, but other than that it seems to work. One thing on my muse is that volume is very low
You just ensured the future firmware updates on the long term 😄 , thanks for the benevolence on the children projects
I start to try to use the "driver" es8388 3 questions/comments: 1- where to put the initialization of MCLK (it's 2 very specific lines)?
2- There is no "volume" sequence in the es8388 driver... I think it's important... because otherwise the adjustment is made by weakening the source... right?
3- I don't see how ".../targets/muse/muse.c" is related to the rest of the processing
...for 1: create an nvs variable "init_MCLK" = 0(default) or 1 ? ...for 2 : add the sequence with .json format or not ?
Look at my latest commitments on the cmake version, I've set it up by using the i2s basic driver and adding all your init sequence. You don't have to do anything in muse.c now
I've "finalized" the updates so now, if that works for you, you should just set adapt the battery logic to your needs. What I don't know is:
[edit]: I've also updated version 4.3 and it works in muse as well (spotify)
I've "finalized" the updates so now, if that works for you, you should just set adapt the battery logic to your needs. What I don't know is:
* how many cells are there * what is the scale factor for a 100% charged battery (on SqueezeAMP there is a divider to maximize ADC range)
Hi, I don't know how many cells there are but there's some common code about batteries in examples : https://github.com/RASPIAUDIO/museProto_radio/blob/4a842f76e6887097a7d916053f73decbfd529404/museProto_radio/museProto_radio.ino#L128
[edit]: I've also updated version 4.3 and it works in muse as well (spotify)
what do you mean by "spotify" ? Spotify Connect ?
Yes, I mean Spotify connect
cspot integration !? Awesome ! I wasn't expecting it, I saw an old issue last days which seems compromising it. Just tested on my ESP32, seems to works fine. An awesome additional point for the ESPMuse Luxe too. By the way @RASPIAUDIO on the main page of the website :
ESP32 programmable to be able to:
Airplay, Bluetooth, Logitech media server, SD card mp3 play
You could add spotify connect now and I think you should write "Squeezebox" instead of lms, philippe44 and sle118 are making exploits on ESP but I don't think that we will see a lms server on ESP one day :p
2- There is no "volume" sequence in the es8388 driver... I think it's important... because otherwise the adjustment is made by weakening the source... right?
On that topic, I've opted for just software volume in general. At the end of the day and in your configuration, you're driving a fixed-gain power amplifier, so all we do is reducing the DAC output excursion. Whether you do that using a real analogue divider or in the digital domain has very limited impact on perceived sound.
Don't get me wrong, I'm not trying to be argumentative and if you prefer to absolutely use what ES8388 calls DAC volume (I'd be curious to know what's really inside), of course please do but then that will be a fork of squeezelite-esp32. Having soft gain is important here as it ensures consistency of VU and spectrum (I did not say precision but just consistency :smile:)
I'm running out of time today and I'll email you a full answer tonight...
It works well... but there are several unresolved points (by me anyway)
For the battery and the led (neopixel) I will detail that later...
Thank you for everything Philippe
Hi, I've just receive my Muse Luxe, I've been surprised to find a simple Bluetooth firmware on it so I've flashed it with Squeezeesp32 quickly. For now to avoid to set everything by hand I've flashed with the bin from this repo and then updated to 4.3 but doesn't seems to work as expected (probably something to change on the DAC config, if you have a good nvs file for 4.3 I'm interested).
@philippe44 "Preset Options" is a very welcome option ! Looking forward finding the Muse Luxe inside.
For information the sound with the firmware from this repo is loud.
I have some observations and remarks about the Muse, I will probably make a post about these on the forum. Do not hesitate if I can help for some tests.
@schmurtzm if you want my build to work, you have to flash everything, not just the squeezelite.bin - you can use "idf.py flash" to do that or if you just have the flash tools, go to LMS forum and find the list and addresses of binaries to update with the GUI downloader
I'm running out of time today and I'll email you a full answer tonight...
It works well... but there are several unresolved points (by me anyway)
there is an error in the "BUILD": i2s.c line 883
the sound is very low
buttons are not taken into account
(I have ideas on these 3 points)
For the battery and the led (neopixel) I will detail that later...
Thank you for everything Philippe
Strange that buttons don't work, what idf version have you chosen? Sound is low, I agree and I was hoping you could tell me why. Wrt i2s.c, it should compile so we may really have different build environment.
@schmurtzm if you want my build to work, you have to flash everything, not just the squeezelite.bin - you can use "idf.py flash" to do that or if you just have the flash tools, go to LMS forum and find the list and addresses of binaries to update with the GUI downloader
Yes that's what I've done with binaries from here :
esptool.exe --baud 921600 write_flash --flash_mode dio --flash_freq 80m --flash_size detect 0x1000 bootloader/bootloader.bin 0x8000 partition_table\partition-table.bin 0xd000 ota_data_initial.bin 0x10000 recovery.bin 0x150000 squeezelite.bin
I think that the problem is more about my I2S configuration after flashing (because it works with the older firmware)
I'll share a build later today because for now, you have to rebuild everything using a dedicated target or you need the new squeezelite generic i2s build that has not been released yet (look at artefacts of actions on GH) and use some specific nvs parameters (see main/Kconfig.projbuild) and look for everything with an "if MUSE" flag, it is mainly dac_config, dac_controller and bat_config.
main/Kconfig.projbuild , good to know ! OK, my config file is ready for Muse, now waiting for the new I2S build. Thanks for your support ! (I have to start learn to build this project but I'm a little afraid by codec compilation 😅 )
Re codecs, the best is to just use the pre-build ones I'm offering. I never rebuild them, they are not part of the build chain
Here is my 4.3 build Muse.zip
I've also added Muse config script in 4.0 and 4.3 so that what I do is more clear
Hi Philippe, did you read my e-mail ?
Here is my 4.3 build Muse.zip
Thank you Philippe, my Muse is currently in 4.3 and working fine (squeezelite,airplay and spotify quickly tested). Now I have a packaged device to make serious tests, thanks both for that ! I didn't found "Preset Options" in your firmware but I presume it is normal because it is a custom firmware.
I think that the sound seems less loud than with Raspiaudio firmware so I presume that the ES8388 is not driven exactly in the same way.
Hi Philippe, did you read my e-mail ?
No I did not, let me check my spam
Here is my 4.3 build Muse.zip
Thank you Philippe, my Muse is currently in 4.3 and working fine (squeezelite,airplay and spotify quickly tested). Now I have a packaged device to make serious tests, thanks both for that ! I didn't found "Preset Options" in your firmware but I presume it is normal because it is a custom firmware.
I think that the sound seems less loud than with Raspiaudio firmware so I presume that the ES8388 is not driven exactly in the same way.
The preset will come later, that's @sle118's realm. I have that same problem of the speaker being to quiet but I've not beena ble to figure out why. Hence I need to talk to @RASPIAUDIO. It's the same dac_controlset
[edit]: was a silly mistake - figured out now
OK, I'm posting the message not received here. (it is encrypted in French!!!) Maybe it would be better to talk about all this face to face... what do you think?
Donc, voilà où j'en suis:
j'utilise la version par défaut de squeezelite et idf 4.0
et je travaille toujours à partir d'une flash remise à zéro (erase_flash)
Sur la version chargée ce matin, je constate :
les boutons ne fonctionnent pas
le son est faible
J'ai essayé de comprendre ce dernier point en supposant que l'essentiel est dans dac_external.c
2 remarques :
1- la validation de MCLK y est bien. Mais il manque l'enable de l'ampli (par le GPIO 21)
la séquence est la suivante (elle est dans muse.c) :
gpio_reset_pin(PA);
gpio_set_direction(PA, GPIO_MODE_OUTPUT);
gpio_set_level(PA, 1);
à moins qu'elle ne se trouve ailleurs....
C'est d'ailleurs bizarre que cela marche un peu sans ça...
2- Et aussi, Dans cette séquence tu cherches le mot clé "model" dans CONFIG_DAC_CONTROLSET où il ne peut être...
Je crois que ça devrait être dans CONFIG_DAC_CONFIG
Je peux me tromper!!! sois indulgent !!!
D'ailleurs, je pense que même si les 2 points + haut sont vrais , il y a autre chose qui ne va pas....
Je continue à travailler sur cette intégration....
Amitiés.
Louis
Regarde la version que j'ai mise à jour tout à l'heure (cmake or cmake.43). Il faut soit utiliser le fichier Muse-sdkconfig.defaults comme config ou faire un idf.py menuconfig et choisir "muse" comme target. Tout devrait builder et plus de problème de volume ou de buttons. La seule chose qui reste à faire c'est la batterie et les led à base de rmt. L'es8388, le pa, la majeure partie du sampling de la batterie sont faits. Tout est configuré dans le menuconfig ou dans le preset Muse-sdkconfig.default. Tu peux aussi utiliser les artifacts du dernier build. Attention, il faut tout charger, bootloader, recovery, etc...
On the version I just downloaded the sound is loud and good but the buttons are still not taken into account... (I continued my research... yesterday I was wrong on some points: MCLK ==> adac_core.c keyword mclk enable amp ==> output_i2s.c i think isn't it? )
oui j'ai fait comme tu dis... Le son est changé du tout au tout Mais les boutons toujours pas Il a aussi l'erreur de build sur i2s.c => adc_power_always_on() pas reconnu que je dois remplacer par adc_power_on() C'est du je pense à un pb entre 4.0 et 4.1
oui je fais toujours un "build all"
Buttons work if I add this in "register_default_nvs()"
char boutons[450];
strcpy(boutons, CONFIG_AUDIO_CONTROLS);
store_nvs_value(NVS_TYPE_STR, "boutons", boutons);
config_set_default(NVS_TYPE_STR, "actrls_config", "boutons", 0);
store_nvs_value(NVS_TYPE_STR,"actrls_config", "boutons");
I hope this helps !
On the version I just downloaded the sound is loud and good
but the buttons are still not taken into account...
(I continued my research... yesterday I was wrong on some points:
MCLK ==> adac_core.c keyword mclk
enable amp ==> output_i2s.c i think
isn't it?
)
Yes, this is where these are set to all codecs or targets that need these
oui j'ai fait comme tu dis...
Le son est changé du tout au tout
Mais les boutons toujours pas
Il a aussi l'erreur de build sur i2s.c => adc_power_always_on() pas reconnu que je dois remplacer par adc_power_on()
C'est du je pense à un pb entre 4.0 et 4.1
Vous êtes sur une 4.1 ? Je ne recommande pas. On supporte deux idf 4.0 et 4.3 mais 4.1 c'est s'exposer à des ennuis. On devrait arrêter bientôt la 4.0 de toutes façons.
Buttons work if I add this in "register_default_nvs()"
char boutons[450]; strcpy(boutons, CONFIG_AUDIO_CONTROLS); store_nvs_value(NVS_TYPE_STR, "boutons", boutons); config_set_default(NVS_TYPE_STR, "actrls_config", "boutons", 0); store_nvs_value(NVS_TYPE_STR,"actrls_config", "boutons");
I hope this helps !
Tu as raison, j'avais oublie de porter une modification qui utiliser la configuration statique des audio controls de 4.0 vers 4.3
OK Super! Pour la batterie, je ne suis pas plus avancé que ce que tu as pu voir dans muse.c : 1- la mesure acquisition périodique ( T= 1sec ou + 5 voire 10sec) moyenne N mesures (10 par exemple) (la valeur brute obtenue < 4095 par principe, 2300 ici pour la batterie à pleine charge) 2- l'action C'est allumer la led neopixel en vert jaune ou rouge suivant la moyenne brute obtenue comparée à 2 seuils (VGREEN et VRED) Ces valeurs ne sont très faciles à déterminer En général, c'est une opération qui n'appelle pas une grande précision je pense...
Je vais passer à la version 4.3 dès demain ou lundi (comme ce n'est pas la version par défaut, il faut passer par le .zip?)
OK Super!
Pour la batterie, je ne suis pas plus avancé que ce que tu as pu voir dans muse.c :
1- la mesure
acquisition périodique ( T= 1sec ou + 5 voire 10sec)
moyenne N mesures (10 par exemple)
(la valeur brute obtenue < 4095 par principe, 2300 ici pour la batterie à pleine charge)
2- l'action
C'est allumer la led neopixel en vert jaune ou rouge suivant la moyenne brute obtenue comparée à 2 seuils (VGREEN et VRED)
Ces valeurs ne sont très faciles à déterminer
En général, c'est une opération qui n'appelle pas une grande précision je pense...
Je vais passer à la version 4.3 dès demain ou lundi (comme ce n'est pas la version par défaut, il faut passer par le .zip?)
Par défaut, le système build-in fait une mesure toutes les 10s et fait un appel de la callback toutes 5 mins. Mais la valeur retournée dépend d'un scaling factor: lecteurs de l'ADC, multipliée par scaling factor pour normaliser en volts 0. Ensuite, le nombre cellules de LiIon permet de laisser le core faire une évaluation pour la webUI. Donc la question est : quel scaling pour avoir Volts = adc scaling / 4095. Sachant que vous utiliser une valeur d'atténuation adc esp32 qui est prise en compte dans bat_config, donc scaling est juste vraiment le facteur multiplicateur pour avoir des volts à partir de la lecture de l'adc. Si 2300 est votre max et que vous avez une cellule à 4.2, alors scaling = 4.24095/2300=7.48 Mais je ne sais pas si vous avez 1, 2 ou 3 cells et si vous souhaitez le max a 4.2, 4.3 ou 4.4
Ensuite, vous pouvez avoir votre propre solution pour transformer ces volts en N niveaux
Je ne suis pas sûr de bien comprendre la question sur 4.3. Il faut juste faire un checkout du dernier idf stable, 4.3.2
ma question n'était pas sur l'idf 4.3 , mais sur la version squeezelite à charger et comment la charger : qd je fais "git clone...." je récupère la version par défaut et non une version 4.3 (il doit y avoir qq chose d'éléméntaire que je ne sais pas faire...)
Pour la batterie, il faut que j'en parle avec Olivier. Ce qui est sûr c'est qu'il y a 1 cell. A+
Effectivement pour squeezelite si tu veux la branche qui contient cspot et qui correspond à idf 4.3 if faut faire un checkout de "master-v4.3".
Pour la battery, j'ai mis le coefficient qui correspond à 4.2v = 2300 sur le DAC et une cellule et ça a l'air cohérent
J'ai fait les changements pour intégrer la visualisation de la batterie, mais ça n'a pas l'air de marcher. Je te laisser regarder
OK je regarde ça au plus vite et je te tiens au courant (=> lundi)
Par ailleurs, j'ai bien du mal à récupérer la version master-v4.3... en gros j'utilise "git checkout" depuis le repo de la version par défaut... mais ça ne marche pas Comme je ne l'ai jamais utilisé, je suis bloqué. Si tu peux me donner la marche à suivre...
Tu as cloné la repository d'abord have un "git clone submodule --recursive" (vérifie la syntaxe, je me trompe toujours) ? Ensuite un "git checkout master-v4.3" devrait te donner notre base.
merci... c'est : git clone --recurse-submodules -j8 http.....
le point du jour: 1- il y a une petite erreur dans CONFIG_AUDIO_CONTROLS il faudrait remplacer \"longpress\":1000 par \"long_press\":1000 sinon l'appui long sur le bouton central ne marche pas (c'est moi qui est fait cette erreur au départ!)
2- Pour la batterie Pour passer des mesures brutes aux valeurs physiques il faudrait je crois:
J'ai quand même vérifié que tout marchait bien à part ce point:
Il a aussi le fait que la led ne s'allume qu'au bout 5mn (30 * 10 sec) Il faudrait peut-être faire un appel à battery_svc() des le démarrage
Je vais regarder mais je ne comprends pas ce que l'utilisation de valeurs brutes change. Les logs montrent bien qu'on reçoit une valeur bien convertie dans muse.c mais dans mon cas la led ne s'allume pas hors, quelle que soit la valeur, on devrait avoir une couleur.
Je préfère rester en valeur convertie car ça permet aussi d'indiquer une valeur réelle à LMS.
Pour le démarrage tu as raison, il faut une valeur initiale.
Là, il y a peut être un autre problème; ce que j'ai constaté moi avec ta version d'hier sans modification : la led s'allume en rouge mais au bout de 300sec Et c'est logique car la mise à l'échelle étant fausse ça ramème une valeur de 0.57 V qui est inférieure à VRED
Oui je suis d'accord pour rester en valeurs physiques c'est plus général et ça te permet d'intégrer d'autres cas...
Je m'y remets demain... je te tiens au courant
Tu peux me donner le code que tu utilises ? Je pense que ta version n'a pas la remise à échelle corrigée par ça me donne bien 4.4V, pas 0.6. C'est dans le dernier Kproject.build
I had a look at the changes