-
Notifications
You must be signed in to change notification settings - Fork 296
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
6mics / linear 4 mics: fails to record against v5.10 kernel #290
Comments
Same issue. |
Hey, I have installed a fresh raspbian and only installed the driver (v5.9). my system: i don't know if it is relevant, but i can see some "I2S SYNC error!" and "overlay: WARNING: memory leak will occur if overlay removed" in my dmesg. I can play with the leds, so i guess my cable is connected correctly. |
I just figured out that for my Pi 4 and 4 mic linear array the respeaker/seeed-voicecard/master with '--compat-kernel'-option works. |
@xiongyihui yes, except that downgrades the kernel to an older version. |
Raspbian's kernel upgrade is a lot more drastic than desktop Linux's (jumping from 4.10 to 4.19 to 5.4 to 5.10...) . I haven't even updated my Ubuntu pi from 5.4 to 5.8 yet... I think I'll go via 5.8 to see whether it breaks between 5.4 and 5.8 or 5.8 to 5.10... It is going to take a while - also because I now have all 3 devices... |
Yes, the driver broke between 5.4 and 5.8 . arecord blocking at Edit: only the 6-mic (and the linear 4-mic) is not recording at 5.8. The 2-mic and square 4-mics okay at 5.8. |
@Drizzt321 @BeckyHeath @lxne @flattman @xiongyihui : which devices have you got? I found it is only the 6mics (and linear 4-mics) broke at 5.8 . 2-mics and square 4-mics are still okay at 5.8 . disclaimer: I don't work for seeed studio - though my 2-mics and square 4-mics came from a gift-voucher courtesy of seeed studio. |
I have finished testing all three devices (2 and 6 mics and the square 4-mics) I have against a fresh new current rasp os (which ships with 5.10) and just the 6-mics - and likely the linear 4-mics - is broken. Have enabled debugging and started switching back and forth between 5.10 and 5.4 with the 6-mics and it is a bit slow, but at least we know the problem is probably in the ac101-part. I don't particularly want to encourage people to downgrade, but for the time being I am switching back and forth between current 5.10.x and last 5.4.x to find out what's wrong, and I have written a how-to. Edit : correcting url |
Hi @HinTak, I do have the linear 4-mic. |
@HinTak Howdy! I have the 6-mic setup. I ended up solving the issue by running an old version of raspbian buster instead. see: https://downloads.raspberrypi.org/raspbian_full/images/raspbian_full-2020-02-14/ |
@HinTak thxs for your investications. I can confirm, that my 6-array mic works like a charm with kernel 5.4, installed by --compat-kernel. I guess that for raspberry os there are only 5.4 and 5.10 kernels, right? |
@lxne sorry, corrected the url @BeckyHeath - good to know the full version have matching kernel header package included. Starting with lite/headless, the matching header package usually missing, and it is not always possible to get the header without upgrading the kernel. |
@flattman you likely want to do the "apt-mark hold..." step too (and unhold in the future). I went to the raspberrypi site, debian buster with 4.19 is also linked from there. It seems that the raspberry pi foundation is jumping from one kernel LTS version to the next. (which is 5.10, 5.4, 4.19, 4.10, etc). |
Btw, Ubuntu groovy is using kernel 5.8.x . |
Comparing the boot message under 5.4 and 5.10, one line is missing:
So it looks like the overlay is not loaded/read properly. This makes sense as the overlay is specific to 6-mics/linear-4-mics, so only the 6-mics/linear-4-mics breaks. We have had an overlay-related problem (and fixed in c4c112d ) not-too-distant in the past - mostly in upstream tightening / changing what is regarded as "valid". This is probably going to be a similar issue... |
The missing "mapping ok" message turned out to be a red herring: the Intel Soundwire guy decided it is too much information (apparently each Intel audio hardware gives multiple lines of "mapping ok"...) so he decided to delete it for suppress it for everybody... Sigh. Need to looking elsewhere. |
Filed uptream as raspberrypi/linux#4279 - pretty sure it is due to some subtle changes in the rest of the kernel... @lxne - the red herring's change message - it seems that some Intel Soundwire device put out 14 lines of those, and this guy decided that it is not useful for the rest of us :-( :
|
Written to alsa-devel https://mailman.alsa-project.org/pipermail/alsa-devel/2021-April/183770.html and CC'ed the 5 people whose kernel code changes are involved. Let's see what follows on alsa-devel . More detail upstream at raspberrypi/linux#4279 , but this is now a further upstream issue, with the rest of the linux kernel sound system, not specific to pi... Holy sh*t... |
The problematic commit is this one. I have flipped it back and forth to make sure. Unfortunately the ti.com address bounced, so I hope some of the other alsa-devel people can help.
|
I think the upstream change was correct - that the respeaker code depends on the previous behavior is wrong... For now I have spent enough time on it and would rather doing something else for a bit. :-) |
You will see the log if you enable dynamic debug. |
@plbossart apologies -I was being unkind, after chasing down that path for a day. FWIW, I filed an issue for raspbian to ship their kernels with dynamic debugging on a year ago: raspberrypi/linux#3486 . Most desktop Linux have it on; I kind-of understand that they want to ship with the best performance on a small ARM-based distro though. |
I have an ugly-but-functional change to the driver code to fix this, posted as https://mailman.alsa-project.org/pipermail/alsa-devel/2021-April/184023.html - anybody knowledgeable in audio drivers, advices and suggestions on how to achieve the same result in a better way would be appreciated. |
Need to revisit, and do in a different way. respeaker#290 6mics / linear 4 mics: fails to record against v5.10 kernel raspberrypi/linux#4279 [regression] alsa system call blocks on record between 5.4.83 and 5.5.19 In v5.5, commit 4378f1fbe924054a09ff0d4e39e1a581b9245252 Author: Peter Ujfalusi <[email protected]> Date: Fri Sep 27 10:16:46 2019 +0300 ASoC: soc-pcm: Use different sequence for start/stop trigger On stream stop currently we stop the DMA first followed by the CPU DAI. This can cause underflow (playback) or overflow (capture) on the DAI side as the DMA is no longer feeding data while the DAI is still active. It can be observed easily if the DAI side does not have FIFO (or it is disabled) to survive the time while the DMA is stopped, but still can happen on relatively slow CPUs when relatively high sampling rate is used: the FIFO is drained between the time the DMA is stopped and the DAI is stopped. It can only fixed by using different sequence within trigger for 'stop' and 'start': case SNDRV_PCM_TRIGGER_START: case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: Trigger order: dai_link, DMA, CPU DAI then the codec case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: Trigger order: codec, CPU DAI, DMA then dai_link Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
Need to revisit, and do in a different way. respeaker#290 6mics / linear 4 mics: fails to record against v5.10 kernel raspberrypi/linux#4279 [regression] alsa system call blocks on record between 5.4.83 and 5.5.19 In v5.5, commit 4378f1fbe924054a09ff0d4e39e1a581b9245252 Author: Peter Ujfalusi <[email protected]> Date: Fri Sep 27 10:16:46 2019 +0300 ASoC: soc-pcm: Use different sequence for start/stop trigger On stream stop currently we stop the DMA first followed by the CPU DAI. This can cause underflow (playback) or overflow (capture) on the DAI side as the DMA is no longer feeding data while the DAI is still active. It can be observed easily if the DAI side does not have FIFO (or it is disabled) to survive the time while the DMA is stopped, but still can happen on relatively slow CPUs when relatively high sampling rate is used: the FIFO is drained between the time the DMA is stopped and the DAI is stopped. It can only fixed by using different sequence within trigger for 'stop' and 'start': case SNDRV_PCM_TRIGGER_START: case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: Trigger order: dai_link, DMA, CPU DAI then the codec case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: Trigger order: codec, CPU DAI, DMA then dai_link Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
The idea is the same as the previous attempt: calls ac101_trigger() just before set_clock(1). respeaker/seeed-voicecard#290 6mics / linear 4 mics: fails to record against v5.10 kernel raspberrypi/linux#4279 [regression] alsa system call blocks on record between 5.4.83 and 5.5.19 In v5.5, commit 4378f1fbe924054a09ff0d4e39e1a581b9245252 Author: Peter Ujfalusi <[email protected]> Date: Fri Sep 27 10:16:46 2019 +0300 ASoC: soc-pcm: Use different sequence for start/stop trigger On stream stop currently we stop the DMA first followed by the CPU DAI. This can cause underflow (playback) or overflow (capture) on the DAI side as the DMA is no longer feeding data while the DAI is still active. It can be observed easily if the DAI side does not have FIFO (or it is disabled) to survive the time while the DMA is stopped, but still can happen on relatively slow CPUs when relatively high sampling rate is used: the FIFO is drained between the time the DMA is stopped and the DAI is stopped. It can only fixed by using different sequence within trigger for 'stop' and 'start': case SNDRV_PCM_TRIGGER_START: case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: Trigger order: dai_link, DMA, CPU DAI then the codec case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: Trigger order: codec, CPU DAI, DMA then dai_link Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
I found another way of fixing the issue I am happier with HinTak@19067f3 (the first was a couple of commits before that, and reverted). I am somewhat against the The current https://github.com/HinTak/seeed-voicecard/ works for anything between 4.19, 5.4 and 5.10. I have definitely spent way too much time on this than I am willing to... cc many people cloned/starred my repo recently : @foolishcui @sveinbjornt @locomoco28 @dony71 @stdevel @dbelca @Lederhaut @tcgumus @coxtor @njhurst @BeneyKim @tewarid @datagutt @Daenara EDIT: adjust the default branch to work with 4.19 too. |
@HinTak This all seems to work just fine on my fresh install w/5.10! Thanks for all the work! It only seems to support S32_LE playback, for some reason though. Not sure what's up with that. Trying to figure out how to get aplay/arecord/etc to use that by default. And along with the S32_LE thing, need to figure out how to get Picroft/Mycroft to use the right output, or right format for output, so I can get it working... |
@Drizzt321 Btw, although playback takes 8 channels, a random stereo pair is used, so if you playback what you just record, there is a 1/4 chance in the 6-mics or 1/2 chance for the 4-mics you'd be playing the empty channel's :-). This is mentioned at the bottom of the Readme. Anyway, I really would rather be doing something not respeaker related for a while :-). I don't work for Seeed Studio... if you feel generous, please click the donate link in https://hintak.github.io , even if only to send a beer! |
@HinTak I think I can manage to muddle through now, now that you got the basic underlying driver worked out! And already sent you a beer, or two, depending on how much things are where you're at. :) That's interesting, about the playback. |
@Drizzt321 thanks! You didn't have your name in github... Beer from supermarkets has got cheaper and more varied lately, since pubs are closed and breweries would rather sell some cheaply than not at all... Anyway, the playback thing is somewhat central/relevant to this bug: recording uses the clock on the playback chip for synchronization, and when used in the designed way, data is 8-channel and same frequency in both directions; recording have two empty channels, while playback just pick a stereo pair out of 8 (hence what the readme says). |
@HinTak Hm...
When I run the When I play it back manually, This seems quite relevant, I'll poke at it sometime soon to see if that helps me fix it. https://community.mycroft.ai/t/picroft-with-i2s-audio/4658/16 Here's the detailed mycroft output.
|
@Drizzt321 I see you are doing |
@HinTak I did send you some Euros, hope you can use 'em. |
Thanks @lxne, I appreciate that! |
See two people (cc @Drizzt321 @BeckyHeath ) experience such problem, probably should start a new issue instead of keeping on exchange elsewhere (#285), especially on closed issues (#234)
The text was updated successfully, but these errors were encountered: