Skip to content
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

output filled with noise for 4-mics array with recent code #289

Closed
HinTak opened this issue Mar 12, 2021 · 40 comments
Closed

output filled with noise for 4-mics array with recent code #289

HinTak opened this issue Mar 12, 2021 · 40 comments

Comments

@HinTak
Copy link
Contributor

HinTak commented Mar 12, 2021

Mentioned by @Daenara in
#251 (comment) - with an attached audio sample.
The noise is not white noise, but seems to be some kind of data corruption within the driver. the 6-mic array works okay for me and it is unclear why the 4-mic driver mis-behaves (while sharing some of the same hardware and therefore chip-driver code).

I was supposed to receive a 4-mics device (and a 2-mic device, which I do not have either) about two months ago curtesy of a gift voucher from Seeed Studio in appreciation for the code update, but it hasn't arrived yet. I probably should check on that order...

@HinTak
Copy link
Contributor Author

HinTak commented Mar 26, 2021

@Daenara - the 4-mic device arrived today (nearly 4 months...). I also have a new blank sd card to play with too / and the 2-mics device. What OS etc you are on, and other sound related application you run it with?

Thanks Seeed Studio for the complementary voucher. @turmary @Pillar1989

@Daenara
Copy link

Daenara commented Mar 26, 2021

I just updated my pi today and was actually looking into downgrading the kernel to something workable soon because I want my mic to work. I use the official raspberry os in the barebone version (no graphical interface) with the current kernel (Linux Pi-Hime 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l GNU/Linux). I don't really use much sound related stuff, I basically only require alsa/arecord to work for the speech recognition stuff I run in dockers to work.

I know your v5.5 version was working on the 4-mic and I stayed there until I accidently updated the kernel to 5.10. This is when I switched to your v5.9 branch and I haven't gotten anything working since. So I sadly can't tell you with which version of the kernels everything broke again but I do know something is broken... All tests I did the last few days were just noise, not even my voice coming through quietly in the background.

@HinTak
Copy link
Contributor Author

HinTak commented Mar 27, 2021

@Daenara I am slightly confused - when did you start having that terrible noise problem? Raspbian's first 5.10 kernel release was tagged on 1st Feb, so it would have been available only a few days before/after. Was it working okay upto end of January, or did you have to do throw away all channels except one, before that?

@HinTak
Copy link
Contributor Author

HinTak commented Mar 27, 2021

@Daenara actually you could tell which kernel version was used in the past. If you type last, it would give you a list of what kernel version was used in the past reboots. Unfortunately the pi does not have a built-in clock like a Intel desktop, so it does not know world time until it is networked. So the reboot time is always 1 Jan ...; but the log in / session time (your pi account starting a terminal) should be in correct time.

@Daenara
Copy link

Daenara commented Mar 27, 2021

I thought I used a 5.5 kernel, but apparently I went from a working 5.4.83-v7l+ directly to 5.10.11-v7l+. I did purposely not update the system because I knew there would be driver issues with every update, so that update was quite accidental. So after I was on 5.10 I switched to your v5.9 branch which you wrote somewhere should work for 5.10 also and I had problems since. I updated a few times since the accidental update but if it changed anything, it got worse.

I always threw away all but one channel, even after the quick fix you made in v5.4 that made the drivers usable, the software I use only needs one channel and I had issues with random noise on one channel or the other since I departed form the last working official driver before they used your fixes last year.

Before your quick fix no channel had usable audio, after the fix I had mostly clear audio (some noise, but my voice was always clear enough for speech to text, just some small background noise and crackling). The first channel always had the best quality, but that might just be from the way the mic is lying next to me. Two mics are pretty close to the pi while two are 10cm away, so I am guessing one of them is channel one and there is less interference.

After finally getting it working I only did selected updates for software and no full update for fear of breaking the finally working system, so I apologize for not being able to tell you at which point it broke, I just now kernel 5.4 was working, and now it doesn't anymore.

daenara  pts/0        192.168.0.50     Fri Mar 26 20:27   still logged in
reboot   system boot  5.10.17-v7l+     Thu Jan  1 01:00   still running
daenara  pts/1        192.168.0.50     Fri Mar 26 19:33 - 20:26  (00:53)
daenara  pts/1        192.168.0.50     Fri Mar 26 19:32 - 19:33  (00:00)
daenara  pts/1        192.168.0.50     Fri Mar 26 19:30 - 19:32  (00:01)
daenara  pts/0        192.168.0.50     Fri Mar 26 19:26 - 20:26  (00:59)
reboot   system boot  5.10.17-v7l+     Thu Jan  1 01:00 - 20:26 (18712+20:26)
daenara  tty1                          Fri Mar 26 19:16 - crash (-18712+19:16)
reboot   system boot  5.10.17-v7l+     Thu Jan  1 01:00 - 20:26 (18712+20:26)
daenara  pts/1        192.168.0.50     Fri Mar 26 17:41 - 17:44  (00:03)
daenara  pts/0        192.168.0.50     Fri Mar 26 17:29 - crash (-18712+17:29)
daenara  pts/0        192.168.0.50     Fri Mar 26 16:51 - 17:28  (00:36)
daenara  pts/0        192.168.0.50     Thu Mar 25 21:21 - 05:47  (08:26)
reboot   system boot  5.10.17-v7l+     Thu Jan  1 01:00 - 20:26 (18712+20:26)
daenara  pts/0        192.168.0.50     Thu Mar 25 20:43 - crash (-18711+20:43)
daenara  pts/0        192.168.0.50     Wed Mar 10 17:11 - 17:12  (00:01)
reboot   system boot  5.10.11-v7l+     Thu Jan  1 01:00 - 20:26 (18712+20:26)
daenara  pts/0        192.168.0.50     Sat Feb 27 16:34 - 17:09  (00:34)
daenara  pts/0        192.168.0.50     Thu Feb 18 22:32 - 02:47  (04:15)
reboot   system boot  5.10.11-v7l+     Thu Jan  1 01:00 - 20:26 (18712+20:26)
daenara  pts/0        192.168.0.50     Thu Feb 18 22:26 - 22:30  (00:04)
reboot   system boot  5.10.11-v7l+     Thu Jan  1 01:00 - 22:30 (18676+22:30)
daenara  pts/0        192.168.0.50     Thu Feb 18 22:20 - 22:25  (00:05)
reboot   system boot  5.10.11-v7l+     Thu Jan  1 01:00 - 22:26 (18676+22:26)
daenara  pts/0        192.168.0.50     Sat Feb 13 20:42 - 20:43  (00:01)
reboot   system boot  5.10.11-v7l+     Thu Jan  1 01:00 - 20:44 (18671+20:44)
daenara  pts/0        192.168.0.50     Sat Feb 13 17:56 - 20:41  (02:45)
reboot   system boot  5.4.83-v7l+      Thu Jan  1 01:00 - 20:41 (18671+20:41)
daenara  pts/0        192.168.0.50     Sat Feb 13 17:51 - 17:55  (00:03)
reboot   system boot  5.4.83-v7l+      Thu Jan  1 01:00 - 17:55 (18671+17:55)
daenara  pts/0        192.168.0.50     Sat Feb 13 17:49 - 17:49  (00:00)
daenara  pts/0        192.168.0.50     Fri Feb 12 20:29 - 04:47  (08:17)
reboot   system boot  5.4.83-v7l+      Thu Jan  1 01:00 - 17:49 (18671+17:49)
daenara  pts/0        192.168.0.50     Fri Feb 12 20:25 - 20:29  (00:04)
daenara  pts/0        192.168.0.50     Tue Feb  9 18:15 - 18:17  (00:01)
daenara  pts/0        192.168.0.50     Tue Feb  9 18:15 - 18:15  (00:00)
daenara  pts/0        192.168.0.50     Tue Feb  9 18:14 - 18:14  (00:00)
daenara  pts/0        192.168.0.50     Tue Feb  9 18:14 - 18:14  (00:00)
daenara  pts/0        192.168.0.50     Tue Feb  9 18:13 - 18:14  (00:01)
daenara  pts/0        192.168.0.50     Tue Feb  9 17:40 - 18:13  (00:32)
daenara  pts/0        192.168.0.50     Tue Feb  9 17:37 - 17:37  (00:00)
daenara  pts/0        192.168.0.50     Tue Feb  9 17:35 - 17:36  (00:01)
daenara  pts/0        192.168.0.50     Sat Feb  6 18:04 - 05:20  (11:16)
daenara  pts/0        192.168.0.50     Wed Feb  3 19:35 - 01:08  (05:32)
daenara  pts/1        192.168.0.50     Mon Feb  1 01:18 - 03:31  (02:13)
daenara  pts/0        192.168.0.50     Sun Jan 31 21:03 - 01:35  (04:32)
reboot   system boot  5.4.83-v7l+      Thu Jan  1 01:00 - 20:29 (18670+20:29)
daenara  pts/0        192.168.0.50     Sun Jan 31 20:57 - 21:03  (00:05)
reboot   system boot  5.4.83-v7l+      Thu Jan  1 01:00 - 21:03 (18658+21:03)
daenara  pts/0        192.168.0.50     Sun Jan 31 20:51 - 20:57  (00:05)
reboot   system boot  5.4.83-v7l+      Thu Jan  1 01:00 - 20:57 (18658+20:57)
daenara  pts/0        192.168.0.50     Sun Jan 31 20:45 - 20:51  (00:06)
reboot   system boot  5.4.83-v7l+      Thu Jan  1 01:00 - 20:51 (18658+20:51)
daenara  pts/0        192.168.0.50     Sun Jan 31 20:38 - 20:44  (00:05)
reboot   system boot  5.4.83-v7l+      Thu Jan  1 01:00 - 20:45 (18658+20:45)
daenara  pts/0        192.168.0.50     Sun Jan 31 20:26 - 20:38  (00:12)
daenara  pts/0        192.168.0.50     Mon Jan 25 21:07 - 06:10  (09:03)
daenara  pts/0        192.168.0.50     Sun Jan 24 22:11 - 03:51  (05:40)
daenara  pts/0        192.168.0.50     Sat Jan 23 20:48 - 04:37  (07:49)
daenara  pts/0        192.168.0.50     Sat Jan 23 02:41 - 04:17  (01:36)
daenara  pts/0        192.168.0.50     Wed Jan 20 18:42 - 01:17  (06:35)
daenara  pts/0        192.168.0.50     Tue Jan 19 18:31 - 23:05  (04:33)
daenara  pts/0        192.168.0.50     Sat Jan 16 18:52 - 01:34  (06:42)
daenara  pts/0        192.168.0.50     Sat Jan 16 03:33 - 04:55  (01:21)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 20:38 (18658+20:38)
daenara  pts/0        192.168.0.50     Fri Jan 15 20:27 - 03:33  (07:05)
daenara  pts/0        192.168.0.50     Tue Jan 12 21:28 - 01:00  (03:31)
daenara  pts/0        192.168.0.50     Wed Jan  6 17:49 - 04:54  (11:05)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 03:33 (18643+03:33)
daenara  pts/0        10.0.42.10       Wed Dec  9 11:28 - 11:39  (00:11)
daenara  pts/0        192.168.0.50     Tue Nov 24 17:59 - 02:11  (08:12)
daenara  pts/0        192.168.0.50     Fri Nov 20 19:39 - 03:49  (08:09)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 03:33 (18643+03:33)
daenara  pts/0        192.168.0.50     Fri Nov 20 17:25 - 19:37  (02:12)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 03:33 (18643+03:33)
daenara  pts/0        192.168.0.50     Fri Nov 20 17:24 - 17:24  (00:00)
daenara  pts/0        192.168.0.50     Thu Nov 19 20:38 - 01:15  (04:36)
daenara  pts/0        192.168.0.50     Tue Nov 17 17:34 - 03:49  (10:14)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 17:24 (18586+17:24)
daenara  pts/0        192.168.0.50     Tue Nov 17 16:52 - 17:34  (00:41)
daenara  pts/0        192.168.0.50     Tue Nov 10 22:58 - 02:42  (03:43)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 17:34 (18583+17:34)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 17:34 (18583+17:34)
daenara  pts/0        192.168.0.50     Tue Sep 29 21:27 - 14:42 (2+17:14)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 17:34 (18583+17:34)
daenara  pts/0        192.168.0.50     Tue Sep 29 21:09 - 21:15  (00:05)
daenara  pts/0        192.168.0.50     Sun Sep 20 21:14 - 04:18  (07:03)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 21:15 (18534+20:15)
daenara  pts/0        192.168.0.50     Sun Sep 20 21:06 - 21:12  (00:06)
daenara  pts/0        192.168.0.50     Sat Sep 19 18:42 - 06:17  (11:34)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 21:12 (18525+20:12)
daenara  pts/0        192.168.0.50     Sat Sep 19 18:11 - 18:39  (00:28)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 18:39 (18524+17:39)
daenara  pts/0        192.168.0.50     Sat Sep 19 18:02 - 18:10  (00:07)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 18:10 (18524+17:10)
pi       pts/0        192.168.0.50     Sat Sep 19 17:45 - down   (00:16)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 18:01 (18524+17:01)
pi       pts/0        192.168.0.50     Thu Aug 20 11:47 - 17:44 (30+05:57)
reboot   system boot  5.4.51-v7l+      Thu Jan  1 01:00 - 17:44 (18524+16:44)

