You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am attempting to generate short sound stimulus bursts and record the results using the R Pi. Several issues have come up and been fairly well solved. these include:
I'm using ultra sound so needed more than 48k sample rate. Microphones are I2S mems devices running at 64000 sps. Playback uses common USB sound card with 96000 sps. Hence the two streams are running at different sample rates. (the USB device will not run at 64k)
An InputStream and OuputStream were set up for these devices with call back functions. Everything works, but it became clear that the two streams did not run at the same "real time" rate based on the expected 64k and 96k sample rates. Since I'm sending out only short bursts of sound, I found a work-around that involved shifting the "active" sound inside the "chirp block" using the timing provided by the callback functions. I also found I could 'trim the drift' by adjusting the number of frames in the block by one or two counts so the drift would either let the recording fall behind or get ahead of the playback over time.
This leaves the real problem I'm left with, which is underflows on the microphone recording channel. These have been intermittent but regular on the order of one event/minute using 50ms data blocks. When looking carefully at the timing, I found that the Callback was happening almost exactly as the buffer became full. There seemed to be no allowance for any "time slop" to deal with the buffer.
I also tried a blocking stream.read instead of the callback. That seems to work slightly better - maybe reducing the number or events by a factor of two or so, but it did not eliminate them. My suspicion is that operating system events are getting in the way of a timely buffer read. Any idea about what I can do to solve this. (something like a "disable interrupts" function for a microprocessor that would ensure nothing is getting in the way of my read?)
I suspect the problem may be with the I2S mic driver... I'm using this: https://github.com/PaulCreaserML/rpi-i2s-audio
Even though the mics are specified only to 64ksps, I found they will work at 96ksps. Hence I thought maybe I could use a single bidirectional stream with only one clock rate... But, trying that, I could not get the mic device to be accepted by ,if I recall, PortAudio.
The text was updated successfully, but these errors were encountered:
I am attempting to generate short sound stimulus bursts and record the results using the R Pi. Several issues have come up and been fairly well solved. these include:
I suspect the problem may be with the I2S mic driver... I'm using this: https://github.com/PaulCreaserML/rpi-i2s-audio
Even though the mics are specified only to 64ksps, I found they will work at 96ksps. Hence I thought maybe I could use a single bidirectional stream with only one clock rate... But, trying that, I could not get the mic device to be accepted by ,if I recall, PortAudio.
The text was updated successfully, but these errors were encountered: