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

6mics / linear 4 mics: fails to record against v5.10 kernel #290

Closed
HinTak opened this issue Mar 16, 2021 · 32 comments
Closed

6mics / linear 4 mics: fails to record against v5.10 kernel #290

HinTak opened this issue Mar 16, 2021 · 32 comments

Comments

@HinTak
Copy link
Contributor

HinTak commented Mar 16, 2021

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)

@lxne
Copy link

lxne commented Apr 5, 2021

Same issue.
Not working on my Pi 4 with most recent buster and kernel v5.10.

@flattman
Copy link

flattman commented Apr 5, 2021

Hey,
i have the same problem with my 6 mic array. I can play a wav file but can not record. It only produces empty wave files with this cmd arecord -Dac108 -f S32_LE -r 16000 -c 8 a.wav, same in audacity.

I have installed a fresh raspbian and only installed the driver (v5.9).

my system:
Linux raspberrypi 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l GNU/Linux
Raspbian GNU/Linux 10 (buster)
Raspberry Pi 4 Model B Rev 1.2

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.

@lxne
Copy link

lxne commented Apr 5, 2021

I just figured out that for my Pi 4 and 4 mic linear array the respeaker/seeed-voicecard/master with '--compat-kernel'-option works.

@Drizzt321
Copy link

@xiongyihui yes, except that downgrades the kernel to an older version.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 6, 2021

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...

@HinTak
Copy link
Contributor Author

HinTak commented Apr 7, 2021

Yes, the driver broke between 5.4 and 5.8 . arecord blocking at snd_pcm_mmap_readi().

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.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 8, 2021

@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.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 9, 2021

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.
https://github.com/HinTak/RaspberryPi-Dev/blob/master/Downgrading-Pi-Kernel.md . People can go backward and hold, until the issue is fixed, I guess.

Edit : correcting url

@lxne
Copy link

lxne commented Apr 9, 2021

Hi @HinTak, I do have the linear 4-mic.
Thank you so much for your investigations.
Your link to the how-to switch sends me to 'not found'.
Am I missing something?

@BeckyHeath
Copy link

@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/

@flattman
Copy link

flattman commented Apr 9, 2021

@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?

@HinTak
Copy link
Contributor Author

HinTak commented Apr 9, 2021

@lxne sorry, corrected the url
https://github.com/HinTak/RaspberryPi-Dev/blob/master/Downgrading-Pi-Kernel.md

@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.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 9, 2021

@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).

@HinTak
Copy link
Contributor Author

HinTak commented Apr 9, 2021

Btw, Ubuntu groovy is using kernel 5.8.x .

@HinTak
Copy link
Contributor Author

HinTak commented Apr 9, 2021

Comparing the boot message under 5.4 and 5.10, one line is missing:

seeed-voicecard soc:sound: ac10x-codec.1-0035 <-> fe203000.i2s mapping ok

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...

@HinTak
Copy link
Contributor Author

HinTak commented Apr 13, 2021

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.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 13, 2021

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 :-( :

commit 1d5cd5254f67bc65622f4cac04c25d6e082f21b0
Author: Pierre-Louis Bossart <[email protected]>
Date:   Fri Jun 12 15:40:50 2020 -0500

    ASoC: soc-pcm/compress: reduce verbosity on mapping ok messages
    
    With dynamic debug not enabled, we still get these messages:
    
    [   48.133586] sof_sdw sof_sdw: rt711-aif1 <-> SDW0 Pin2 mapping ok
    [   48.133595] sof_sdw sof_sdw: rt711-aif1 <-> SDW0 Pin3 mapping ok
    [   48.133650] sof_sdw sof_sdw: sdw:1:25d:1308:0 <-> SDW1 Pin2 mapping ok
    [   48.133658] sof_sdw sof_sdw: rt715-aif2 <-> SDW3 Pin2 mapping ok
    [   48.133666] sof_sdw sof_sdw: intel-hdmi-hifi1 <-> iDisp1 Pin mapping ok
    [   48.133672] sof_sdw sof_sdw: intel-hdmi-hifi2 <-> iDisp2 Pin mapping ok
    [   48.133677] sof_sdw sof_sdw: intel-hdmi-hifi3 <-> iDisp3 Pin mapping ok
    [   48.133712] sof_sdw sof_sdw: snd-soc-dummy-dai <-> Headphone 0 mapping ok
    [   48.133733] sof_sdw sof_sdw: snd-soc-dummy-dai <-> Headset mic 1 mapping ok
    [   48.133746] sof_sdw sof_sdw: snd-soc-dummy-dai <-> SDW1-speakers 2 mapping ok
    [   48.133762] sof_sdw sof_sdw: snd-soc-dummy-dai <-> Microphones 4 mapping ok
    [   48.133774] sof_sdw sof_sdw: snd-soc-dummy-dai <-> HDMI1 5 mapping ok
    [   48.133798] sof_sdw sof_sdw: snd-soc-dummy-dai <-> HDMI2 6 mapping ok
    [   48.133809] sof_sdw sof_sdw: snd-soc-dummy-dai <-> HDMI3 7 mapping ok
    
    This is not really useful for most users, demote to dev_dbg()
    

@HinTak HinTak changed the title fails to record against v5.10 kernel 6mics / linear 4 mics: fails to record against v5.10 kernel Apr 15, 2021
@HinTak
Copy link
Contributor Author

HinTak commented Apr 17, 2021

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...

@HinTak
Copy link
Contributor Author

HinTak commented Apr 20, 2021

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.

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

@HinTak
Copy link
Contributor Author

HinTak commented Apr 20, 2021

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. :-)

@plbossart
Copy link

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.

You will see the log if you enable dynamic debug.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 20, 2021

@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.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 24, 2021

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.

HinTak added a commit to HinTak/seeed-voicecard that referenced this issue Apr 24, 2021
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]>
HinTak added a commit to HinTak/seeed-voicecard that referenced this issue Apr 24, 2021
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]>
HinTak added a commit to HinTak/seeed-voicecard-x that referenced this issue Apr 27, 2021
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]>
@HinTak
Copy link
Contributor Author

HinTak commented Apr 27, 2021

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).
@Drizzt321 @BeckyHeath @flattman @lxne @xiongyihui

I am somewhat against the --compat-kernel option (hence removed it), but if you want to downgrade the kernel, here is how to do it properly (and undo):
https://github.com/HinTak/RaspberryPi-Dev/blob/master/Downgrading-Pi-Kernel.md
In the course of looking at this, I have gone back and forth between 5.4 and 5.10 (and occasionally even 4.19), sometimes a few times a day so anything between 5.4 and 5.10 (including Ubuntu's 5.8) should work; and built and booted custom built kernels... There are a few in-progress write-ups, Building-the-Linux-Kernel.md , Debugging-Regressions.md Unload-Reloading-Part-2.md which hopefully will get updated before I forget all the details.

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...
Please feel free to donate at the bottom of the page at https://hintak.github.io/ .

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 HinTak closed this as completed Apr 27, 2021
@Drizzt321
Copy link

@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...

@HinTak
Copy link
Contributor Author

HinTak commented Apr 28, 2021

@Drizzt321 aplay -L gives you a list of usable logical devices. ac101 and hw:... interacts directly with the hardware and is limited by what the hardware permits. If you want rate conversions etc, use the plugin... ones; these are defined in the asound.conf, and you can make up your own config too, to get alsa (the upper closer to application part) to do the conversion for you.

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!

@Drizzt321
Copy link

@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.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 28, 2021

@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).

@Drizzt321
Copy link

@HinTak Hm...

arecord -r 16000 test2.wav and then aplay test2.wav, and I hear it out of the mono speaker I have plugged in to the mono JST jack.

When I run the mycroft-mic-test, it doesn't tell me what the record command/values are, but it does share the playback aplay -Dhw:0,0 WAV_FILE. It then fails, saying sample format not available.

When I play it back manually, aplay /tmp/test.wav it just gives me silence, I presume because it's playing it out the wrong channels. When I specify the hardware aplay -D "plughw:0,0" /tmp/test.wav I hear it fine.

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.

$ mycroft-mic-test -l
Stopping audio (22128)...stopped.
Stopping speech (22151)...stopped.
Already up to date.
Initializing...
Starting audiotest
 Initializing...
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.front
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround21
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround21
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround40
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround41
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround50
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround51
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround71
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
ALSA lib pcm_a52.c:823:(_snd_pcm_a52_open) a52 is only for playback
ALSA lib conf.c:5014:(snd_config_expand) Unknown parameters {AES0 0x6 AES1 0x82 AES2 0x0 AES3 0x2  CARD 0}
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM iec958:{AES0 0x6 AES1 0x82 AES2 0x0 AES3 0x2  CARD 0}
ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
ALSA lib pcm_params.c:2226:(snd1_pcm_hw_refine_slave) Slave PCM not usable
ALSA lib pcm_params.c:2226:(snd1_pcm_hw_refine_slave) Slave PCM not usable
ALSA lib pcm_params.c:2226:(snd1_pcm_hw_refine_slave) Slave PCM not usable
ALSA lib pcm_params.c:2226:(snd1_pcm_hw_refine_slave) Slave PCM not usable
ALSA lib pcm_dmix.c:1043:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
ALSA lib pcm_params.c:2226:(snd1_pcm_hw_refine_slave) Slave PCM not usable
ALSA lib pcm_params.c:2226:(snd1_pcm_hw_refine_slave) Slave PCM not usable
ALSA lib pcm_params.c:2226:(snd1_pcm_hw_refine_slave) Slave PCM not usable
ALSA lib pcm_params.c:2226:(snd1_pcm_hw_refine_slave) Slave PCM not usable
ALSA lib pcm_params.c:2226:(snd1_pcm_hw_refine_slave) Slave PCM not usable
ALSA lib pcm_params.c:2226:(snd1_pcm_hw_refine_slave) Slave PCM not usable
ALSA lib pcm_params.c:2226:(snd1_pcm_hw_refine_slave) Slave PCM not usable
ALSA lib pcm_params.c:2226:(snd1_pcm_hw_refine_slave) Slave PCM not usable
 ====================== Audio Devices ======================
  Index    Device Name
   2:       pulse
   6:       default

 ========================== Info ===========================
 Input device: Default device @ Sample rate: 16000 Hz
 Playback commandline: aplay -Dhw:0,0 WAV_FILE

 ===========================================================
 ==         STARTING TO RECORD, MAKE SOME NOISE!          ==
 ===========================================================
 ===========================================================
 ==           DONE RECORDING, PLAYING BACK...             ==
 ===========================================================
Playing WAVE '/tmp/test.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Mono
aplay: set_params:1339: Sample format non available
Available formats:
- S32_LE
An error occured while playing back audio (1)
Restarting Mycroft voice service...
Already up to date.
Initializing...
Starting background service audio
Already up to date.
Initializing...
Starting background service voice

@HinTak
Copy link
Contributor Author

HinTak commented Apr 29, 2021

@Drizzt321 I see you are doing aplay ...hw:0,0... - that's likely wrong... There is another phone jack on the respeaker board itself, and it is 1,0!

@lxne
Copy link

lxne commented Apr 29, 2021

@HinTak I did send you some Euros, hope you can use 'em.

@HinTak
Copy link
Contributor Author

HinTak commented Apr 29, 2021

Thanks @lxne, I appreciate that!

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

No branches or pull requests

6 participants