I am exactly the same but it was my initial reading of the Mycroft introduction that got me to source my PS3eye.
The PS3eye driver is a hack and by name it gives a hint to its purpose and platform.
Dmesg will complain on each boot and alsactl will fail if you try to load or access ctl values.
Its confusing more than anything.
But the main problem with seperate cards for capture and playback are is it will run from 2 different clock sources that will drift.
The killer here is the manner of an FFT filter as it sort of creates a spectrograph by counting the intensity of a frequency band.
Any drift means the increment can drop into the wrong band and it can drastically start to get things expotentially wrong.
Pulseaudio is bloat, but I have no objection and the code of webrtc_audio_processing is supposedly vastly superior to speex.
I can not run pulseaudio with my respeaker 2mic and so want to but the driver service crashes and why the hell does a driver have a service is beyond me.
The difference between AEC with a PS3eye + webrtc and Respeaker 2mic + speex has no comparison its vastly better with the Respeaker 2mic + speex and this is whilst as code its supposedly inferior.
Webrtc-audio-processing does have drift compensation but its relatively sucksville against the worst scenario of USB & I2S sources for playback and capture.
Its not just the ps3eye, running USB & I2S of the inbuilt is just about the worst method that generally will kill any EC code due to huge clock drifts.
I so wish to get pulseaudio to run with the respeaker 2 mic as I am itching to see how webrtc performs when its not hamstrung via the worst linux audio drift scenario of any that are exascerbated by the relative slow clocks of the SoCs we use.
There are some other alternatives that on a Pi3 it is possible to use 2 channels for I2S for mic and 2 channels I2S for DAC.
With a search on aliexpress you can find very cheap modules for the Pi3 and with a google you could prob get it runing quite easy as they share the same I2S clock.
Shame it supposedly doesn’t work on a Pi4.
That made me think hold on whats USB like when its on the same clock and I am testing that at this very moment or would be as found a cheap USB sound card that has the rarity of a stereo ADC.
So I am just testing how a USB sound card is to clock drift and EC as it negates the Respeaker I2S drivers and so does DIY I2S.
Passive mics on a soundcard might be less than stella but if the clock drift isn’t a problem then use powered mic modules and wire them up yourselves.
From low cost electric to ones with gpio controlled hardware gain and ALC to mems could all produce excellent results.
If you can get the I2S method running on a PI3 then I would hazard a guess clock drift is not a problem.
That just made me think that all-in-one usb of any kind might not be all that bad but just don’t recommend seperate playback & capture of any hardware that has multiple and different clock sources.
For voice AI not to be able to ‘barge in’ via any media play from a new stream to media is a huge problem for many.
Its untrue that software AEC does not work on a Pi, you need a Pi3 or above but it definately works as long as you don’t kill it with clock drift.
Its not just the PS3eye its recomending seperate capture & playback hardware isn’t a good idea and couple that with the other problems of the PS3eye why did someone recommend what for many Voice AI situations is essentially junk.
Adafruit & Sparkfun do all the above and also have a wealth of info and support.
The Enermax AP001E DreamBass USB Soundcard & Syba Sd-aud20101 have stereo ADC and a thing on aliexpress often called a S1 and looks like this is also supposedly stereo on mic input.
But still have to verify that but ebay/amazon all seem to sell them.
Stereo ADC and 2 mics can make a big leap in sensitivity and it is possible to also do software DoA (Direction of arrival)
You can even have mics in paralel on a channel but overall increases in mic and channels less returns as above 4 the simple physics of geometry and the speed of sound come into play and packing more in a small space doesn’t mean the DSP is better unless its faster to the increase in mic qty and reduction in gap spacing.
I also hate the 2mic drivers as they are as flakey as hell, but they might be all we have as the alternatives in respect to EC don’t work well enough to consider it to work.
Also you need the minium process power of somewhere around a Pi3.
Audio and voice has much interest and as SoC and the CPUs we use for AI gets stronger software methods will become much more of a valid alternative with hardware DSP getting ever cheaper and choice is more of a consideration.
I haven’t seen anyone yet with a multicore X86 monster and Turing GPU and hardware dsp as a master but there is a whole range of solutions and the satelite/master hireachy is an extremely efficient and effective model.
If there are any C/Python gurus out there please have a look at the pulseaudio and alsaplugin implementations as they are not that great and alsa-plugin webrtc_audio_processing would be really great.