@HinTak
Copy link
Contributor Author

HinTak commented Apr 7, 2021

@Daenara I have finally gotten round to try recording with the 4-mic device. It works okay here - though the 4-mic recordings are definitely a bit noisier than the 6-mics device's. I did a 2nd recording with the 4-mic because the CD I was playing happened to reach a quieter part... here are against 5.4 kernel:
6mic-5.4.zip
4mic-5.4-2.zip
4mic-5.4-1.zip

Here are against the older 4.19 kernel - I don't think they are noticeably better, but if you have a way of measuring "quality" I would like to know:
6mic-4.19.zip
4mic-4.19.zip

The music was played in the next room, which would be the 9-o'clock direction for the 4-mic and 6-o'clock direction for the 6-mic, if you view the "RESPEAKER" marking on the top the correct way. (when mounted, the 4-mic and 6-mics have that word facing different directions - my pi itself is roughly at the same place) .

Do you still have one which makes broken the noisy recordings? I wonder what you do that different from mine.

Yes, the driver is broken between 5.4 and 5.8 (see #290 ) .

@Daenara
Copy link

Daenara commented Apr 7, 2021

With working drivers the only issue I have is that the "base" noise level varies from time to time. If I am lucky I get no noise at all, if I am unlucky I have a channel or two where it is louder.

I think the completely broken recording was from when the drivers broke, normally I just have a bit more noise, not that bad. I just tried getting back on my old test install sd card but so far every sample I recorded was just noise and when I tried reinstalling the drivers the install script pulled the newest kernel so I can't test on 5.4 anymore. Whoever thought it was a good idea to just install whatever the newest kernel is didn't think that decision through.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 8, 2021

@Daenara sorry about your trouble and I sympathize about the kernel upgrade... I think it is a bit of both: the upstream (raspbian) has been known to ship broken kernel header packages, and it is often not possible to get matching headers to the running kernel... And seeed staff are not exactly present. Raspbian is also doing fairly large jumps every 6-9 months too - that does not help.

I myself try to do what I do on desktop Linux, which is upgrade as frequent as possible (so that breakage is small and seen early) but be prepared to roll back to the last known good configuration if things don't work .

On Raspbian you can do "sudo apt-mark hold ..." a package to stop a specific package from getting auto-upgraded. I do that to one of my SD cards. Unfortunately Ubuntu does not follow the same rule ("apt-mark hold ..." itself succeeds, but it does not have the same effect as Ubuntu boots differently from Raspbian). But you have to know exactly what you are doing to use "apt-mark hold ..." since it messes with mutual dependences.

I think I spotted a mistake in the post 5.4 code, but it likely only affect the 6-mics device. I'll look further tomorrow. (at least now I have one device of each so it makes life easier, though things get tedious plunging / rebooting.. )

@HinTak
Copy link
Contributor Author

HinTak commented Apr 8, 2021

@Daenara interestingly only the 6-mic driver is broken in 5.8+ - I was able to record against 5.8 with both the 2-mic and the square 4-mic.

I think the current install process is a compromise: the kernel header package is usually not included in the upstream image (it is only useful for out-of-tree drivers, and most people are not attaching random extra devices to their pi?), and only the latest is usually available, hence it forces a kernel upgrade to match it. Perhaps it should only check and abort instead? partly, it is raspbian doing big jumps too (desktop linux is a lot more gradual, and ubuntu's pi release seems to stay with the same x for 5.x).

@Daenara
Copy link

Daenara commented Apr 8, 2021

So you are telling me that the 4mic should work on a 5.10 kernel with your 5.9 drivers? If so either my mic is completely broken now (I doubt it, haven't done anything to the hardware and it was just lying next to me) or the install/uninstall process is so broken that the drivers only work after a completely fresh install.

What I hate about the current install process is that if I get your 5.5 branch and try to install it it automatically upgrades my 5.4 kernel to whatever is current, 5.10 in this case which won't work with the 5.5 branch. The old branches should check what the last kernel is that the branch can use and pull that, if at all, not whatever is current, that behavior just breaks stuff. It also should just check if the headers are there and only install if they are missing.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 9, 2021

@Daenara It is a bit more than that! :-) . In the last few days, I have updated the default (still called v5.9) branch, and it is the same code which records okay for 4.19.x, 5.4.x, 5.8.x, and 5.10.x for the 2mics and 4-mics devices. ( 6 mics is broken for 5.8 and 5.10 - see #290 ).

Yes, it should work for the 4-mics which ever kernels you are using, within those versions, if you clone the current state of my repo. I have written down how to downgrade too:
https://github.com/HinTak/RaspberryPi-Dev/blob/master/Downgrading-Pi-Kernel.md ; it is just 4 commands (and a 5th for verifying), and I have written down how to undo the downgrade too. For the next week or so - however much time I can find - I'll be going back and forth between the current 5.10 and the last working 5.4, to find out what's wrong with the 6-mics part of the code.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 9, 2021

@Daenara please feel free to go ahead and go back to 4.19 too! I haven't tested downgrading that far back (but the modified instructions are towards the end of the first section) - as I said, I was just switching bewtween 5.4 and 5.10 on raspbian, and 5.4 and 5.8 on ubuntu, to find out what's working and what's not working - it is a lot of reboots, switching SD cards, and plugging / unplugging the 3 mics sets too.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 15, 2021

@Daenara FWIW, I have tested successfully downgrading back to 4.19 from 5.10 as in the middle part of https://github.com/HinTak/RaspberryPi-Dev/blob/master/Downgrading-Pi-Kernel.md .

@Daenara
Copy link

Daenara commented Apr 19, 2021

I am still trying to figure out why my mic is producing constant noise now, I don't want to believe all 4 mics broke with it just sitting next to me but so far I haven't been able to get any useful recording on any version of the kernel. I just tried doing a test with the raspbian os image from march and I couldn't install the drivers. Here is the log of that:

make.log

@Daenara
Copy link

Daenara commented Apr 19, 2021

Okay, after playing around with the settings I managed to get some kind of usable recording with the current v5.9 branch and the raspberry pi os from March, using the compat-kernel option, since I can't install with the 5.10.17 kernel for some reason (see above). Though still only on the first channel and only after playing around in alsamixer for a while. I had to turn down the digital volume and up the gain to get anything but since I can get pretty clear sound on at least one channel I think it is not a matter of a broken mic and more of some broken settings that come with the driver.

While experimenting with alsamixer I did manage to at least hear my voice on all 4 channels but I did not manage to get the last two channels to drop their overwhelming noise. I did a few recordings with 32000 Hz and a few with 8000 Hz in between, just to check if it changes anything and strangely enough I am only able to really hear my voice on the noisiest channel on 8000 Hz.

Here are the files I tested with, I am always saying "test eins zwei drei vier", as well as the alsamixer settings I ended up on in the end. The first few samples had the default settings, Then I turned down digital volume but didn't turn up gain on sample 6. I did gain on channel one afterwards, the sample that doesn't have any voice in it (number 9) was me turning down digital volume to 40 something, I turned it back up again later.

samples.zip
image

I noticed that in between there are small bouts of loud noise on some channels for a bit, then it is nearly silent on the same channel and it all is kinda strange. Something goes wrong when recording, I doubt real world interference would produce those results, and I did remove everything that is not the mic from the pi for some older tests that had only noise and no voice last week, and the noise stayed constant. I think something in the software is responsible for the noise, but I can't figure out what it is.

@Daenara
Copy link

Daenara commented Apr 19, 2021

I did even more testing, this time on my productive operating system, newest kernel (5.10.17) and the v5.9 branch (last commit included was April 1st). This time I turned down all but one channel in alsamixer, set the digital volume for that channel to 81 and the gain for that channel to 71. I only got a clear recording on one channel, but I noticed it was not on the first, like it always was but on the 2nd (counting alsamixer channel numbering). Also, the loud noises were not on the last two channels like they were on the last tests. Could it be that somehow the channels are switched or addressed wrongly
somehow? It used to correspondent between the channels as shown on the pi and the channels in the audio file when opened with audacity, now it doesn't.

test_channel.zip

After doing this test I tried setting the one working channel up so I could use voicecommands again. I first upped the gain of channel 2 (only working one) from 71 to 81 and only got small snippets of sound. I turned it back down again to 71 and got a recording where I could understand my voice but suddenly opened in audacity the sound was on the 2nd channel like it should be, not the 4th it was the recordings before. I did another recording as a test and the sound jumped back to channel 4 in audacity. So something is definitely off somewhere.

Here are the samples:
test_channel_2.zip

@HinTak
Copy link
Contributor Author

HinTak commented Apr 19, 2021

I am still trying to figure out why my mic is producing constant noise now, I don't want to believe all 4 mics broke with it just sitting next to me but so far I haven't been able to get any useful recording on any version of the kernel. I just tried doing a test with the raspbian os image from march and I couldn't install the drivers. Here is the log of that:

make.log

The log says you are trying to build somewhat old driver code against current kernel.

@Daenara
Copy link

Daenara commented Apr 20, 2021

I did a clean install of raspbian os and pulled your v5.9 branch. The same branch that is running on another installation with the same kernel just fine, just a few commits behind. There are only two differences, the working system was upgraded via apt and has your drivers from April 1st, the system that does not install the drivers uses the new raspberry pi os image that comes with kernel 5.10.17 and uses the most current of your repro, since I just pulled it today.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 20, 2021

Hmm, if you did a clone recently, the last commit should be more recent than 27 Nov 2020. If you do:

git log --format=oneline | head -11

The last line should be ... snd_soc_component_read32() merged into snd_soc_component_read() (this is the 27 Nov commit in the longer "git log" form). The first 10 lines are things I did recently to support older kernels and does not matter / have not effect against 5.10 . You should have that line somewhere within the 11 lines displayed?

@Daenara
Copy link

Daenara commented Apr 20, 2021

Okay, you can ignore that. I somehow pulled the respeaker drivers, no wonder nothing worked on that test install... But I still have quite a few strange things happening on my working install using your fork. I do not think audio channel mappings between alsa and the channel number in the audio file recorded should vary between recordings, for one.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 20, 2021

@Daenara FWIW, the off-by-2(for 4 mics, coming out as 3,4,1,2) is one of those filed but closed without resolution ones, e.g. #145

My understanding is that it is generic to how multi-channel audio on raspberrypi works: multi-channel (>2) audio on pi works by telling the audio core the data is sterero at 2x / 3x / 4x frequency in the middle. The mics know it is 4-/6-/8-channels, the application knows it too, but in the middle it is all two-channel at double/triple frequency. Hence the occasional 2-channel shift if things go out of sync.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 20, 2021

Here are issues about channel shifts on another multi-channel card : Audio-Injector/Octo#8
Audio-Injector/Octo#1 . Except the developers leave the issues open and offer advices :-) .

@Daenara
Copy link

Daenara commented Apr 22, 2021

@HinTak We found the problem. Apparently my mic was defect from the get go, I asked about the noise issues here and was told by the seed ppl here that is was normal, so I never questioned it or send it in. It was only after you sent me the file of how yours sounds that I questioned that. We went today and measured everything we could and noticed that quite a few of the capacitor weren't soldered on properly, one even fell off. So after my father soldered all of them on properly we were able to get clear audio on all 4 channels, something that never worked even when the mic was new. We also noticed that the mics never get the power they should get. But even a few minutes after we did the test with clear sound, things started to get worse, I ordered a cheap clone so we can try to figure out how it is supposed to work and then maybe we can fix it, or I just use the clone. After being told my issues that obviously were a hardware defect of improper soldering were normal I don't think I will order an original again.

Sorry for all the issue searching I put you through for this. We did test the hardware before, but it needed one of the badly soldered capacitors to fall off until we could locate the issue because no amount of magnifying glasses we own could have let us see the bad soldering on less than a mm big parts. To solder them back on my father actually stacked 3 magnifying glasses and even then it was hard to see the issue.

I am hopeful that once the clone arrives we can figure out how much voltage there should be at the mics and with enough luck I can just use the clone while my father tinkers around with the original one which I didn't allow him to before now, because it was somewhat working and I did not have a replacement.

For anyone with similar issues, if the mic is new, send it in if you live anywhere with warranty. The thing can have a bit of noise, but if you have noise that drowns out voice when using it or channels that are filled with constant noise all the time, apparently some capacitors aren't doing their job.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 22, 2021

@Daenara I am glad we get to some answers! I had the impression you have more than one, or use it on more than one pi? Or are they a bad batch? Since I got my other ones (besides the one-and-only 6-mics), I have watched some YouTube videos of people soldering the GPIO header. Some projects requires one to mount the device at 90 degrees to a pi (pi zero etc), and I was afraid that taking it off and on and swapping the devices would loosen the GPIO header; but I wouldn't assume the rest of the board to have bits coming loose. Do you use it where there is a lot of changes in temperature or humidity? (e.g. In the kitchen or bathroom, or outdoor)

Would be great if you post some pictures of fallen parts! :-)

@Daenara
Copy link

Daenara commented Apr 22, 2021

I only have one mic, but I do have a few pis, so I switched that around for testing. We did not take pictures of the fallen part, but since that part was less than one mm big, I don't think we even have a camera good enough for that. If you look at the back of your 4mic, the groove ports facing down, there are some parts soldered on the left and right of those ports. Left side was not soldered on correctly, one of them fell off and resoldering the rest of them solved all the problems I had since I got the mic. I only ever got completely clean audio on channel one, the rest were always noisy, thought understandable for humans, my voice assistant struggled. I think it got worse over time and the one that fell off completely was responsible for the noise only channel 4, and that somehow bled over to channel 3 since they are close, hence those always being the worst. The not properly soldered ones that didn't fell off were most likely responsible for the phenomena of it sometimes working, and other times being completely silent and sometimes the audio just cut off in between, most likely caused by small vibrations on my desk by me breathing and the connection sometimes loosening, then fixing itself.

I don't think humidity had something to do with it, it never worked properly, I was really surprised by the quality of your audio sample, I never got anything that good, even when new, I only use it indoors, in my room. While it is next to the window, I don't open that often, and when I do, the glass is between the mic and the outside. I played around with weather sensor data last summer, and humidity in here was pretty low but constant. Only times I have taken it out of my room was to take it to the basement lab to test it with my father, since he is the hardware guy, while I do software mostly. I was really surprised he even managed to solder the fallen part back on, even if it is slightly crooked, it is connected properly. If I remember the next time I take the mic of the pi, I can take a picture of the parts like they are now, if my phone permits, but other than the crooked soldering of the one that fell off, it looks normal. Good thing I keep my voice assistant in the top part of a shoe box, we would have never found the capacitor agian if it had fallen on the floor, it took us 5 minutes to find it in a shoe box.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 23, 2021

Yes, would love to see your father's soldering work; please do try to send a picture :-).

I didn't know clone existed, until you mentioned it - and at about 1/2 of the price of the original, and not difficult to find one to buy too. I sure hope you get better results soon.

719i8KwAwcL AC_SL1000

@HinTak
Copy link
Contributor Author

HinTak commented Apr 23, 2021

The clone have parts really well-labelled. It is not identical though - the central components next to the ac108 moved a bit. Though mine says v1.1, and most online pictures says v1.0.

@Daenara
Copy link

Daenara commented Apr 30, 2021

Sadly the labeling is not exactly that of the original, otherwise it might have made for a good reference when testing mine. The mapping of which numbers go to which mic differ.

We did some more soldering today, so I tried taking pictures for you, but my phone camera isn't good enough, here is the best of them:
DSC_0017 (4)

You can see a bit of the soldering on the bottom left, but that is exactly where my phone struggles... The yellow capacitor in the middle was todays soldering, after the last round it worked, but stopped working on all 4 mics after a few hours, so we replaced the only capacitor that is used by all 4 mics hoping it will help. The capacitor on the groove port bottom left was the first thing we did, hoping the noise would be just feedback from the groove port, so we used it to suppress possible feedback. Didn't help but we left it there anyway.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 30, 2021

The camera is adequate - it is a 20M pixel image! The flash/lighting, and camera shake is more a problem. Try taking a picture outdoor during day time, and perhaps also rest your elbow on something solid (and set the timer to do it after x seconds, instead of touching the screen to shoot, also helps)?

You are talking about where c18 in the clone figure is, right? This is a edited down version of yours:

116732784-7cbb7200-a9eb-11eb-95b8-d3f094abaa18

Mine says v1.1 01/10/2020 .

@Daenara
Copy link

Daenara commented Apr 30, 2021

The problem with the camera is, that it won't focus on what I want it to. Without the light it won't focus at all, using the inbuilt light from the camera just makes everything white and reflecting and I can't get any better lighting with the mic on my table since I need the pi working to use my desk light (zigbee lightbulb, no control at all without the pi). Add to that the fact that the camera is not intended to work up close and it is a struggle. Taking pictures outdoor during the daytime could help, but I still need the mic and pi working, an it was already dark when we tried to fix it. Once it is replaced and not needed for everything to work (voice input is optional, but the groove ports are used) I can try to take better pictures, maybe even use the family camera that actually has a proper lens as opposed to my phone cam. 20M pixel is all well, but if I can't get a proper focus on anything without holding the mic a meter away then it won't actually help.

As for the labeling on the clone, we referenced the official schematic with the clone labeling and on the schematic mic one has c3, c4, c7 and c10, while the clone has different ones, it seems to be that way for all mics. I didn't check anything else, but the numbering is different.

Just noticed what you meant with the c18, yes, that is the one that flee off, the others in that corner were resoldered as well, but not moved.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 30, 2021

I have a lot more faith on Japanese engineering (as opposed to Chinese engineering...), and Sony's in particular, than you do :-)... Would the macro mode described in https://www.sony.co.uk/electronics/support/articles/SX586601 help? The auto mode is supposed to be quite good, but maybe it needs a bit of help. I have the older Z Ultra (which does not have a special macro mode). I can hold the phone to about 3 inches from the circuit board , and the board fills the screen.

EDIT: Your camera is supposed to be able to shot at 0.12 metre (a little under 5 inches).

@Daenara
Copy link

Daenara commented May 8, 2021

So the replacement came today. It seems I have pretty bad luck with mics right now because two parts were soldered crooked and touched, which might have caused problems. Since I did not want to wait for another one I let my father fix it, and now it works perfectly. I played around with alsamixer a bit trying to reduce the slight noise it has to nothing while still being able to hear myself from the other end of the room. The result is, noiseless is impossible but the slight noise I have now is even quieter than my old mic on its best days and I think it might just be from too much gain (which I need to record from the other end of the room).

As promised, now that it is not in use I took better pictures of my fathers soldering on the old one. With the lamp on my desk working my phone even took good pictures for once.

DSC_0025

@HinTak
Copy link
Contributor Author

HinTak commented May 8, 2021

That surely sounds unfortunate. How /where did you order? Are they the same place? Both seeed studio and lctech HQ are in Shenzhen, as well as X-Power (the manufacturer of the audio chip) , but I wouldn't know where they are actually made, as it makes sense to assemble them nearer the shipping destination.

@Daenara
Copy link

Daenara commented May 8, 2021

I ordered from a Chinese ebay vendor, not much choice in Germany. I wasn't even supposed to arrive for a few days, vewndor put May 12. to June 2. as the delivery time. I think I ordered on April 22. Stuff from China always takes at least two weeks, normally longer, so we decided to fix it instead of reporting it as defect and waiting for a new one.

@HinTak
Copy link
Contributor Author

HinTak commented May 8, 2021

Hmm, not aliexpress? Why do you have to order from China? I think I bought my 6-mic from
https://shop.pimoroni.com/products/respeaker-4-mic-array-for-raspberry-pi and the other two are courtesy of a gift voucher, so they were on the official we site
https://www.seeedstudio.com/ . Both ship worldwide, and when they arrive, the postages were from UK. There are plenty of distributors who would ship from UK, though it seems that the 4-mics were a bit short in supply for a while. (my order had 3 items, it took 4 months, but when it arrived the 4-mics one has a serial number/batch about 2 weeks before that, so it looks like that was the rare item holding the order back). The lctech clone are sold on amazon... The first few shops on Google when I click on shopping are fairly reputable.

The 4-mics is only $20-25 US in price. I am surprised you can't find a Uk supplier? I saw the lctech clone on a german web site, actually.

The pi came from UK (actually I live within a "walkable" distance from the pi foundation, as in I could walk there in about an hour on foot) and there are enough UK stockists who would ship pi accessories to the continent?

@Daenara
Copy link

Daenara commented May 8, 2021

I ordered my original one in Germany, but I didn't want to spend 25€ or so on another one and got the clone. The clone I can't get anywhere closer and I don't order anything that might be shipped from the US, that is 20€ shipping costs, if not more. Also, everything above 20€ or so I have to pay extra taxes for import, and if for some reason no shipping fee is declared customs just assumes one, and I have to pay that and a fine for the extra work that caused them, and if that comes above 20€ I have to pay the import tax, also. Last time someone didn't declare the package properly I would have had to pay as much import tax as I spent on the content, so I let it go back to the sender. So we order clones, small electronics and stuff from China because the same thing costs at least 2x more if we order from Germany. Ans everything from outside Germany needs to be less than 20€.

As for why ebay, it was that or alibaba and I had a 3€ voucher for ebay and it was just cheaper there. Cost 8€, 10€ or so with shipping. Since they both sent from China it didn't make a difference timewise.

@HinTak
Copy link
Contributor Author

HinTak commented May 8, 2021

Argh, I don't pretend to understand the german custom rules. I have a lot of respect for German and Japanese engineering; rather much less for Chinese engineering / "made in China" and Chinese business / "sold from China"... While "made in China" is certainly not a guarantee for quality - quite the reverse -, it is still spectacularly poor to have bits falling off relatively new boards. I wonder if there are businesses selling fake seeed studio boards, or just taking their trash and soldering it up somewhat and resell them online :-).

@github-actions
Copy link

Stale issue message

@ghost
Copy link

ghost commented Jul 23, 2021

@HinTak ,
This action was performed automatically.
Please describe the issue according to bug template - if the issue was resolved, ignore this message. The issue will be marked as closed in 7 days if inactive.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Platform
What platform are you running the code on.

  • Device: [e.g. Raspberry Pi 4]
  • OS: [e.g. Raspbian OS 32bit kernel version ...]
  • Version/commit number [e.g. d1816f5]

Relevant log output
Please copy and paste any relevant log output.

@AIWintermuteAI
Copy link
Contributor

Hi @Daenara !

That was rather long thread, but I read it all.
From what I see in the end it was hardware problem. Very unfortunate, but that does happen. I'll collect the necessary information and pass it on to QC department.
Issue closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants