seeed-voicecard
seeed-voicecard copied to clipboard
respeaker
[Bug]: reference channels shifts (disordered) over multiple recordings
Describe the bug
To Reproduce Steps to reproduce the behavior:
- download provided image for hardware testing from: [https://files.seeedstudio.com/linux/Raspberry%20Pi%204%20reSpeaker/2021-05-07-raspios-buster-armhf-lite-respeaker.img.xz]
- burn image to an sd card
- boot kit (rpi4 with respeaker 5)
- login and run the following commnad:
arecord -D hw:CARD=seeed8micvoicec,DEV=0 -d 3 -r 48000 -c 8 -f s32_le test.wav - repeat 2-3 times
- review recordings in audacity or similar software and see reference channels (2 channels that contain no signal) shift places (reference channel may appear at channels other than 6,7)
Expected behavior
reference channels should always be channels 6 and 7 (count starting from 0)
Platform
- e.g. Raspberry Pi 4
- Raspbian OS 32bit kernel version 5.10.17-v7l+
- Commit number: d688a02f14f5d702ab1010e85605d572b582ea05
- note: the image supplied on the readme page (https://files.seeedstudio.com/linux/Raspberry%20Pi%204%20reSpeaker/2021-05-07-raspios-buster-armhf-lite-respeaker.img.xz) was used. i did not build the driver myself.
Relevant log output
No response
hi, @gusido ! I was able to reproduce the issue on the latest https://github.com/respeaker/seeed-voicecard/commit/dd9391fb78e6ec0ead495e5246e32a781d056ab2 commit version.
I looked briefly through the https://github.com/respeaker/seeed-voicecard/blob/master/ac108.c code and there has been quite a few changes that might affect channel order. I'm almost done with issue backlog and after that will be spending time working on issues that we were able to reproduce while doing internal testing.
@HinTak do you have any ideas of what might be causing channel shift? It looks similar to https://github.com/respeaker/seeed-voicecard/issues/301 ,which I wasn't able to reproduce. But this one affects Reference channels and not the recording cahnnels it seems.
Yes, #301 and quite a few closed-without-resolution ones. Afaik this is generic to multichannel (>2) capture and playback on the pi. See it on a different device and more / better discussion : https://github.com/Audio-Injector/Octo/issues/1 . The audio-injector people at least leave the issue open for years, for other people to read about it...
Hi there. Had the same issue on both Pi 3 and Pi 4, 32bits OS. I opened a topic thinking about a bad config but now I know it's a bug... As I found some previous version of the driver without this bug, does anybody know the most recent release without the bug ? Thanks in advance
Hi, I am having a similar problem with the Respeaker-4-mic-array for Raspberry Pi, though not with the "reference" mics but with the recordings. Is there any active development/troubleshooting going on?
I am using the 64-bit kernel, and tested out on 2 different Raspberry Pi's and arrays with Audacity. I get two different permutations: 1-2-3-4 or 3-4-1-2. I couldn't get to find a reliable way to induce the switching between these permutations, but if I try hard enough (basically restarting the capture within Audacity or the script at https://github.com/spatialaudio/python-sounddevice/blob/0.4.1/examples/plot_input.py until it happens). Please let me know if it would be appropriate to open up a new issue. Stable permutations of the microphones is very crucial for our application, and we would be really happy to reach a solution as fast as possible.
Best regards,
Hi, I had the same problem on Respeaker-4-mic-array and made this workaround. channel_order_fix.zip
In the zip file, ac108.c and seeed-voicecard.c are modified This patch only works for Respeaker-4-mic-array, but I think it can be modified for any device. The key point is to start generating the clock after "spin_unlock_irqrestore" (additional "mdelay(10);" is no needed in ac108.c and should be removed from my patch). I did it today, so I'm not sure if it's working properly.
Yours faithfully,
Hello, can you help out with the Respeaker-6-mic-array? Thank you so much
@JaPhoton Great work. Did this fix get merged in? If not, how do we Make the new files using the C source code files you provided? @egaznep Looks like you got it working too. Do you mind sharing the recompile and installation steps using @JaPhoton s code.
Thanks!
@rnehrboss On the repository dir is Makefile so you can probably make this files using "make" command in console.
The 6 mic is a nightmare as seems totally random and currently not much good for the DelaySum/TDOA beamformer I have hacked together. https://github.com/StuartIanNaylor/ProjectEars Its my 1st C++ project starting from scratch with C++ but couldn't find another lite realtime Pi3 capable beamformer anywhere.
Is anyone @JaPhoton else hosting a repo with the channel fixes as say with above its impossible to use with rotating channels.
https://github.com/respeaker/seeed-voicecard/issues/251#issuecomment-728522330
You have stated the ac108 is @eol would the http://www.everest-semi.com/pdf/ES7210%20PB.pdf be an alternative?
Is anyone still looking at this? it's been close to a year, and the respeaker 6 is still essentially unusable because of the inconsistent channel order.
Only thing I can say is make sure you buy with paypal and at least then you can get a refund as yeah completely unusable if you have a random channel order.
PS Respeaker please fix these with a new revision and supply mic daughter boards as why limit the board to what is a bad choice of the geometry you supply and near impossible to isolate the onboard mics. Just a straight board 4/8 channel ADC with dupont jumpers for analogue inputs with one being analogue mics from your store.
Or at least be honest and remove them from the store.
I also have the same problem.
Try an older kernel and an older driver.
Branch rel-v5.5 works for me.
I use sudo ./install.sh --compat-kernel to install the driver. It will use the hardcoded FORCE_KERNEL in the install.sh, which is 1.20200819-1 a.k.a. 5.4.51-v7l+.
The mic array I am using is a 4-mic linear array.
The raspberry pi I am using is:
Revision : c03111
SoC : BCM2711
RAM : 4GB
I have forked this repository and applied the necessary changes there. Then if I recall correctly, things worked like a charm. If you click on my profile you should be able to find it. Good luck!
13 Nis 2022 Çar 01:45 tarihinde rnehrboss @.***> şunu yazdı:
@JaPhoton https://github.com/JaPhoton Great work. Did this fix get merged in? If not, how do we Make the new files using the C source code files you provided? @egaznep https://github.com/egaznep Looks like you got it working too. Do you mind sharing the recompile and installation steps using @JaPhoton https://github.com/JaPhoton s code.
Thanks!
— Reply to this email directly, view it on GitHub https://github.com/respeaker/seeed-voicecard/issues/309#issuecomment-1097304509, or unsubscribe https://github.com/notifications/unsubscribe-auth/AECMKFLPYNWNE7QJGJBKAZ3VEX4HBANCNFSM5CN7L6VQ . You are receiving this because you were mentioned.Message ID: @.***>
hey folks, I did a PR which cleans up and improves the above patch since it was breaking the output for my respeaker 6 mic. The original patch was getting rid of the clock changes for the ac101 (output) without doing it anywhere else.
Let me know if you had the same problem and if this fixes it :)
P.S. I did a PR against HinTak repo as it's more updated and we might want to batch multiple changes. let me know if you prefer a PR against this repo instead.
well... turns out the previous solution worked like 80% of the times so I bit the bullet and implemented automatic loopback channel detection into the ec project (that's realistically how most of us would use it anyway)
please check the PR above this comment and play with the other features I added. Let me know how it goes :)
Is anyone still looking at this? it's been close to a year, and the respeaker 6 is still essentially unusable because of the inconsistent channel order.
I checkout branch linux-4.19-or-less instead of master, use sudo ./install.sh --compat-kernel, then kernel version will be transformed from 5.10.17-v7l+ to 4.19. the order becomes correct...
FWIW, Even "placebo style" random white-space changes is guaranteed to be correct at least 25% of time, since there are only 4 sync positions. Besides, I don't think the original was as poor as 25%? More like occasional (ie 80% correct). So I think "80%" correct is just placebo.
One more comment on this issue. I think many users need to remotely log in to the Raspberry Pi through their laptop (not 24/7 on, you might close your laptop), start a screen session, then run their script in the screen session, and lastly, use Ctrl-A Ctrl-D to exit the screen session. In this way, your script will keep running even if you disconnect the SSH session.
However, in our tests, this process may lead to a channel shift after you use Ctrl-A Ctrl-D to exit the screen session. The solution is to not use screen on Raspberry Pi to keep your remote command alive.
Disclaimer: I don't work for Seeed Studio. FWIW, comments like "this issue happens in this other situation I care about too" isn't helpful.
The problem is well-understood I think - various components of the hardware just fake it and packs 2-channel 176k data, to and from, 8-channel 44k data. There are 4 ways of doing it. The driver starts and stop the components together, so most of the time, it is correct. However, when the system is busy (any situation, hence naming your "favourite" situation is not helpful) and stutters a bit, they go out of sync and you get one of the other 3 of 4 ways of packing 2x176k to 8x44k.
I think the only correct way to fix this, is to fix the other bug about kernel panic with spinlocks. That addresses the scheduling problem.
The spinlock issue is https://github.com/respeaker/seeed-voicecard/issues/251
This exact issue has bitten me in my current project. With 4 mic ReSpeaker card I observe occasional channel swap while recording.
While reading the issue, BCM I2S block description, I came across the following:
If a FIFO error occurs in a two channel frame, then channel synchronisation may be lost which may result in a left right audio channel swap. RXSYNC and TXSYNC status bits are provided to help determine if channel slip has occurred. They indicate if the number of words in the FIFO is a multiple of a full frame (taking into account where we are in the current frame being transferred). This assumes that an integer number of frames data has been sent/read from the FIFOs.
It's the only way I can imagine things going out of sync - swapping L/R parts of I2S frame would permute 1-2-3-4 mics into 3-4-1-2 which is what I observe. A sample scenario would be where the FIFO is overflown at start if e.g codec starts pushing the data before DMA is started. Is this what's happening here?
Is there anything else (github issue, forum thread, whatever) that sheds some light on this topic?
This bit us a while back. Someone made a firmware fix. We grabbed that and have used it ever since without issue. Sorry I don't have a link to the fix. Should be able to search back. It was probably late 2021, early 2022.
On Mon, Sep 18, 2023 at 8:56 AM Przemysław Węgrzyn @.***> wrote:
This exact issue has bitten me in my current project. With 4 mic ReSpeaker card I observe occasional channel swap while recording.
While reading the issue, BCM I2S block description, I came across the following:
If a FIFO error occurs in a two channel frame, then channel synchronisation may be lost which may result in a left right audio channel swap. RXSYNC and TXSYNC status bits are provided to help determine if channel slip has occurred. They indicate if the number of words in the FIFO is a multiple of a full frame (taking into account where we are in the current frame being transferred). This assumes that an integer number of frames data has been sent/read from the FIFOs.
It's the only way I can imagine things going out of sync - swapping L/R parts of I2S frame would permute 1-2-3-4 mics into 3-4-1-2 which is what I observe. A sample scenario would be where the FIFO is overflown at start if e.g codec starts pushing the data before DMA is started. Is this what's happening here?
Is there anything else (github issue, forum thread, whatever) that sheds some light on this topic?
— Reply to this email directly, view it on GitHub https://github.com/respeaker/seeed-voicecard/issues/309#issuecomment-1723473482, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHU7QE2TTO3RKCQ6IQ7KR6DX3BHHXANCNFSM5CN7L6VQ . You are receiving this because you were mentioned.Message ID: @.***>
Do you refer to this particular comment? https://github.com/respeaker/seeed-voicecard/issues/309#issuecomment-989912874
I will certainly give it a try then.
Yep.. I think that's it. Good luck.
On Mon, Sep 18, 2023 at 9:12 AM Przemysław Węgrzyn @.***> wrote:
Do you refer to this particular comment? #309 (comment) https://github.com/respeaker/seeed-voicecard/issues/309#issuecomment-989912874
I will certainly give it a try then.
— Reply to this email directly, view it on GitHub https://github.com/respeaker/seeed-voicecard/issues/309#issuecomment-1723511185, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHU7QEZ3TX3VCBVW2GYPXELX3BJGNANCNFSM5CN7L6VQ . You are receiving this because you were mentioned.Message ID: @.***>
Do you refer to this particular comment? #309 (comment)
I will certainly give it a try then.
Already explained that the code change is rubbish: https://github.com/respeaker/seeed-voicecard/issues/309#issuecomment-1505995789
Working for us. Prior, the channels were totally random, after driver change, seem to be 100% acurate. We now have many many units in the field.
Hmm, I'm still missing any explanation of what exactly is causing the issue, I'd love to gain a deeper understanding.
@HinTak you write about "4 sync positions" - how can there be 4 sync positions, anyway? I must be missing something important here, but my understanding so far was that the mis-synchronization is due to I2S input FIFO going out of sync, but the FIFO is 32-bit wide, so that would only explain 1-2-3-4 to 3-4-1-2 swap. I'm confused here.
@rnehrboss do you remember, if you have tried the original code from the zip from JaPhoton, or the one from jacopomaroli pull request?