Time taken for recording to start

[hystrix1]

I have noticed that from issuing a record command (e.g. arecord -r 48000 -f S16_LE -c 2 -d 5 test.wav), it can sometimes take nearly 2 seconds for recording of the sound to actually begin. This can be seen in this waveform, where recording of the sound actually begins after 1.45 seconds:

I'm using a Raspberry Pi 3B and Stretch.

Is there a reason for this delay? Can I do something to improve it?

[r-bt]

This is also happening to me. There is about two seconds of silence before a recording actually starts.

[flatmax]

Can you tell if this is a digital delay (because of a large period time) or an analogue delay (because of a HPF on the cs4265 chip) ?

…

On 18/3/19 4:49 am, Richard Beattie wrote: This is also happening to me. There is about two seconds of silence before a recording actually starts. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAq6B-0oV8EumoA-hzWEk1wpIoDWbBnwks5vXoAngaJpZM4Yxhhd>.

[hystrix1]

Can you tell if this is a digital delay (because of a large period time) or an analogue delay (because of a HPF on the cs4265 chip) ?
…
On 18/3/19 4:49 am, Richard Beattie wrote: This is also happening to me. There is about two seconds of silence before a recording actually starts. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B-0oV8EumoA-hzWEk1wpIoDWbBnwks5vXoAngaJpZM4Yxhhd.

How can we tell? We just see the result in the recorded wav file.

[flatmax]

If there is a HPF switch, you may want to toggle this off (if it is on) to avoid any hardware latencies. How are you recording audio ? Which application ?

…

On 20/3/19 4:13 am, hystrix1 wrote: Can you tell if this is a digital delay (because of a large period time) or an analogue delay (because of a HPF on the cs4265 chip) ? … <#> On 18/3/19 4:49 am, Richard Beattie wrote: This is also happening to me. There is about two seconds of silence before a recording actually starts. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9 (comment) <#9 (comment)>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B-0oV8EumoA-hzWEk1wpIoDWbBnwks5vXoAngaJpZM4Yxhhd. How can we tell? We just see the result in the recorded wav file. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAq6B4f4m5GunAQ5fRJvR6m5sCcmF4wbks5vYRq5gaJpZM4Yxhhd>.

[hystrix1]

If there is a HPF switch, you may want to toggle this off (if it is on) to avoid any hardware latencies. How are you recording audio ? Which application ?
…
On 20/3/19 4:13 am, hystrix1 wrote: Can you tell if this is a digital delay (because of a large period time) or an analogue delay (because of a HPF on the cs4265 chip) ? … <#> On 18/3/19 4:49 am, Richard Beattie wrote: This is also happening to me. There is about two seconds of silence before a recording actually starts. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9 (comment) <#9 (comment)>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B-0oV8EumoA-hzWEk1wpIoDWbBnwks5vXoAngaJpZM4Yxhhd. How can we tell? We just see the result in the recorded wav file. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B4f4m5GunAQ5fRJvR6m5sCcmF4wbks5vYRq5gaJpZM4Yxhhd.

How would I know if there is an HPF switch? Where would I fit this? I don't have anything attached to the base card or the pre-amp board.

By the way, is there an instruction manual for this AudioInjector Ultra 2 card?

The delay in start of recording is present when using alsa "arecord" (see my initial post), and also SoX "rec" http://sox.sourceforge.net/sox.html

[flatmax]

On 21/3/19 5:08 am, hystrix1 wrote: If there is a HPF switch, you may want to toggle this off (if it is on) to avoid any hardware latencies. How are you recording audio ? Which application ? … <#> On 20/3/19 4:13 am, hystrix1 wrote: Can you tell if this is a digital delay (because of a large period time) or an analogue delay (because of a HPF on the cs4265 chip) ? … <#> On 18/3/19 4:49 am, Richard Beattie wrote: This is also happening to me. There is about two seconds of silence before a recording actually starts. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9 <#9> (comment) <#9 (comment) <#9 (comment)>>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B-0oV8EumoA-hzWEk1wpIoDWbBnwks5vXoAngaJpZM4Yxhhd. How can we tell? We just see the result in the recorded wav file. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment) <#9 (comment)>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B4f4m5GunAQ5fRJvR6m5sCcmF4wbks5vYRq5gaJpZM4Yxhhd. How would I know if there is an HPF switch? Where would I fit this? I don't have anything attached to the base card or the pre-amp board. By the way, is there an instruction manual for this AudioInjector Ultra 2 card? The delay in start of recording is present when using alsa "arecord" (see my initial post), and also SoX "rec" http://sox.sourceforge.net/sox.html <url>

OK - I'll have a look. The switches are in alsamixer - not sure if they default on or off.

[hystrix1]

On 21/3/19 5:08 am, hystrix1 wrote: If there is a HPF switch, you may want to toggle this off (if it is on) to avoid any hardware latencies. How are you recording audio ? Which application ? … <#> On 20/3/19 4:13 am, hystrix1 wrote: Can you tell if this is a digital delay (because of a large period time) or an analogue delay (because of a HPF on the cs4265 chip) ? … <#> On 18/3/19 4:49 am, Richard Beattie wrote: This is also happening to me. There is about two seconds of silence before a recording actually starts. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9 <#9> (comment) <#9 (comment) <#9 (comment)>>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B-0oV8EumoA-hzWEk1wpIoDWbBnwks5vXoAngaJpZM4Yxhhd. How can we tell? We just see the result in the recorded wav file. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment) <#9 (comment)>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B4f4m5GunAQ5fRJvR6m5sCcmF4wbks5vYRq5gaJpZM4Yxhhd. How would I know if there is an HPF switch? Where would I fit this? I don't have anything attached to the base card or the pre-amp board. By the way, is there an instruction manual for this AudioInjector Ultra 2 card? The delay in start of recording is present when using alsa "arecord" (see my initial post), and also SoX "rec" http://sox.sourceforge.net/sox.html
OK - I'll have a look. The switches are in alsamixer - not sure if they default on or off.

@flatmax I think I was confused with your statement "If there is an HPF switch..." and assumed because you said that, it wasn't a software switch.

Anyway, I have tried setting the switch using amixer cset name='ADC HPF Switch' 1 and amixer cset name='ADC HPF Switch' 0, and there is a difference, but still a delay:

HPF Switch OFF:

HPF Switch ON:

I'll work my way through the list of controls that amixer controls shows, and see if anything else makes any difference.

[flatmax]

I see the delay now. Can you please explain your setup for recording ?

…

On 22/3/19 5:05 am, hystrix1 wrote: On 21/3/19 5:08 am, hystrix1 wrote: If there is a HPF switch, you may want to toggle this off (if it is on) to avoid any hardware latencies. How are you recording audio ? Which application ? … <#> On 20/3/19 4:13 am, hystrix1 wrote: Can you tell if this is a digital delay (because of a large period time) or an analogue delay (because of a HPF on the cs4265 chip) ? … <#> On 18/3/19 4:49 am, Richard Beattie wrote: This is also happening to me. There is about two seconds of silence before a recording actually starts. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9 <#9> <#9 <#9>> (comment) <#9 <#9> (comment) <#9 (comment) <#9 (comment)>>>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B-0oV8EumoA-hzWEk1wpIoDWbBnwks5vXoAngaJpZM4Yxhhd. How can we tell? We just see the result in the recorded wav file. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 <#9> (comment) <#9 (comment) <#9 (comment)>>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq6B4f4m5GunAQ5fRJvR6m5sCcmF4wbks5vYRq5gaJpZM4Yxhhd. How would I know if there is an HPF switch? Where would I fit this? I don't have anything attached to the base card or the pre-amp board. By the way, is there an instruction manual for this AudioInjector Ultra 2 card? The delay in start of recording is present when using alsa "arecord" (see my initial post), and also SoX "rec" http://sox.sourceforge.net/sox.html OK - I'll have a look. The switches are in alsamixer - not sure if they default on or off. @matt <https://github.com/matt> I think I was confused with your statement "If there is an HPF switch..." and assumed because you said that, it wasn't a software switch. Anyway, I have tried setting the switch using |amixer cset name='ADC HPF Switch' 1| and |amixer cset name='ADC HPF Switch' 0|, and there is a difference, but still a delay: HPF Switch OFF: test_HPF_off <https://user-images.githubusercontent.com/16988358/54774143-f1176a80-4c02-11e9-98ab-e17545f7a4a2.GIF> HPF Switch ON: test_HPF_on <https://user-images.githubusercontent.com/16988358/54774182-08eeee80-4c03-11e9-9021-e72ac19bf85b.GIF> I'll work my way through the list of controls that |amixer controls| shows, and see if anything else makes any difference. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAq6B_otb_AyUoGTqUYvhOKRQFmZDm0Dks5vY8ndgaJpZM4Yxhhd>.

[hystrix1]

I see the delay now. Can you please explain your setup for recording ?

My setup is using the Ultra 2 sound card attached to a Raspberry Pi (3B+ or Zero) running the latest version of Raspbian Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux.

Recording is set to use the on-board mics: amixer cset name='ADC Mux' 0
Volume is: amixer cset name='PGA Volume' 40

[rahealy]

I can confirm the behavior @hystrix1 is experiencing. I'm happy to assist if more information is needed.

$ cat /proc/device-tree/model
Raspberry Pi 3 Model B Rev 1.2

$ uname -a
Linux rev 4.19.57-v7+ #1244 SMP Thu Jul 4 18:45:25 BST 2019 armv7l GNU/Linux

$ /opt/vc/bin/vcgencmd version
Jul  9 2019 14:42:57 
Copyright (c) 2012 Broadcom
version 6c3fe3f096a93de3b34252ad98cdccadeb534be2 (clean) (release) (start_x)

$ amixer cset name='ADC Mux' 0
numid=18,iface=MIXER,name='ADC Mux'
  ; type=ENUMERATED,access=rw------,values=1,items=2
  ; Item #0 'MIC'
  ; Item #1 'LINEIN'
  : values=0

$ amixer cset name='PGA Volume' 40
numid=1,iface=MIXER,name='PGA Volume'
  ; type=INTEGER,access=rw---R--,values=2,min=0,max=48,step=0
  : values=40,40
  | dBscale-min=-12.00dB,step=0.50dB,mute=0

$ amixer cset name='ADC HPF Switch' 0
numid=7,iface=MIXER,name='ADC HPF Switch'
  ; type=BOOLEAN,access=rw------,values=1
  : values=off

$ arecord -r 192000 -f S16_LE -c 2 -d 5 ./tmp/test.wav  
Recording WAVE './tmp/test.wav' : Signed 16 bit Little Endian, Rate 192000 Hz, Stereo

The only messages regarding the CS4265 in dmesg output are during boot:

[    4.176286] cs4265 1-004e: CS4265 Version 3
[    4.184871] asoc-simple-card soc:sound: cs4265-dai1 <-> 3f203000.i2s mapping ok
[    4.185176] asoc-simple-card soc:sound: control 2:0:0:SPDIF Switch:0 is already present
[    4.185194] cs4265 1-004e: ASoC: failed to add widget SPDIF dapm kcontrol SPDIF Switch: -16  

I'm not sure what the odd waveforms at the beginning are but the delay is pretty clear.

[rahealy]

I found I missed something in the dmesg output that corresponds with the recording start:

[ 5045.091119] bcm2835-i2s 3f203000.i2s: I2S SYNC error!

This might however be a problem with using ribbon cable to connect the Ultra to the RPi and has nothing to do with the delay.

@hystrix1 do you see anything like this in your dmesg output?

[hystrix1]

Yes, I also see the I2S SYNC error. I read here that it is harmless:
raspberrypi/linux#1949

The delay in recording and associated "noise" in ultrasound certainly makes sound-activated recording a challenge with this sound card.

[rahealy]

Interesting observation regarding loopback:

Given:

$ amixer cset name='ADC HPF Switch' 0
$ amixer cset name='ADC Soft Ramp Switch' 0 
$ amixer cset name='ADC Mux' 'MIC'
$ amixer cset name='PGA Volume' 40
$ amixer cset name='Loopback Switch' 0
$ arecord -r 32000 -f S16_LE -c 2 -d 20 ./tmp/test.wav

We get the following delay:

Turn on the loopback:

$ amixer cset name='Loopback Switch' 1
$ arecord -r 32000 -f S16_LE -c 2 -d 20 ./tmp/test.wav

We get no delay (the noise is from a room fan - other tests confirm the microphones are still picking up audio):

So a workaround might just be turning on the loopback:

$ amixer cset name='Loopback Switch' 1

[rahealy]

After poking around the driver code and skimming the datasheet for the cs4265 my current guess is the delay is somehow related to the high pass filter settling time.

In the table on page 16 of the datasheet found here:

https://statics.cirrus.com/pubs/proDatasheet/CS4265_F4.pdf

the settling time is listed as 10^5 / Fs where Fs is the sampling rate. Solving for 48kHz sample rate: 10^5 / 48000 = ~2 seconds - 2 seconds seems about right for what we're seeing.

I've found driver code here:

https://github.com/torvalds/linux/blob/master/sound/soc/codecs/cs4265.h
https://github.com/torvalds/linux/blob/master/sound/soc/codecs/cs4265.c

Depending on how the cs4265 works we might be able to take care of the settling time and offset calibration at boot or maybe somewhere in the cs4265_set_bias_level() callback. I don't know how it all works exactly.

I can compile and load the above code as a module but I'm still learning how to replace the existing snd_soc_cs4265 module. It seems it's not as simple as running modprobe -r snd_soc_cs4265 then loading my own version with insmod.

[hystrix1]

Interesting observation regarding loopback:

Given:

$ amixer cset name='ADC HPF Switch' 0
$ amixer cset name='ADC Soft Ramp Switch' 0 
$ amixer cset name='ADC Mux' 'MIC'
$ amixer cset name='PGA Volume' 40
$ amixer cset name='Loopback Switch' 0
$ arecord -r 32000 -f S16_LE -c 2 -d 20 ./tmp/test.wav

We get the following delay:

Turn on the loopback:

$ amixer cset name='Loopback Switch' 1
$ arecord -r 32000 -f S16_LE -c 2 -d 20 ./tmp/test.wav

We get no delay (the noise is from a room fan - other tests confirm the microphones are still picking up audio):

So a workaround might just be turning on the loopback:

$ amixer cset name='Loopback Switch' 1

Many thanks for the tip. I have tried this and it does seem to work....no delay :-)

[flatmax]

Any ideas for why loopback works ?
It is possible that it bypasses DAPM and keeps the supplies high - or is it something else ?

[rahealy]

@flatmax Good questions. I've added some printk()'s to the driver code among other things. See:

https://github.com/rahealy/snd_soc_cs4265

It looks like when the Loopback Switch is on the DAPM level is SND_SOC_BIAS_ON. On this level it appears that the driver clears the PDN bit of the Power Control register in the cs4265 bringing it into normal operation. By the time we call arecord it's likely the inputs have already settled.

When the Loopback Switch is off the DAPM level is SND_SOC_BIAS_STANDBY. On this level it appears that the driver sets the PDN bit of the Power Control register in the cs4265 putting it into low power state. When we call arecord DAPM runs through SND_SOC_BIAS_PREPARE to SND_SOC_BIAS_ON in a fraction of a second - well under the ~2 second settling time specified in the datasheet.

So, I guess the question is whether the behavior is correct based on what DAPM expects.

Looks like you (@flatmax) have already gotten commits to driver code accepted into the Linux tree. I'm happy to implement suggestions and/or test if required.

Thank you much!

-Richard

[rahealy]

I'm making the assumption above that the settling time is the issue and not an analog issue on the preamp board. I'm working with what I can observe sans schematics and an oscilloscope.

Edit: Unplugged the preamp board. Behavior still exists. If it's really an analog issue then it's on the Ultra board.

[hystrix1]

@rahealy or @flatmax : Are there any disadvantages in having Loopback on?

[flatmax]

OK - we have confirmed it is a DAPM issue (nice work @rahealy ). Some large caps are taking a while to settle. We should think of a way to have an option to turn DAPM or at least bias settings off for this board (if wanted) - possibly a device tree option or a second device tree. This would get around the requirement of having loopback on which will make life hard for people who want to play sounds and record them at the same time - yet don't want long recording startup delays.

Regarding having loopback on, in short it seems like a way to bypass DAPM, which means the chip is constantly biased and ready to go.
Longer story ...
I haven't tested loopback, however it is likely that it is either a digital or analogue loopback connection internal to the CS4265 chip.

If it is a digital loopback, then anything played out will come back in with no extra noise.

If it is an analogue loopback, then anything played out will come back in with a very low noise floor added.

[rahealy]

Turning on the Loopback Switch doesn't seem to return the currently playing audio [Edit: input] output.

As an experiment I connected L/R outputs to L/R inputs, made sure the Loopback Switch was turned off, played a test waveform and recorded the same successfully. Full-duplex operation seems to work as intended.

Turning loopback on, removing the connection between output to input connectors then playing a test waveform and recording I get almost total silence:

[flatmax]

Nice work ! It seems that loopback routes ADC back to DAC digitally. If you left the looping back RCAs attached in an experiment do you get feedback ? Here is a blurb from the datasheet ... It seems that the loopback is to route ADC input directly to DAC output digitally, referencing the datasheet : http://www.mouser.com/ds/2/76/CS4265_F3-471549.pdf "The CS4265 supports an internal digital loopback mode in which the output of the ADC is routed to the input of the DAC. This mode may be activated by setting the LOOP bit in the Signal Selection register." Matt

…

On 9/8/19 6:57 am, Richard A. Healy wrote: Turning on the Loopback Switch doesn't seem to return the currently playing audio input. As an experiment I connected L/R outputs to L/R inputs, made sure the Loopback Switch was turned /off/, played a test waveform and recorded the same successfully. Full-duplex operation seems to work as intended. Turning loopback /on/, removing the connection between output to input connectors then playing a test waveform and recording I get almost total silence: image <https://user-images.githubusercontent.com/8713278/62737162-c3d22a00-b9f4-11e9-8dd4-61623843e1a2.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9?email_source=notifications&email_token=AAFLUB7WW5VJBCPZJSWSBLDQDSCCJA5CNFSM4GGGDBO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD344D7I#issuecomment-519684605>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFLUB2L4HQOICRIQ3PLBZLQDSCCJANCNFSM4GGGDBOQ>.

[rahealy]

@flatmax wrote:

If you left the looping back RCAs attached in an experiment do you get feedback?

It appears that this is the case only when the inputs haven't settled yet. In the first 1/4 second there's a blip of what I suspect is a highly distorted version of my 1kHz sine test wave:

When the test is run after inputs have been given time to settle I get silence + a bit of noise: