Re: [PATCH] wm8962: add a simple DMIC enable control
On Wed, Feb 02, 2022 at 12:55:04PM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.02.2022 um 10:46 +0000 schrieb Charles Keepax:
On Wed, Feb 02, 2022 at 11:17:34AM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.02.2022 um 09:53 +0000 schrieb Charles Keepax:
On Tue, Feb 01, 2022 at 04:01:13PM +0100, Martin Kepplinger wrote:
Do you have a code example from a different codec that has roughly what is missing here? (the sound subsystem is new to me)
Full disclosure this is complete untested, but it should be pretty close. Let me know if it does the trick and I will send a proper patch to the list. I do have a Librem 5 in a draw somewhere so can pull that out if we get really stuck, but that might have to wait until the weekend :-).
I don't know if you guys are using the analogue bypass paths around the digital core on the chip. I think those will still work with the mics set to digital, so I have left the routes as is, but that might require some checking at some point.
ok that's great and seems to work! that's luxury.
Excellent glad that is working for you, I will prep up a proper patch and send it to the list. Should get that done tomorrow morning, if I don't manage it this afternoon.
Volume / sensitivity of Analog input is too low, I saw that before. What would you try to change that?
Hmm... you say you saw this before? I assume the input volume is always low, not just low sometimes? I would probably start by checking the voltage you have on the micbias, make sure that is as expected. Does the signal coming into the IN3R pin look low on a scope or is it just the level after it has been through the ADC on the chip that seems low?
The input routing on this chip is pretty byzantine, the output of just "amixer" showing all the controls in the relevant use-case would probably be helpful to look over. I suspect there is a reasonable chance something around the input PGA is not configured to match the hardware, although I am not the most familiar with this part so hard to guess at exactly what off the top of my head.
Finally, do you know how much the amplitude is off by?
you can do all of our tasks if you want to :)
Ha! Not sure about that, but happy to help out where I can.
Thanks, Charles
Am Mittwoch, dem 02.02.2022 um 13:35 +0000 schrieb Charles Keepax:
On Wed, Feb 02, 2022 at 12:55:04PM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.02.2022 um 10:46 +0000 schrieb Charles Keepax:
On Wed, Feb 02, 2022 at 11:17:34AM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.02.2022 um 09:53 +0000 schrieb Charles Keepax:
On Tue, Feb 01, 2022 at 04:01:13PM +0100, Martin Kepplinger wrote:
Do you have a code example from a different codec that has roughly what is missing here? (the sound subsystem is new to me)
Full disclosure this is complete untested, but it should be pretty close. Let me know if it does the trick and I will send a proper patch to the list. I do have a Librem 5 in a draw somewhere so can pull that out if we get really stuck, but that might have to wait until the weekend :-).
I don't know if you guys are using the analogue bypass paths around the digital core on the chip. I think those will still work with the mics set to digital, so I have left the routes as is, but that might require some checking at some point.
ok that's great and seems to work! that's luxury.
Excellent glad that is working for you, I will prep up a proper patch and send it to the list. Should get that done tomorrow morning, if I don't manage it this afternoon.
Volume / sensitivity of Analog input is too low, I saw that before. What would you try to change that?
Hmm... you say you saw this before? I assume the input volume is always low, not just low sometimes? I would probably start by checking the voltage you have on the micbias, make sure that is as expected. Does the signal coming into the IN3R pin look low on a scope or is it just the level after it has been through the ADC on the chip that seems low?
Literally *no* effort went into this yet :) All I see is when I set the "headset mic" volume to max in gnome settings, the recorded volume is something like "almost usable", so that's off a bit.
I can't easily measure, but different headset mics produce similar volume.
The input routing on this chip is pretty byzantine, the output of just "amixer" showing all the controls in the relevant use-case would probably be helpful to look over. I suspect there is a reasonable chance something around the input PGA is not configured to match the hardware, although I am not the most familiar with this part so hard to guess at exactly what off the top of my head.
I append the output of `amixer contents` below.
Finally, do you know how much the amplitude is off by?
no
you can do all of our tasks if you want to :)
Ha! Not sure about that, but happy to help out where I can.
Thanks, Charles
:) thank you very much so far. You already really helped. We can even make the mic available now (to enable manually by the user) while we look into the volume and detection.
so long, all the best,
martin
On Thu, Feb 03, 2022 at 10:57:44AM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.02.2022 um 13:35 +0000 schrieb Charles Keepax:
On Wed, Feb 02, 2022 at 12:55:04PM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.02.2022 um 10:46 +0000 schrieb Charles Keepax:
On Wed, Feb 02, 2022 at 11:17:34AM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.02.2022 um 09:53 +0000 schrieb Charles Keepax:
On Tue, Feb 01, 2022 at 04:01:13PM +0100, Martin Kepplinger wrote:
Volume / sensitivity of Analog input is too low, I saw that before. What would you try to change that?
Hmm... you say you saw this before? I assume the input volume is always low, not just low sometimes? I would probably start by checking the voltage you have on the micbias, make sure that is as expected. Does the signal coming into the IN3R pin look low on a scope or is it just the level after it has been through the ADC on the chip that seems low?
Literally *no* effort went into this yet :) All I see is when I set the "headset mic" volume to max in gnome settings, the recorded volume is something like "almost usable", so that's off a bit.
I can't easily measure, but different headset mics produce similar volume.
No problem keep me posted any additional tests/info you guys get might help out here. Looking through your routing I think you are sending the mic directly to the speaker, I would definitely test capturing the signal over the I2S as well to confirm it is consistently a low volume on both paths.
:) thank you very much so far. You already really helped. We can even make the mic available now (to enable manually by the user) while we look into the volume and detection.
Happy to help, please feel free to keep the questions/debug info coming.
numid=11,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=2 : values=off,off
Ermm.... this should be muting the input PGA? I wouldn't expect any input from the analogue here.
numid=10,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=63,step=0 : values=29,29 | dBscale-min=-23.25dB,step=0.75dB,mute=0
This is the PGA volume on the inputs and appears to be set to -1.5dB. Not sure if that might be part of the problem?
numid=23,iface=MIXER,name='DAC Monomix Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=9,iface=MIXER,name='Digital Capture Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=127,step=0 : values=116,116 | dBscale-min=-72.00dB,step=0.75dB,mute=1
This looks set to +15dB at the moment, so presumably no problem here.
numid=84,iface=MIXER,name='INPGAR IN1R Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off
This is a total random hunch and might just be my unfamilarity with the chip. But I would definitely try a test with this switch turned on. From the input circuitry diagrams in the data sheet kinda looks like it will be needed to connect one side of the input PGA to the grounded output in your schematic.
numid=85,iface=MIXER,name='INPGAR IN2R Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=86,iface=MIXER,name='INPGAR IN3R Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=87,iface=MIXER,name='INPGAR IN4R Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=2,iface=MIXER,name='Input Mixer Switch' ; type=BOOLEAN,access=rw------,values=2 : values=off,on numid=94,iface=MIXER,name='Input Mode' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Analog' ; Item #1 'Digital' : values=1
Ah... I think you have the wrong path configured here. This appears to be coming from the digital mics. Just to confirm it is the analog mics you are having issues with?
numid=91,iface=MIXER,name='MIXINR IN2R Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=6,iface=MIXER,name='MIXINR IN2R Volume' ; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0 : values=7 | dBscale-min=-15.00dB,step=3.00dB,mute=0 numid=92,iface=MIXER,name='MIXINR IN3R Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=8,iface=MIXER,name='MIXINR IN3R Volume' ; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0 : values=0 | dBscale-min=-15.00dB,step=3.00dB,mute=0 numid=93,iface=MIXER,name='MIXINR PGA Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=7,iface=MIXER,name='MIXINR PGA Volume' ; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0 : values=7 | dBrange- rangemin=0,,rangemax=1 | dBscale-min=0.00dB,step=6.00dB,mute=0 rangemin=2,,rangemax=2 | dBscale-min=13.00dB,step=13.00dB,mute=0 rangemin=3,,rangemax=4 | dBscale-min=18.00dB,step=2.00dB,mute=0 rangemin=5,,rangemax=5 | dBscale-min=24.00dB,step=0.00dB,mute=0 rangemin=6,,rangemax=7 | dBscale-min=27.00dB,step=3.00dB,mute=0
Plenty of gain on the PGA.
numid=65,iface=MIXER,name='Speaker Switch' ; type=BOOLEAN,access=rw------,values=2 : values=on,off numid=64,iface=MIXER,name='Speaker Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=127,step=0 : values=121,121 | dBscale-min=-121.00dB,step=1.00dB,mute=1
Thanks, Charles
Am Donnerstag, dem 03.02.2022 um 11:05 +0000 schrieb Charles Keepax:
On Thu, Feb 03, 2022 at 10:57:44AM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.02.2022 um 13:35 +0000 schrieb Charles Keepax:
On Wed, Feb 02, 2022 at 12:55:04PM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.02.2022 um 10:46 +0000 schrieb Charles Keepax:
On Wed, Feb 02, 2022 at 11:17:34AM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.02.2022 um 09:53 +0000 schrieb Charles Keepax: > On Tue, Feb 01, 2022 at 04:01:13PM +0100, Martin > Kepplinger > wrote:
Volume / sensitivity of Analog input is too low, I saw that before. What would you try to change that?
Hmm... you say you saw this before? I assume the input volume is always low, not just low sometimes? I would probably start by checking the voltage you have on the micbias, make sure that is as expected. Does the signal coming into the IN3R pin look low on a scope or is it just the level after it has been through the ADC on the chip that seems low?
Literally *no* effort went into this yet :) All I see is when I set the "headset mic" volume to max in gnome settings, the recorded volume is something like "almost usable", so that's off a bit.
I can't easily measure, but different headset mics produce similar volume.
No problem keep me posted any additional tests/info you guys get might help out here. Looking through your routing I think you are sending the mic directly to the speaker, I would definitely test capturing the signal over the I2S as well to confirm it is consistently a low volume on both paths.
:) thank you very much so far. You already really helped. We can even make the mic available now (to enable manually by the user) while we look into the volume and detection.
Happy to help, please feel free to keep the questions/debug info coming.
yes my bad :) If I may, just let me describe my situation again and see whether anything else comes to your mind.
It's weird but I when I set "Capture Volume" to 60 instead of 29, I didn't hear a difference.
So far I don't hear a difference when setting "INPGAR IN1R Switch" on.
Does "Value" in this ucm description make any sense to you?
EnableSequence [ cset "name='Digital Capture Volume' 127,127" cset "name='Capture Volume' 63,63" cset "name='MIXINR IN3R Switch' on" cset "name='MIXINR IN3R Volume' 7" cset "name='INPGAR IN1R Switch' on" cset "name='Input Mode' Analog" ]
DisableSequence [ cset "name='INPGAR IN1R Switch' off" cset "name='MIXINR IN3R Switch' off" cset "name='MIXINR IN3R Volume' 0" cset "name='Input Mode' Digital" ]
Value { CapturePriority "100" CaptureChannels "2" CaptureSwitch "name='MIXINR IN3R Volume'" CaptureSwitch "name='MIXINR IN3R Switch'" CapturePCM "hw:${CardId},0" JackControl "Headphones Jack" }
Let me just append the correct amixer contents where I hear my usual "quiet and bad signal" recording:
Am Freitag, dem 04.02.2022 um 10:43 +0100 schrieb Martin Kepplinger:
Am Donnerstag, dem 03.02.2022 um 11:05 +0000 schrieb Charles Keepax:
On Thu, Feb 03, 2022 at 10:57:44AM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.02.2022 um 13:35 +0000 schrieb Charles Keepax:
On Wed, Feb 02, 2022 at 12:55:04PM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.02.2022 um 10:46 +0000 schrieb Charles Keepax:
On Wed, Feb 02, 2022 at 11:17:34AM +0100, Martin Kepplinger wrote: > Am Mittwoch, dem 02.02.2022 um 09:53 +0000 schrieb > Charles > Keepax: > > On Tue, Feb 01, 2022 at 04:01:13PM +0100, Martin > > Kepplinger > > wrote:
Volume / sensitivity of Analog input is too low, I saw that before. What would you try to change that?
Hmm... you say you saw this before? I assume the input volume is always low, not just low sometimes? I would probably start by checking the voltage you have on the micbias, make sure that is as expected. Does the signal coming into the IN3R pin look low on a scope or is it just the level after it has been through the ADC on the chip that seems low?
Literally *no* effort went into this yet :) All I see is when I set the "headset mic" volume to max in gnome settings, the recorded volume is something like "almost usable", so that's off a bit.
I can't easily measure, but different headset mics produce similar volume.
No problem keep me posted any additional tests/info you guys get might help out here. Looking through your routing I think you are sending the mic directly to the speaker, I would definitely test capturing the signal over the I2S as well to confirm it is consistently a low volume on both paths.
:) thank you very much so far. You already really helped. We can even make the mic available now (to enable manually by the user) while we look into the volume and detection.
Happy to help, please feel free to keep the questions/debug info coming.
yes my bad :) If I may, just let me describe my situation again and see whether anything else comes to your mind.
It's weird but I when I set "Capture Volume" to 60 instead of 29, I didn't hear a difference.
So far I don't hear a difference when setting "INPGAR IN1R Switch" on.
Does "Value" in this ucm description make any sense to you?
EnableSequence [ cset "name='Digital Capture Volume' 127,127" cset "name='Capture Volume' 63,63" cset "name='MIXINR IN3R Switch' on" cset "name='MIXINR IN3R Volume' 7" cset "name='INPGAR IN1R Switch' on" cset "name='Input Mode' Analog" ] DisableSequence [ cset "name='INPGAR IN1R Switch' off" cset "name='MIXINR IN3R Switch' off" cset "name='MIXINR IN3R Volume' 0" cset "name='Input Mode' Digital" ] Value { CapturePriority "100" CaptureChannels "2" CaptureSwitch "name='MIXINR IN3R Volume'"
sorry, of course this is a typo I've fixed: CaptureVolume
CaptureSwitch "name='MIXINR IN3R Switch'" CapturePCM "hw:${CardId},0" JackControl "Headphones Jack"
I know this is a workaround until I have mic detection.
}
Let me just append the correct amixer contents where I hear my usual "quiet and bad signal" recording:
On Fri, Feb 04, 2022 at 10:43:53AM +0100, Martin Kepplinger wrote:
yes my bad :) If I may, just let me describe my situation again and see whether anything else comes to your mind.
It's weird but I when I set "Capture Volume" to 60 instead of 29, I didn't hear a difference.
So far I don't hear a difference when setting "INPGAR IN1R Switch" on.
Does "Value" in this ucm description make any sense to you?
Mostly a couple comments inline.
EnableSequence [ cset "name='Digital Capture Volume' 127,127" cset "name='Capture Volume' 63,63" cset "name='MIXINR IN3R Switch' on" cset "name='MIXINR IN3R Volume' 7" cset "name='INPGAR IN1R Switch' on" cset "name='Input Mode' Analog"
Little hard to say without the rest of the ucm file (happy to have a look at that if you had a handy link?), but this looks a bit weird. Why are you connecting the MIXINR IN3R stuff here, you want to go through the PGA most likely?
]DisableSequence [ cset "name='INPGAR IN1R Switch' off" cset "name='MIXINR IN3R Switch' off" cset "name='MIXINR IN3R Volume' 0" cset "name='Input Mode' Digital" ]
Value { CapturePriority "100" CaptureChannels "2" CaptureSwitch "name='MIXINR IN3R Volume'"
This should probably be CaptureVolume, rather than CaptureSwitch.
CaptureSwitch "name='MIXINR IN3R Switch'" CapturePCM "hw:${CardId},0" JackControl "Headphones Jack"
Assuming your machine driver creates an appropriately named control.
}Let me just append the correct amixer contents where I hear my usual "quiet and bad signal" recording:
numid=11,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=2 : values=off,off
This still looks weird, I wouldn't expect you would hear anything with the "Capture Switch" off, it mutes the PGA. Can you confirm if this is on whilst you are actually capturing audio?
numid=84,iface=MIXER,name='INPGAR IN1R Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on
I definitely would consider turning this on as just a test thing not a recommendation on how the part should be used, until we see if it helps. It was just a weird hunch, I feel the routing is probably more sensible without it.
numid=92,iface=MIXER,name='MIXINR IN3R Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=93,iface=MIXER,name='MIXINR PGA Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on
I don't think you should have both the IN3R and PGA switches enabled at once. I would suggest only using the PGA switch.
Ok, I think what is happening here is you have both of these connected, and because you have the PGA muted, you are only hearing the unboosted mic signal coming through MIXINR IN3R. This would explain both why the Capture Volume has no effect and why your signal is quiet.
Thanks, Charles
Am Freitag, dem 04.02.2022 um 17:21 +0000 schrieb Charles Keepax:
On Fri, Feb 04, 2022 at 10:43:53AM +0100, Martin Kepplinger wrote:
yes my bad :) If I may, just let me describe my situation again and see whether anything else comes to your mind.
It's weird but I when I set "Capture Volume" to 60 instead of 29, I didn't hear a difference.
So far I don't hear a difference when setting "INPGAR IN1R Switch" on.
Does "Value" in this ucm description make any sense to you?
Mostly a couple comments inline.
EnableSequence [ cset "name='Digital Capture Volume' 127,127" cset "name='Capture Volume' 63,63" cset "name='MIXINR IN3R Switch' on" cset "name='MIXINR IN3R Volume' 7" cset "name='INPGAR IN1R Switch' on" cset "name='Input Mode' Analog"
Little hard to say without the rest of the ucm file (happy to have a look at that if you had a handy link?), but this looks a bit weird. Why are you connecting the MIXINR IN3R stuff here, you want to go through the PGA most likely?
sure, this is the changing (force-pushing) file I'm working on: https://source.puri.sm/martin.kepplinger/librem5-base/-/blob/headset/default...
] DisableSequence [ cset "name='INPGAR IN1R Switch' off" cset "name='MIXINR IN3R Switch' off" cset "name='MIXINR IN3R Volume' 0" cset "name='Input Mode' Digital" ] Value { CapturePriority "100" CaptureChannels "2" CaptureSwitch "name='MIXINR IN3R Volume'"
This should probably be CaptureVolume, rather than CaptureSwitch.
CaptureSwitch "name='MIXINR IN3R Switch'" CapturePCM "hw:${CardId},0" JackControl "Headphones Jack"
Assuming your machine driver creates an appropriately named control.
}
Let me just append the correct amixer contents where I hear my usual "quiet and bad signal" recording:
numid=11,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=2 : values=off,off
This still looks weird, I wouldn't expect you would hear anything with the "Capture Switch" off, it mutes the PGA. Can you confirm if this is on whilst you are actually capturing audio?
you're right. I append my current setting, now while gnome audio settings are open (where the signal volume is shown), then it's on.
numid=84,iface=MIXER,name='INPGAR IN1R Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on
I definitely would consider turning this on as just a test thing not a recommendation on how the part should be used, until we see if it helps. It was just a weird hunch, I feel the routing is probably more sensible without it.
removed that.
numid=92,iface=MIXER,name='MIXINR IN3R Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=93,iface=MIXER,name='MIXINR PGA Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on
I don't think you should have both the IN3R and PGA switches enabled at once. I would suggest only using the PGA switch.
Ok, I think what is happening here is you have both of these connected, and because you have the PGA muted, you are only hearing the unboosted mic signal coming through MIXINR IN3R. This would explain both why the Capture Volume has no effect and why your signal is quiet.
ok. I keep MIXINR IN3R Switch disabled now and the volume is indeed high now, and I control volume using
CaptureSwitch "name='Capture Volume'"
Volume itself indeed is good now. Recorded voice is very "metallic" and "shallow" if you know what I mean - and distorted when using MAX volume. The gnome audio recorder doesn't show *any* signal in the UI, so that must still be kind of bad - even though I understand recorded voice way better now than before.
Thanks, Charles
thanks for all the time and help, and sorry for all the wrong amixer output I sent you,
martin
On Mon, Feb 07, 2022 at 11:49:32AM +0100, Martin Kepplinger wrote:
Am Freitag, dem 04.02.2022 um 17:21 +0000 schrieb Charles Keepax:
On Fri, Feb 04, 2022 at 10:43:53AM +0100, Martin Kepplinger wrote:
numid=92,iface=MIXER,name='MIXINR IN3R Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=93,iface=MIXER,name='MIXINR PGA Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on
I don't think you should have both the IN3R and PGA switches enabled at once. I would suggest only using the PGA switch.
Ok, I think what is happening here is you have both of these connected, and because you have the PGA muted, you are only hearing the unboosted mic signal coming through MIXINR IN3R. This would explain both why the Capture Volume has no effect and why your signal is quiet.
ok. I keep MIXINR IN3R Switch disabled now and the volume is indeed high now, and I control volume using
CaptureSwitch "name='Capture Volume'"
Volume itself indeed is good now. Recorded voice is very "metallic" and "shallow" if you know what I mean - and distorted when using MAX volume. The gnome audio recorder doesn't show *any* signal in the UI, so that must still be kind of bad - even though I understand recorded voice way better now than before.
My first thought is that the signal is clipping somewhere in the chain. You have a lot of the gaines up very high from when you were trying to working around the low signal level issues.
Can we be clear here on what paths are in play here. Presumably the gnome audio recorder is capturing over the I2S. When you say you can understand the recorded voice way better now, do you mean in the file captured by the gnome audio recorder? Or are you listening to that on another path, like direct to the headphones?
thanks for all the time and help, and sorry for all the wrong amixer output I sent you,
No problem, always a bit of back and forth in these debugging exercises.
numid=10,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=63,step=0 : values=63,63 | dBscale-min=-23.25dB,step=0.75dB,mute=0
This is +24dB, I would start with something like +0dB, +3dB or +6dB.
numid=7,iface=MIXER,name='MIXINR PGA Volume' ; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0 : values=7 | dBrange- rangemin=0,,rangemax=1 | dBscale-min=0.00dB,step=6.00dB,mute=0 rangemin=2,,rangemax=2 | dBscale-min=13.00dB,step=13.00dB,mute=0 rangemin=3,,rangemax=4 | dBscale-min=18.00dB,step=2.00dB,mute=0 rangemin=5,,rangemax=5 | dBscale-min=24.00dB,step=0.00dB,mute=0 rangemin=6,,rangemax=7 | dBscale-min=27.00dB,step=3.00dB,mute=0
Hmm... step size here seems to disagree with the datasheet but this is either +29dB or +30dB depending on who we trust.
So combining those two you have like +54dB of analogue gain, like no way that isn't causing the signal to clip.
I would start with 0dB on each, then bump them up to like +6dB if the signal is really quiet. But somewhere you should be able to get specs on the mic and work out what actual gain you need to get a full scale signal out of the mic for the given micbias voltage. Your hardware folks should be able to help out there.
Thanks, Charles
On Mon, Feb 07, 2022 at 02:21:29PM +0000, Charles Keepax wrote:
On Mon, Feb 07, 2022 at 11:49:32AM +0100, Martin Kepplinger wrote:
Am Freitag, dem 04.02.2022 um 17:21 +0000 schrieb Charles Keepax:
On Fri, Feb 04, 2022 at 10:43:53AM +0100, Martin Kepplinger wrote:
Volume itself indeed is good now. Recorded voice is very "metallic" and "shallow" if you know what I mean - and distorted when using MAX volume. The gnome audio recorder doesn't show *any* signal in the UI, so that must still be kind of bad - even though I understand recorded voice way better now than before.
My first thought is that the signal is clipping somewhere in the chain. You have a lot of the gaines up very high from when you were trying to working around the low signal level issues.
Can we be clear here on what paths are in play here. Presumably the gnome audio recorder is capturing over the I2S. When you say you can understand the recorded voice way better now, do you mean in the file captured by the gnome audio recorder? Or are you listening to that on another path, like direct to the headphones?
thanks for all the time and help, and sorry for all the wrong amixer output I sent you,
Hey, just wanted to check everything was going ok on this stuff? Did the volume tweaks get things sounding more normal, and any other problems you guys are having?
Thanks, charles
Am Dienstag, dem 01.03.2022 um 13:44 +0000 schrieb Charles Keepax:
On Mon, Feb 07, 2022 at 02:21:29PM +0000, Charles Keepax wrote:
On Mon, Feb 07, 2022 at 11:49:32AM +0100, Martin Kepplinger wrote:
Am Freitag, dem 04.02.2022 um 17:21 +0000 schrieb Charles Keepax:
On Fri, Feb 04, 2022 at 10:43:53AM +0100, Martin Kepplinger wrote:
Volume itself indeed is good now. Recorded voice is very "metallic" and "shallow" if you know what I mean - and distorted when using MAX volume. The gnome audio recorder doesn't show *any* signal in the UI, so that must still be kind of bad - even though I understand recorded voice way better now than before.
My first thought is that the signal is clipping somewhere in the chain. You have a lot of the gaines up very high from when you were trying to working around the low signal level issues.
Can we be clear here on what paths are in play here. Presumably the gnome audio recorder is capturing over the I2S. When you say you can understand the recorded voice way better now, do you mean in the file captured by the gnome audio recorder? Or are you listening to that on another path, like direct to the headphones?
thanks for all the time and help, and sorry for all the wrong amixer output I sent you,
Hey, just wanted to check everything was going ok on this stuff? Did the volume tweaks get things sounding more normal, and any other problems you guys are having?
Thanks, charles
Hi Charles!
that's really nice of you to ask. Sorry for not replying earlier. Mainly cset "name='MIXINR PGA Volume' 0,0" made things much better indeed. I took a break from this then and the issue is still open, here: https://source.puri.sm/Librem5/librem5-base/-/merge_requests/296 or if you want to look at the current ucm file: https://source.puri.sm/Librem5/librem5-base/-/blob/bb48912242dd0db1f35c6de84...
As you know I'm no expert with the codec and this definitely can be improved: When visualizing the signal, it doesn't look "good" yet and the signal strength seems to only go to 50% of the available scale (in the gnome volume setting). Actually I'll talk about this to Guido tomorrow and even though it is kind of usable now, I hope to that we can come up with a profile that we're preliminarliy happy with.
Of course we already use your "Input Mode" control.
thanks,
martin
Am Dienstag, dem 01.03.2022 um 15:00 +0100 schrieb Martin Kepplinger:
Am Dienstag, dem 01.03.2022 um 13:44 +0000 schrieb Charles Keepax:
On Mon, Feb 07, 2022 at 02:21:29PM +0000, Charles Keepax wrote:
On Mon, Feb 07, 2022 at 11:49:32AM +0100, Martin Kepplinger wrote:
Am Freitag, dem 04.02.2022 um 17:21 +0000 schrieb Charles Keepax:
On Fri, Feb 04, 2022 at 10:43:53AM +0100, Martin Kepplinger wrote:
Volume itself indeed is good now. Recorded voice is very "metallic" and "shallow" if you know what I mean - and distorted when using MAX volume. The gnome audio recorder doesn't show *any* signal in the UI, so that must still be kind of bad - even though I understand recorded voice way better now than before.
My first thought is that the signal is clipping somewhere in the chain. You have a lot of the gaines up very high from when you were trying to working around the low signal level issues.
Can we be clear here on what paths are in play here. Presumably the gnome audio recorder is capturing over the I2S. When you say you can understand the recorded voice way better now, do you mean in the file captured by the gnome audio recorder? Or are you listening to that on another path, like direct to the headphones?
thanks for all the time and help, and sorry for all the wrong amixer output I sent you,
Hey, just wanted to check everything was going ok on this stuff? Did the volume tweaks get things sounding more normal, and any other problems you guys are having?
Thanks, charles
Hi Charles!
that's really nice of you to ask. Sorry for not replying earlier. Mainly cset "name='MIXINR PGA Volume' 0,0" made things much better indeed. I took a break from this then and the issue is still open, here: https://source.puri.sm/Librem5/librem5-base/-/merge_requests/296 or if you want to look at the current ucm file: https://source.puri.sm/Librem5/librem5-base/-/blob/bb48912242dd0db1f35c6de84...
As you know I'm no expert with the codec and this definitely can be improved: When visualizing the signal, it doesn't look "good" yet and the signal strength seems to only go to 50% of the available scale (in the gnome volume setting). Actually I'll talk about this to Guido tomorrow and even though it is kind of usable now, I hope to that we can come up with a profile that we're preliminarliy happy with.
Of course we already use your "Input Mode" control.
thanks,
martin
Hi Charles,
Let me forward the commit message I just did for the ucm settings here, now that I have a *bit* of an overview of the codec:
There are 3 Volume controls for the analog parts, all before the ADC. In order from Jack to ADC, they are:
numid=10,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=63,step=0 : values=63,63 | dBscale-min=-23.25dB,step=0.75dB,mute=0
"Input PGA Volume Control". 31=0dB. We use 39=+6dB.
numid=7,iface=MIXER,name='MIXINR PGA Volume' ; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0 : values=7 | dBrange- rangemin=0,,rangemax=1 | dBscale-min=0.00dB,step=6.00dB,mute=0 rangemin=2,,rangemax=2 | dBscale-min=13.00dB,step=13.00dB,mute=0 rangemin=3,,rangemax=4 | dBscale-min=18.00dB,step=2.00dB,mute=0 rangemin=5,,rangemax=5 | dBscale-min=24.00dB,step=0.00dB,mute=0 rangemin=6,,rangemax=7 | dBscale-min=27.00dB,step=3.00dB,mute=0
"Right input PGA to Right input Boost-Mixer Gain" 0=0dB. we use 1=+3dB.
numid=8,iface=MIXER,name='MIXINR IN3R Volume' ; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0 : values=6 | dBscale-min=-15.00dB,step=3.00dB,mute=0
5=0dB. we use 6=+3dB. That's a later amplifier, "Boost-Mixer Gain".
("quotes" are from the datasheet)
Still, the recording sounds pretty good I think, but since gnome sound- recording doesn't visualize the signal waves - whatever that means :) I'll look at the file in audacity or something similar later.
thanks for having a look,
martin
On Wed, Mar 02, 2022 at 12:48:28PM +0100, Martin Kepplinger wrote:
Am Dienstag, dem 01.03.2022 um 15:00 +0100 schrieb Martin Kepplinger:
Am Dienstag, dem 01.03.2022 um 13:44 +0000 schrieb Charles Keepax:
On Mon, Feb 07, 2022 at 02:21:29PM +0000, Charles Keepax wrote:
On Mon, Feb 07, 2022 at 11:49:32AM +0100, Martin Kepplinger
Am Freitag, dem 04.02.2022 um 17:21 +0000 schrieb Charles
On Fri, Feb 04, 2022 at 10:43:53AM +0100, Martin Kepplinger
that's really nice of you to ask. Sorry for not replying earlier. Mainly cset "name='MIXINR PGA Volume' 0,0" made things much better indeed. I took a break from this then and the issue is still open, here: https://source.puri.sm/Librem5/librem5-base/-/merge_requests/296 or if you want to look at the current ucm file: https://source.puri.sm/Librem5/librem5-base/-/blob/bb48912242dd0db1f35c6de84...
As you know I'm no expert with the codec and this definitely can be improved: When visualizing the signal, it doesn't look "good" yet and the signal strength seems to only go to 50% of the available scale (in the gnome volume setting). Actually I'll talk about this to Guido tomorrow and even though it is kind of usable now, I hope to that we can come up with a profile that we're preliminarliy happy with.
Let me forward the commit message I just did for the ucm settings here, now that I have a *bit* of an overview of the codec:
There are 3 Volume controls for the analog parts, all before the ADC. In order from Jack to ADC, they are:
numid=10,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=63,step=0 : values=63,63 | dBscale-min=-23.25dB,step=0.75dB,mute=0
"Input PGA Volume Control". 31=0dB. We use 39=+6dB.
numid=7,iface=MIXER,name='MIXINR PGA Volume' ; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0 : values=7 | dBrange- rangemin=0,,rangemax=1 | dBscale-min=0.00dB,step=6.00dB,mute=0 rangemin=2,,rangemax=2 | dBscale-min=13.00dB,step=13.00dB,mute=0 rangemin=3,,rangemax=4 | dBscale-min=18.00dB,step=2.00dB,mute=0 rangemin=5,,rangemax=5 | dBscale-min=24.00dB,step=0.00dB,mute=0 rangemin=6,,rangemax=7 | dBscale-min=27.00dB,step=3.00dB,mute=0
"Right input PGA to Right input Boost-Mixer Gain" 0=0dB. we use 1=+3dB.
numid=8,iface=MIXER,name='MIXINR IN3R Volume' ; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0 : values=6 | dBscale-min=-15.00dB,step=3.00dB,mute=0
5=0dB. we use 6=+3dB. That's a later amplifier, "Boost-Mixer Gain".
("quotes" are from the datasheet)
Still, the recording sounds pretty good I think, but since gnome sound- recording doesn't visualize the signal waves - whatever that means :) I'll look at the file in audacity or something similar later.
Yeah I have been having a look at your patch you linked. I think there are still maybe a couple things I am not sure on. I would try removing these two lines:
cset "name='MIXINR IN3R Switch' on" cset "name='MIXINR IN3R Volume' 6"
I am pretty sure we want to be using the PGA path here. If you check Figure 13 in the datasheet, you can route IN3R to MIXINR either through the IN3R input or through the PGA input. I suspect we want to come through the PGA. Using the IN3R path should mean the PGA volume has no effect, it is effectively bypassing the PGA. You may need to also add:
cset "name='MIXINR PGA Switch' on"
Although your previous control dumps had that input set on. I suspect if you have both enabled you will get some slightly weird effects, there is probably a slightly phase delay through the PGA and there won't be on the direct path, so when they mix together it will likely sound weird.
Hopefully that gets us to a clean signal. The settings described in your commit message give +9dB analogue gain which seems reasonable to me, and from the patch itself looks like you have +15dB digital gain, which feels a little high but not total unreasonable.
Thanks, Charles
Am Mittwoch, dem 02.03.2022 um 13:40 +0000 schrieb Charles Keepax:
On Wed, Mar 02, 2022 at 12:48:28PM +0100, Martin Kepplinger wrote:
Am Dienstag, dem 01.03.2022 um 15:00 +0100 schrieb Martin Kepplinger:
Am Dienstag, dem 01.03.2022 um 13:44 +0000 schrieb Charles Keepax:
On Mon, Feb 07, 2022 at 02:21:29PM +0000, Charles Keepax wrote:
On Mon, Feb 07, 2022 at 11:49:32AM +0100, Martin Kepplinger
Am Freitag, dem 04.02.2022 um 17:21 +0000 schrieb Charles > On Fri, Feb 04, 2022 at 10:43:53AM +0100, Martin > Kepplinger
that's really nice of you to ask. Sorry for not replying earlier. Mainly cset "name='MIXINR PGA Volume' 0,0" made things much better indeed. I took a break from this then and the issue is still open, here: https://source.puri.sm/Librem5/librem5-base/-/merge_requests/296 or if you want to look at the current ucm file: https://source.puri.sm/Librem5/librem5-base/-/blob/bb48912242dd0db1f35c6de84...
As you know I'm no expert with the codec and this definitely can be improved: When visualizing the signal, it doesn't look "good" yet and the signal strength seems to only go to 50% of the available scale (in the gnome volume setting). Actually I'll talk about this to Guido tomorrow and even though it is kind of usable now, I hope to that we can come up with a profile that we're preliminarliy happy with.
Let me forward the commit message I just did for the ucm settings here, now that I have a *bit* of an overview of the codec:
There are 3 Volume controls for the analog parts, all before the ADC. In order from Jack to ADC, they are:
numid=10,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=63,step=0 : values=63,63 | dBscale-min=-23.25dB,step=0.75dB,mute=0
"Input PGA Volume Control". 31=0dB. We use 39=+6dB.
numid=7,iface=MIXER,name='MIXINR PGA Volume' ; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0 : values=7 | dBrange- rangemin=0,,rangemax=1 | dBscale-min=0.00dB,step=6.00dB,mute=0 rangemin=2,,rangemax=2 | dBscale-min=13.00dB,step=13.00dB,mute=0 rangemin=3,,rangemax=4 | dBscale-min=18.00dB,step=2.00dB,mute=0 rangemin=5,,rangemax=5 | dBscale-min=24.00dB,step=0.00dB,mute=0 rangemin=6,,rangemax=7 | dBscale-min=27.00dB,step=3.00dB,mute=0
"Right input PGA to Right input Boost-Mixer Gain" 0=0dB. we use 1=+3dB.
numid=8,iface=MIXER,name='MIXINR IN3R Volume' ; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0 : values=6 | dBscale-min=-15.00dB,step=3.00dB,mute=0
5=0dB. we use 6=+3dB. That's a later amplifier, "Boost-Mixer Gain".
("quotes" are from the datasheet)
Still, the recording sounds pretty good I think, but since gnome sound- recording doesn't visualize the signal waves - whatever that means :) I'll look at the file in audacity or something similar later.
Yeah I have been having a look at your patch you linked. I think there are still maybe a couple things I am not sure on. I would try removing these two lines:
cset "name='MIXINR IN3R Switch' on" cset "name='MIXINR IN3R Volume' 6"
I am pretty sure we want to be using the PGA path here. If you check Figure 13 in the datasheet, you can route IN3R to MIXINR either through the IN3R input or through the PGA input. I suspect we want to come through the PGA. Using the IN3R path should mean the PGA volume has no effect, it is effectively bypassing the PGA. You may need to also add:
cset "name='MIXINR PGA Switch' on"
ah ok, I think I read Figure 13 wrong then. thanks!
Although your previous control dumps had that input set on. I suspect if you have both enabled you will get some slightly weird effects, there is probably a slightly phase delay through the PGA and there won't be on the direct path, so when they mix together it will likely sound weird.
it was not that bad but with your changes, especially a recorded "s" sounds indeed better now.
Hopefully that gets us to a clean signal. The settings described in your commit message give +9dB analogue gain which seems reasonable to me, and from the patch itself looks like you have +15dB digital gain, which feels a little high but not total unreasonable.
I left MIXINR PGA Volume at 1 and Capture Volume ("Input PGA Volume Control") at 39 for now since I think it shouldn't be quieter than that at least.
Thanks, Charles
On Wed, Mar 02, 2022 at 03:11:00PM +0100, Martin Kepplinger wrote:
Am Mittwoch, dem 02.03.2022 um 13:40 +0000 schrieb Charles Keepax:
On Wed, Mar 02, 2022 at 12:48:28PM +0100, Martin Kepplinger wrote:
Am Dienstag, dem 01.03.2022 um 15:00 +0100 schrieb Martin
Am Dienstag, dem 01.03.2022 um 13:44 +0000 schrieb Charles
On Mon, Feb 07, 2022 at 02:21:29PM +0000, Charles Keepax wrote:
On Mon, Feb 07, 2022 at 11:49:32AM +0100, Martin Kepplinger > Am Freitag, dem 04.02.2022 um 17:21 +0000 schrieb Charles > > On Fri, Feb 04, 2022 at 10:43:53AM +0100, Martin
Although your previous control dumps had that input set on. I suspect if you have both enabled you will get some slightly weird effects, there is probably a slightly phase delay through the PGA and there won't be on the direct path, so when they mix together it will likely sound weird.
it was not that bad but with your changes, especially a recorded "s" sounds indeed better now.
Awesome hopefully that should be us getting pretty close.
Hopefully that gets us to a clean signal. The settings described in your commit message give +9dB analogue gain which seems reasonable to me, and from the patch itself looks like you have +15dB digital gain, which feels a little high but not total unreasonable.
I left MIXINR PGA Volume at 1 and Capture Volume ("Input PGA Volume Control") at 39 for now since I think it shouldn't be quieter than that at least.
I think we probably bump the PGA gain up another 3dB, maybe even 6dB if you really need to, I would just be careful to test some very loud sound levels to make sure your not starting to clip the signal.
Thanks, Charles
participants (2)
-
Charles Keepax -
Martin Kepplinger