ALSAAudioError: No such file or directory

[MichielBontenbal]

When testing on the NEW Pi I get the following error:

[/home/pi/.config/pulse/client.conf:26] Unknown lvalue 'utospawn' in section 'n/a'.
Exception in thread captor:
Traceback (most recent call last):
File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
self.run()
File "/usr/lib/python3.7/threading.py", line 865, in run
self._target(*self._args, **self._kwargs)
File "/home/pi/OpenEars/devicehive-dev/audio/captor.py", line 85, in _capture
ad = AudioDevice()
File "/home/pi/OpenEars/devicehive-dev/audio/alsadevice.py", line 28, in init
self.inp = alsaaudio.PCM(alsaaudio.PCM_CAPTURE, alsaaudio.PCM_NORMAL, device=device)
alsaaudio.ALSAAudioError: No such file or directory [rate16000Hz]

[gmos]

You did not install one of the set-up files where the proper pseudo-device is created in the ALSA framework. Hence the open from this device fails in Python. Assuming you are using the UMIK, youll need to install the OpenEars/install/pi/umik.asoundrc configuration into ALSA to create the pseudo devices.

[MichielBontenbal]

I've done the following to solve this issue:

as per the instruction, make sure there is a file /home/pi/.asoundrc.
check with arecord -l the number of the card the UMIK uses.

with nano, change .asoundrc and make sure the following segment is correct (card number in bold:

pcm.umik {
type plug
slave {
pcm "hw:2,0"
rate 48000
channels 2
format S24_3LE
}

[gmos]

Probably won’t work. This sets up the UMIC only as a stereo 48 kHz device. Guess you have old instructions. Checkout the file given in the previous comment. This is the stuff that will transform the UMIK into a 16 kHz mono pseudo device. And that is what serval wants to open. So add this file at the end of the .asoundrc and try. If it works, perhaps update the documentation. Please not that there are also files for other type of microphones.

[MichielBontenbal]

The script works ;-) Data is coming into the IoT Platform. If there are newer instructions, I'll be happy to receive these!

[Bionerdy]

Super👍

…

On Tuesday, 26 October 2021, Michiel Bontenbal ***@***.***> wrote: The script works ;-) Data is coming into the IoT Platform. If there are newer instructions, I'll be happy to receive these! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADNBX2QDLAVPDE6BPEKVU2DUI3QSVANCNFSM5GXSHTUQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[gmos]

Check a recording. Just data coming in is not enough. The input stage of serval does not do its own transcoding currently (has been disabled/commented out). So the incoming data is already expected to be 16 kHz sample rate and mono. This can only work if ALSA already provides the transcoding from UMIK's native 48 kHz stereo (2/3/4?? bytes per sample) to 16 kHz mono, 2 bytes per sample.

Wonder if that works for your patch. You may be mangling the recording data beyond recognition.

This is by the way a murky area in the Serval suite. Many changes have been made as can be seen from the code. Mostly not well documented or propagated to all affected files (like writeups and documentations).

We should consider to clean up / refactor and document this bit thoroughly. It would be a good investment since we will need a good input stage for whatever future classifier we are going to use. I also have read somewhere that the Raspberry guys have decided to swap ALSA for something new (perhaps better). We should verify this and if true perhaps follow this move to new audio libraries.

To check your set-up you might want to write a couple of lines of Python. Just copy the open statement of the audio device from the Serval code and then read a 10 second sample into a buffer. If your config is ok you should get something close to 10 (sec) * 16 * 1024 (samples/sec) * 2 (byte per sample) =about 399 kB. If you get more you are not transcoding properly.

[MichielBontenbal]

Agree 100%. We also discussed this in the summer. This is something we'll have to work on. I'll add some code to the OpenEars audio analysis.ipynb (see folder data science in this repo). Probably ready later this week.
This will be only the first step...

[MichielBontenbal]

Gijs, see folder datascience for 5 samples we recorded in september and the notebook OpenEars audio analysis.ipynb. I use librosa. the recorded samples have a samplerate=16000 Hz.