[AudioI] Octo inconsistent (usually fails) behavior with arecord | aplay

[Matt Onderlinde]

Thanks Matt,

I really appreciate you getting back to me. The FullDuplexTest works.
I suspect what I was calling "failing" with arecord | aplay was just
the channels swapping like you said. After playing around more with
the default .asoundrc I found that if I moved the output chords around
I could find the output audio. I'm still not sure why Audacity
occasionally showed no output though... Anyway: for my project the
FullDuplexTest is really all I need. I added ttable lines to .asoundrc
so that all input channels get mixed to all 8 output channels (each
output is a merged version of all inputs)... so channel swapping
doesn't matter. I can just output 2 of the 8 merged output channels to
the GoPro camera.

I am seeing some overrun with the FullDuplexTest. I switched to
buster-lite headless and that seems like it might help but I'll do
more testing. Do you have any pointers for avoiding overrun? Maybe
changing the sample rate? Turning off all unnecessary services on the
Pi? I'm not a C programmer (I can edit it to some degree of course...)
and I'm new to ALSA so I'm stumbling my way through.

Thanks,

Matt

On Tue, Dec 14, 2021 at 1:04 AM Matt Flax <matt at audioinjector.net> wrote:
>
>
> On 14/12/21 4:37 am, Matt Onderlinde via People wrote:
> > Hello,
> >
> > I got the Octo and am trying to pipe the result of arecord to aplay like this:
> >
> > arecord -f cd - | aplay -
> >
> > (I've tried numerous other variations of this command...)
> >
> > This works maybe 5-10% of the time... but even when it works it
> > eventually fails (with no error messages and in the terminal it
> > appears like it's still working) and stops playing output. It doesn't
> > seem to matter what the system load is either on the pi.
>
>
> I assume that it is to do with channel swapping. Most likely due to
> asynchronous behaviour in this case.
>
> Does the gtkIOStream fullduplex test work ?
> https://github.com/flatmax/gtkiostream/blob/master/test/ALSAFullDuplexTest.C
>
>
> >
> > arecord -f cd - > /tmp/tmp.wav seems to always work... so something
> > about piping arecord to aplay doesn't seem to work.
> >
> > Also, on reboots the card is only recognized about 30% of the time. I
> > actually bought a 2nd card suspecting the first one might have a
> > hardware issue but I get the same behavior with the 2nd card.
> >
> > I can always get it working with this:
> >
> > sudo modprobe -r snd_soc_audioinjector_octo_soundcard
> > sudo modprobe -r snd_soc_cs42xx8_i2c
> > sudo modprobe -r snd_soc_cs42xx8
> > sudo modprobe snd_soc_cs42xx8
> > sudo modprobe snd_soc_cs42xx8_i2c
> > sudo modprobe snd_soc_audioinjector_octo_soundcard
>
>
> Not sure what that is due to, strange behavior.
>
>
> >
> > For the ~/.asoundrc I'm just using the out-of-the-box file that comes
> > with the .deb file from github.
> >
> > I've also tested in Audacity and see that sometimes the channels
> > record and sometimes they don't... it's just inconsistent.
>
> Again possibly due to channels swapping ?
>
>
> >
> > My pi is the Raspberry Pi 3 - Model B and I've tried both a 2.5 and 3
> > amp power supply. I've also tried several Raspbian versions including
> > the latest Buster release as well as some of the releases from 2017
> > when the .deb file and this project was really getting going.
> >
> > My project goal is to record from up to 6 microphones at once and
> > merge them into a single output channel that goes into a GoPro camera.
> > So far I can't even get to the merging step since arecord | aplay is
> > so unreliable.
>
>
> Regarding recording, it is 100% reliable to undo any form of channel
> swapping. Here is some sample code to demonstrate :
>
> https://github.com/flatmax/gtkiostream/blob/master/test/ALSAFullDuplexMinScan.C#L49-L88
>
> Basically the way it works is that 2 of the 8 input channels always have
> the same value ALWAYS! So we detect those channels and we know they are
> always channels 7 and 8. We then circularly shift the columns (channels)
> to their correct positions in the audio data matrix and we never
> experience channel swapping.
>
> That should serve your project. You could create an ALSA external plugin
> to perform this process and record from that plugin if you like.
>
> To help others ...
>
> What I would like someone to do is work out whether the output channels
> are equally shifted as the input channels. If so, then both problems are
> solved.
>
> I have worked with a student in China who was doing 16 bit recording and
> playback. They managed to get a 16 bit version working reliably for
> input and output.
>
> Matt
>
>
> > Any help would be much appreciated!!!
> >
> > Thanks,
> >
> > Matt
> >
> --
> Checkout the community email list :
> https://lists.audioinjector.net/mailman/listinfo/people
>
>