cloudedbats_wurb_2020
cloudedbats_wurb_2020 copied to clipboard
USB mic works with ALSA `arecord`, but not with wurb2020
Hi,
I was tryng different not officially supported USB microphones.
Unsurprisingly, they didn't work. They were, however, visible in alsamixer
and did work with arecord
.
So, first my question is, what is the benefit provided by pyalsaaudio
over direct calls to command line utility arecord
?
After some fiddling around, I realized that one of my mics provides 32-bit floating number stream, which is suported by ALSA and arecord
, but it seems that wurb2020 has the int16
type hard-coded. How hard would it be to make the changes to support mics with output different from int16
?
Cheers
Hi slowglow, I have used other microphones too, but all of them can deliver a 16 bits data stream when ALSA asks for it. 12 bits, like what the AudioMoth can deliver, is good enough and you will not need more than 16 bits. Strange if a 32 bits mic can't deliver 16 bits. I will not add support for 32 bits in current version, maybe in a future version 1.0, if it is needed for some reason. If you check the code for the pathfinder detector there is a better designed sond capture module with stereo support, and that one may be used in a future version 1.0 detector. I hope you noticed the possibility to specify a part of the mics id string in "wurb_rec_start.sh" and don't need to hack the code. What mic are you using? For example HiFiBerry DAC+ ADC works for me.
Thanks for commenting. I will take a look at the pathfinder detector code. Multi-channel support is really interesting to me.
For the time being, I am trying to track down where the current wurb2020 code is failing, but I do not see any error messages when I ssh into the raspberry pi console and run bash /home/pi/cloudedbats_wurb_2020/wurb_rec_start.sh
manually. It starts the uvicorn server, but no files are written.
I have set the WURB_REC_INPUT_DEVICE
and WURB_REC_INPUT_DEVICE_FREQ_HZ
in wurb_rec_start.sh
. (Thanks for this change, it was very helpful).
If you can tell me where to insert the breakpoints, I will try to look around and debug.
Regarding the hardware, here is what I get from ALSA with -D hw
option (access the hardware device directly):
arecord -D hw:1,0 --dump-hw-params -d1 > /dev/null
Output:
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:1,0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S32_LE
SUBFORMAT: STD
SAMPLE_BITS: 32
FRAME_BITS: 128
CHANNELS: 4
RATE: [44100 192000]
PERIOD_TIME: [125 743039)
PERIOD_SIZE: [6 32768]
PERIOD_BYTES: [96 524288]
PERIODS: [2 1024]
BUFFER_TIME: (62 1486078)
BUFFER_SIZE: [12 65536]
BUFFER_BYTES: [192 1048576]
TICK_TIME: ALL
--------------------
arecord: set_params:1343: Sample format non available
Available formats:
- S32_LE
And here is what I get from ALSA with -D plughw
option (inserts sample rate and format conversion plugins, if needed):
arecord -D plughw:1,0 --dump-hw-params -d1 > /dev/null
Output:
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "plughw:1,0":
--------------------
ACCESS: MMAP_INTERLEAVED MMAP_NONINTERLEAVED MMAP_COMPLEX RW_INTERLEAVED RW_NONINTERLEAVED
FORMAT: S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE MU_LAW A_LAW IMA_ADPCM S20_LE S20_BE U20_LE U20_BE S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE U18_3BE
SUBFORMAT: STD
SAMPLE_BITS: [4 64]
FRAME_BITS: [4 640000]
CHANNELS: [1 10000]
RATE: [4000 4294967295)
PERIOD_TIME: [125 743039)
PERIOD_SIZE: (0 3191328204)
PERIOD_BYTES: (0 4294967295)
PERIODS: (0 4294967295]
BUFFER_TIME: [1 4294967295]
BUFFER_SIZE: [1 4294967294]
BUFFER_BYTES: [1 4294967295]
TICK_TIME: ALL
--------------------
Hi,
well it's hard-coded, but it's a one-liner :) I had the same problem with a USB mic, that can record 16 bits and 24 bits at 192KHz fine using arecord - but: When recording 16bits with that mic with arecord, it's actually converted from 24 to 16 bits. You can see this, while adding arecords option "-v". Wurb-recordings where just loud noise. I've changed the line 597 of wurb_recorder.py from:
self.wave_file.setsampwidth(2) # 2=16 bits.
to:
self.wave_file.setsampwidth(3) # 2=16 bits, 3=24bits, 4=32bits
now I have proper recordings, even in 24 bits - that's fantastic! :)
I've also tested 32 bits, which gave me 32 bit wave files, but noise again. My mic can only do 24 bits.
Here some info about my mic via "more /proc/asound/card1/stream0": Capture: Status: Running Interface = 1 Altset = 1 Packet Size = 600 Momentary freq = 192000 Hz (0xc0.0000) Interface 1 Altset 1 Format: S24_3LE Channels: 1 Endpoint: 0x82 (2 IN) (ASYNC) Rates: 48000, 44100, 192000, 96000 Bits: 24 Channel map: MONO
Thank's sail2themoon for your comments. In the next major release I'm planning for a YAML-based configuration file with optional support for various mics. Your tests indicates that there is an automatic conversion from 24 to 16 bits, witch is great but I have to dig deeper into that. What kind of mics "can only do 24 bits"? 32 bits is easier to handle than 24 bits, but I have no code for that now. Also stereo support is in the pipeline.
sounds great! The conversion is only done with Alsa/arecord, if an input device can't handle a specific bit-rate or bit-width. This can look like the input device is actually capable of it. I don't think Wurb does any conversion, because my mic just put out noise with 16bit. That was when I discovered, that arecord does conversion.
My mic is one of the cheapest 192KHz-USB-mics from "Jeemak", with a modified microphone capsule by myself - but: I think the 192KHz are fake: I get really strange recordings above ~50KHz, seen in the spectrogram.