qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
17.96k stars 38.6k forks source link

[Bug] Preonic startup sound broken after firmware update #14242

Open sbmueller opened 3 years ago

sbmueller commented 3 years ago

After updating my fork of qmk_firmware after a long time and re-flashing, the startup sound of my preonic doesn't work anymore. Other sounds work.

Describe the Bug

I have set in rules.mk:

AUDIO_ENABLE = yes

and in config.h:

#ifdef AUDIO_ENABLE
    #define STARTUP_SONG SONG(PREONIC_SOUND)
    // #define STARTUP_SONG SONG(NO_SOUND)

    #define DEFAULT_LAYER_SONGS { SONG(QWERTY_SOUND), \
                                  SONG(COLEMAK_SOUND), \
                                  SONG(DVORAK_SOUND) \
                                }
#endif

In the past this was sufficient to get the startup sound when connecting the keyboard via USB. Now, I don't hear a sound. I can manually press the key for "AUD_ON" and get a audible feedback for that press, but startup sound is not enabled.

System Information

Additional Context

I did not update my firmware since about spring this year. I did not need AUDIO_ENABLE = yes in my rules.mk back then, startup sound worked out of the box.

Cipulot commented 3 years ago

Hi @sbmueller , I had the same problem with the same board but using QMK WSL. I ended up flashing this fimware to clear eeprom. I then proceeded to recompile mine and flash it to my board. After doing that the startup sound worked as before.

EDIT: it seems that the problem appears at random..... I just compiled the firmware after a keymap change and it doens't work anymore. Imediately after the flashing process is done, andd the board reset itselfs the sound is reproduced. If I unplug and plug in the board it makes a really short, single noted, sound, all the other sounds works as expected tho.

hobby-grade commented 3 years ago

I had this issue on a Planck, and while troubleshooting a different issue, this seemed to solve the issue. Does this have any effect on your Preonic?

amadeus commented 3 years ago

It does not appear to fix my planck, which has this issue (startup song still does not play)

Cipulot commented 3 years ago

It does not appear to fix my planck, which has this issue (startup song still does not play)

Same here, in both my prepnic rev3 and planck rev6. My bootmagic is set to lite on both

hobby-grade commented 3 years ago

It does not appear to fix my planck, which has this issue (startup song still does not play)

Same here, in both my prepnic rev3 and planck rev6. My bootmagic is set to lite on both

~Well in my solution the flag was set to yes and not lite. Is this what you tried?~

I just tried this with a build of the default firmware, and it works when the board reconnects to the QMK toolbox, but then after that it seems to stop working, as was stated above.

sbmueller commented 2 years ago

I also can confirm I hear a sound occasionally without re-flashing anything. But most times, I don't.

Cipulot commented 2 years ago

This isn't the first time that happens. Seems independent to which platform you're compiling on too...

ReVanTis commented 2 years ago

I fixed it by adding "#define AUDIO_INIT_DELAY" in my keymap's config.h, like this: https://github.com/ReVanTis/preonic_qmk/commit/50e021c43e8a2fb3f21e434dfb1ca60aece3d714#diff-dba8f2421d03ea929e7f78c769eaa4046472804b124eff804aa9b0c0ecdb9603R4

It seems to move audio_startup() from audio_init(): https://github.com/qmk/qmk_firmware/blob/f061ca497464fe85284906fb163a33eaee7a91ef/quantum/audio/audio.c#L143 to a later place at matrix_scan_quantum(): https://github.com/qmk/qmk_firmware/blob/f061ca497464fe85284906fb163a33eaee7a91ef/quantum/quantum.c#L401

Not an expert, nor do I understand why, but this solves my issue.

Edit: misread the code and found there's no need to define a value for AUDIO_INIT_DELAY, only defining it is enough...

Cipulot commented 2 years ago

I can confirm that @ReVanTis addition of #define AUDIO_INIT_DELAY into config.h works. Tested on both Planck Rev6 and Preonic Rev3.

ReVanTis commented 2 years ago

Thanks for the confirmation @Cipulot ! Thus I believe this seems to be more like a workaround than the fix. Something low-level has changed thus start-up song does not play correctly in audio_init() and requires a bit of delay. The macro is mysteriously introduced by @drashna with https://github.com/qmk/qmk_firmware/pull/13606 .

sbmueller commented 2 years ago

After some days I noticed that even with @ReVanTis 's fix my Preonic doesn't reliably play the startup sound. It seems to work most of the time though.

Cipulot commented 2 years ago

I've noticed the same in some occasions. Tho I think that my case has more to do with the establishment of a correct USB connection. I should do some more testing adding WAIT_FOR_USB.... I'll keep updated on my case

ReVanTis commented 2 years ago

Hi @sbmueller @Cipulot ,

I guess a working host is required because the audio startup sound plays in matrix scan now, not right after audio init stage.

I've done a very simple test to connect preonic with a usb charger, and it actually fails to play the sound nor does the led lights up. It might relates to recent changes of refactoring audio and lighting system because I somehow remember both led and audio worked when connected to a simple charger quite a long time ago (might be 1-2 years ago).

Cipulot commented 2 years ago

It might very well be that my usb hub acts a bit weird and therefore powers up the board without actually initializing the USB connection. I've had some cases in which USB hubs, especially during startup of the pc, seems to have a "delay" after power before initializing the USB connection. For that I'm going to directly connect the board to the pc so that I can eliminate this possible source of error. Again I'll keep updated on the development...

JuanGarcia345 commented 2 years ago

I'm not sure that this may be of any help but it seems that the it was the commit a3cbc8a004 which broke the startup sound (tested with a preonic and a planck)

RobTheFiveNine commented 2 years ago

After some days I noticed that even with @ReVanTis 's fix my Preonic doesn't reliably play the startup sound. It seems to work most of the time though.

I am noticing the same thing - tried reconnecting a few times to test and it sporadically doesn't work

drashna commented 2 years ago

does #define AUDIO_INIT_DELAY help?

RobTheFiveNine commented 2 years ago

does #define AUDIO_INIT_DELAY help?

Yeah, it seems to work most of the time, there was a few times it didn't, but I've not been able to replicate it since originally commenting on here.

theamarin commented 1 year ago

This problem still appears with my planck/rev5 using latest qmk versions. On USB plug-in, at most a short "blirp" can be heard instead of the three-note startup sound when I use #define AUDIO_INIT_DELAY. Without AUDIO_INIT_DELAY being set, no startup sound can be heard at all.

Also, in quantum/keyboard.c:529, I changed the line

        } else if (timer_elapsed(delayed_task_timer) > 300) {

to

        } else if (timer_elapsed(delayed_task_timer) > 3000) {

Now, it takes several seconds before the keyboard tries to play the startup sound, but it still sounds completely broken. The timers and timestamps used for sound playback look good to me. Any ideas where to debug this?

Apart from that, also the other sounds played back during e.g. AU_ON (audio on) and AU_OFF are somewhat scrambled, they are being played far too fast. To reduce this problem a bit, I specified in my keymap's config.h the following:

#undef TEMPO_DEFAULT
#define TEMPO_DEFAULT 100

This not only reduces the speed by 20% as expected, but sounds like half the speed. But this is does not fix the startup sound and obviously is just a quirky workaround. Do you think these issues might be related?

saiarcot895 commented 1 year ago

I have a Moonlander running a 1.5 month old QMK version, and without AUDIO_INIT_DELAY, I could hear only the first note of the startup sound. With AUDIO_INIT_DELAY, the full song plays.

I'm guessing it's the same or similar issue as to what's been reported here.