3.19 on Nokia n900: audio quality awful

Hi!

In 3.18, sound is nice and clear.

In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound.

Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise.

Any idea what could have caused it?

Quoted 12 lines · Pavel Machek

Hi!

In 3.18, sound is nice and clear.

In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound.

Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise.

Quoted 1 line

Any idea what could have caused it?

$ git bisect start
$ git bisect good v3.18
$ git bisect bad

that'll help find what caused it.

Quoted 15 lines · Felipe Balbi

Quoted 13 lines · Pavel Machek

Hi!

In 3.18, sound is nice and clear.

In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound.

Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise.

Any idea what could have caused it?

Quoted 5 lines

$ git bisect start
$ git bisect good v3.18
$ git bisect bad

that'll help find what caused it.

Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny.

Quoted 21 lines · Pavel Machek

Quoted 19 lines · Felipe Balbi

Quoted 7 lines · Pavel Machek

Hi!

In 3.18, sound is nice and clear.

In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound.

Quoted 6 lines

Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise.

Any idea what could have caused it?

$ git bisect start
$ git bisect good v3.18
$ git bisect bad

Quoted 4 lines

Quoted 1 line

that'll help find what caused it.

Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny.

you're getting code for free, you're getting help for free. Not many people have N900s lying around. Running a bisection is just politeness.

Quoted 24 lines · Felipe Balbi

Quoted 23 lines · Pavel Machek

Quoted 20 lines · Felipe Balbi

Quoted 7 lines · Pavel Machek

Hi!

In 3.18, sound is nice and clear.

In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound.

Quoted 6 lines

Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise.

Any idea what could have caused it?

$ git bisect start
$ git bisect good v3.18
$ git bisect bad

that'll help find what caused it.

Quoted 6 lines

Quoted 2 lines

Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny.

you're getting code for free, you're getting help for free. Not many people have N900s lying around. Running a bisection is just politeness.

Now you are speaking for yourself or for TI?

Thanks for your very valuable help. I know how to do a bisection, thank you.

PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time.

Hi,

Quoted 28 lines · Pavel Machek

Quoted 27 lines · Felipe Balbi

Quoted 25 lines · Pavel Machek

Quoted 13 lines · Felipe Balbi

Quoted 12 lines · Pavel Machek

Hi!

In 3.18, sound is nice and clear.

In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound.

Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise.

Quoted 7 lines

Quoted 1 line

Any idea what could have caused it?

$ git bisect start
$ git bisect good v3.18
$ git bisect bad

that'll help find what caused it.

Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny.

Quoted 5 lines

Quoted 3 lines

you're getting code for free, you're getting help for free. Not many people have N900s lying around. Running a bisection is just politeness.

Now you are speaking for yourself or for TI?

why bring my employer into the discussion ?

Quoted 2 lines

Thanks for your very valuable help. I know how to do a bisection, thank you.

then please do it.

Quoted 25 lines

Quoted 25 lines

Quoted 24 lines

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

In 3.18, sound is nice and clear.

In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound.

Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise.

Any idea what could have caused it?

Quoted 8 lines

Quoted 5 lines

$ git bisect start
$ git bisect good v3.18
$ git bisect bad

that'll help find what caused it.

Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny.

you're getting code for free, you're getting help for free. Not many people have N900s lying around. Running a bisection is just politeness.

Quoted 3 lines

Quoted 1 line

Now you are speaking for yourself or for TI?

why bring my employer into the discussion ?

Because you are speaking of getting help for free, and I don't

remember getting any useful help from you; so I'd like to know who do

you speak for.

Quoted 4 lines

Quoted 2 lines

Thanks for your very valuable help. I know how to do a bisection, thank you.

then please do it.

No, sorry, I don't think that would be reasonable use of my time at this point. First steps are "confirm it happens on other N900 boards, too", ruling out config issues at my part, and "try to get verification from other development boards if they have same problems", because most other boards are easier to work with.

PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time.

Hi,

Quoted 2 lines · Pavel Machek

PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time.

USB networking works fine with 3.19-rc3 and also MMC card rootfs.

Quoted 6 lines · Aaro Koskinen

Hi,

Quoted 2 lines · Pavel Machek

PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time.

Quoted 1 line

USB networking works fine with 3.19-rc3 and also MMC card rootfs.

Does nfsroot work for you? USB networking works as a module but not build-in. [Patch is available for this one.]

u-SD card seems to have similar problem. If I try it after boot, I can access it ok, but using u-SD card for rootfs fails. If it works for you, it would be interesting to know.

I'm loading zImage using 0xffff directly from the PC.

But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options?

Hi,

Quoted 3 lines · Aaro Koskinen

But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options?

yeah, rootwait should do it.

Hi,

Quoted 3 lines · Aaro Koskinen

But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options?

yeah, rootwait should do it.

Quoted 5 lines

Quoted 3 lines

But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options?

yeah, rootwait should do it.

No, rootwait does not solve it. Try it. Tested many times. (And yes, you need to actually fool the rear cover sensor or close the phone.)

Hi,

Quoted 4 lines · Pavel Machek

Quoted 4 lines

Quoted 3 lines

But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options?

Quoted 4 lines

Quoted 1 line

yeah, rootwait should do it.

No, rootwait does not solve it. Try it. Tested many times. (And yes, you need to actually fool the rear cover sensor or close the phone.)

yeah, just put a magnet or, if you have spare back covers, cut one so that you "close" it, but still allow you to put the thing on a development jig.

Also, if why doesn't rootwait work ? You never have a new mmc node or is the mmc node changing names ?

Quoted 12 lines · Felipe Balbi

Hi,

Quoted 8 lines · Pavel Machek

Quoted 5 lines

Quoted 3 lines

But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options?

yeah, rootwait should do it.

No, rootwait does not solve it. Try it. Tested many times. (And yes, you need to actually fool the rear cover sensor or close the phone.)

Quoted 3 lines

yeah, just put a magnet or, if you have spare back covers, cut one so that you "close" it, but still allow you to put the thing on a development jig.

Actually, it should be enough to kill a line from dts somewhere, no need to hack hardware for this.

Quoted 2 lines

Also, if why doesn't rootwait work ? You never have a new mmc node or is the mmc node changing names ?

IIRC node and name are ok, but the mount just fails. As I don't have

"development jig", I lack serial console and this kind of debugging is not easy.

Quoted 7 lines · Pavel Machek

Quoted 6 lines · Aaro Koskinen

Hi,

Quoted 2 lines · Pavel Machek

PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time.

Quoted 8 lines

Quoted 1 line

USB networking works fine with 3.19-rc3 and also MMC card rootfs.

Does nfsroot work for you? USB networking works as a module but not build-in. [Patch is available for this one.]

u-SD card seems to have similar problem. If I try it after boot, I can access it ok, but using u-SD card for rootfs fails. If it works for you, it would be interesting to know.

I haven't tried nfsroot, but I've been using USB networking for ssh for a couple of years without issues. I have g_ether as module.

Also I recently switched rootfs to u-SD card, and it (MMC) works fine as builtin.

But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options?

Quoted 23 lines · Aaro Koskinen

Quoted 7 lines · Pavel Machek

Quoted 6 lines · Aaro Koskinen

Hi,

Quoted 2 lines · Pavel Machek

PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time.

Quoted 8 lines

Quoted 1 line

USB networking works fine with 3.19-rc3 and also MMC card rootfs.

Does nfsroot work for you? USB networking works as a module but not build-in. [Patch is available for this one.]

u-SD card seems to have similar problem. If I try it after boot, I can access it ok, but using u-SD card for rootfs fails. If it works for you, it would be interesting to know.

I haven't tried nfsroot, but I've been using USB networking for ssh for a couple of years without issues. I have g_ether as module.

Also I recently switched rootfs to u-SD card, and it (MMC) works fine as builtin.

Quoted 3 lines

But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options?

Yes, it works if I mount it later. It fails when done directly using root=, even with rootwait etc. Hard to believe, yes, but try it. You can watch the results on console.

Quoted 13 lines · Felipe Balbi

Quoted 11 lines · Pavel Machek

In 3.18, sound is nice and clear.

In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound.

Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise.

Any idea what could have caused it?

Quoted 5 lines

$ git bisect start
$ git bisect good v3.18
$ git bisect bad

that'll help find what caused it.

Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny.

In 3.18, sound is nice and clear.

In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound.

Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise.

Any idea what could have caused it?

Hi!

If you have any idea about playback problems, help would be still welcome. I'll have to do bisect, otherwise, and it will not be easy.

Quoted 11 lines

In 3.18, sound is nice and clear.

In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound.

Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise.

Any idea what could have caused it?

I tried audio recording this time.

In 2.6.28-nokia, it is neccessary to set "Input select" na "digital mic", then it works. Input select being in "playback" option makes it easy to miss.

In 3.18 and 3.19-rc3, all I can record are zeros.

Does playback/recording work for you on OMAP 3430-based machines?

Quoted 7 lines · Pavel Machek

In 2.6.28-nokia, it is neccessary to set "Input select" na "digital mic", then it works. Input select being in "playback" option makes it easy to miss.

In 3.18 and 3.19-rc3, all I can record are zeros.

Does playback/recording work for you on OMAP 3430-based machines?

Same codec (tlv320aic3106) works fine on my am335x and omap-l138 boards. BeagleBoard-xM also fine with twl4030 codec.

I don't have my n900 in hacking mode (it is still in use time-to-time) but looking at the dts file: you might want to add ai3x-micbias-vg property to the aic3x nodes to select the correct mic bias voltage. I can't recall what is appropriate for n900, but 2.6.28-nokia sources might give you the answer.

Quoted 12 lines · Peter Ujfalusi

Quoted 7 lines · Pavel Machek

In 2.6.28-nokia, it is neccessary to set "Input select" na "digital mic", then it works. Input select being in "playback" option makes it easy to miss.

In 3.18 and 3.19-rc3, all I can record are zeros.

Does playback/recording work for you on OMAP 3430-based machines?

Same codec (tlv320aic3106) works fine on my am335x and omap-l138 boards. BeagleBoard-xM also fine with twl4030 codec.

Quoted 5 lines

I don't have my n900 in hacking mode (it is still in use time-to-time) but looking at the dts file: you might want to add ai3x-micbias-vg property to the aic3x nodes to select the correct mic bias voltage. I can't recall what is appropriate for n900, but 2.6.28-nokia sources might give you the answer.

No need to go that far. N900 has been supported in mainline since 2.6.39 or so. Part A of AIC34 (which is basically dual AIC33 in a same package) drives 2 V for the digital microphone bias and part B 2.5 V for the headset.

Unfortunately I haven't had time recently to try what might have caused that regression after 3.18.

Quoted 5 lines · Jarkko Nikula

Quoted 1 line · Peter Ujfalusi

On 01/18/2015 02:01 PM, Pavel Machek wrote:

No need to go that far. N900 has been supported in mainline since 2.6.39 or so. Part A of AIC34 (which is basically dual AIC33 in a same package) drives 2 V for the digital microphone bias and part B 2.5 V for the headset.

Let me try... Umm, no change here :-(

root at n900:/tmp# arecord delme
Recording WAVE 'delme' : Unsigned 8 bit, Rate 8000 Hz, Mono ^CAborted by signal Interrupt...
root at n900:/tmp# hexdump delme
0000000 4952 4646 987c 0000 4157 4556 6d66 2074 0000010 0010 0000 0001 0001 1f40 0000 1f40 0000 0000020 0001 0008 6164 6174 9858 0000 8080 8080 0000030 8080 8080 8080 8080 8080 8080 8080 8080
*
0009880
root at n900:/tmp# aplay delme
Playing WAVE 'delme' : Unsigned 8 bit, Rate 8000 Hz, Mono root at n900:/tmp#

I did this:

I'm not sure which one is "main" microphone and which is headset, but I guess 2V should be "close enough" to 2.5V to produce something different from zeros..?

Quoted 23 lines · Pavel Machek

Quoted 5 lines · Jarkko Nikula

Quoted 1 line · Peter Ujfalusi

On 01/18/2015 02:01 PM, Pavel Machek wrote:

No need to go that far. N900 has been supported in mainline since 2.6.39 or so. Part A of AIC34 (which is basically dual AIC33 in a same package) drives 2 V for the digital microphone bias and part B 2.5 V for the headset.

Let me try... Umm, no change here :-(

root at n900:/tmp# arecord delme
Recording WAVE 'delme' : Unsigned 8 bit, Rate 8000 Hz, Mono ^CAborted by signal Interrupt...
root at n900:/tmp# hexdump delme
0000000 4952 4646 987c 0000 4157 4556 6d66 2074 0000010 0010 0000 0001 0001 1f40 0000 1f40 0000 0000020 0001 0008 6164 6174 9858 0000 8080 8080 0000030 8080 8080 8080 8080 8080 8080 8080 8080
*
0009880
root at n900:/tmp# aplay delme
Playing WAVE 'delme' : Unsigned 8 bit, Rate 8000 Hz, Mono root at n900:/tmp#

Quoted 6 lines

I did this:

I'm not sure which one is "main" microphone and which is headset, but I guess 2V should be "close enough" to 2.5V to produce something different from zeros..?

Main or integrated is digital microphone which does AD conversion itself and headset is analogue. If DMIC is without bias codec will sample plain zeros from DMIC input but analogue input should always produce some random LSB bits from codec's AD converter.

If codec produces zeros also from analogue input then I suppose codec ADC is not powered up or similar. One way to hunt regression if bisecting is not possible due reason or another is to dump and diff codec registers from /sys/kernel/debug/regmap/ using both working commit and head.

arch/arm/boot/dts/omap3-n900.dts line 496

Quoted 11 lines

arch/arm/boot/dts/omap3-n900.dts +2 -0

index 48b0987..f18a5b0 100644
@@ -491,6 +491,8 @@
 		DRVDD-supply = <&vmmc2>;
 		IOVDD-supply = <&vio>;
 		DVDD-supply = <&vio>;
+
+		ai3x-micbias-vg = <1>;
 	};

Looks ok for digital mic.

Quoted 1 line

arch/arm/boot/dts/omap3-n900.dts line 509

Quoted 8 lines

arch/arm/boot/dts/omap3-n900.dts +2 -0

 	tlv320aic3x_aux: tlv320aic3x at 19 {

@@ -502,6 +504,8 @@
 		DRVDD-supply = <&vmmc2>;
 		IOVDD-supply = <&vio>;
 		DVDD-supply = <&vio>;
+
+		ai3x-micbias-vg = <1>;
 	};

This should be 2, i.e. 2.5 V according to Documentation/devicetree/bindings/sound/tlv320aic3x.txt. I think 2 V is too low for some headset mics and that was the reason for 2.5 V.

Quoted 11 lines

Quoted 6 lines

I did this:

I'm not sure which one is "main" microphone and which is headset, but I guess 2V should be "close enough" to 2.5V to produce something different from zeros..?

Main or integrated is digital microphone which does AD conversion itself and headset is analogue. If DMIC is without bias codec will sample plain zeros from DMIC input but analogue input should always produce some random LSB bits from codec's AD converter.

Quoted 5 lines

If codec produces zeros also from analogue input then I suppose codec ADC is not powered up or similar. One way to hunt regression if bisecting is not possible due reason or another is to dump and diff codec registers from /sys/kernel/debug/regmap/ using both working commit and head.

Quoted 11 lines

Review line 509

Quoted 8 lines

(quoted diff) +2 -0

 	tlv320aic3x_aux: tlv320aic3x at 19 {

@@ -502,6 +504,8 @@
 		DRVDD-supply = <&vmmc2>;
 		IOVDD-supply = <&vio>;
 		DVDD-supply = <&vio>;
+
+		ai3x-micbias-vg = <1>;
 	};

This should be 2, i.e. 2.5 V according to Documentation/devicetree/bindings/sound/tlv320aic3x.txt. I think 2 V is too low for some headset mics and that was the reason for 2.5 V.

Can you also try this patch to correct the DAPM route for the rx51:

sound/soc/omap/rx51.c +4 -4

index 04896d6252a2..7f299357c2d2 100644
@@ -250,14 +250,14 @@ static const struct snd_soc_dapm_route audio_map[] = {
 	{"FM Transmitter", NULL, "LLOUT"},
 	{"FM Transmitter", NULL, "RLOUT"},
 
-	{"DMic Rate 64", NULL, "Mic Bias"},
-	{"Mic Bias", NULL, "DMic"},
+	{"DMic Rate 64", NULL, "DMic"},
+	{"DMic", NULL, "Mic Bias"},
 
 	{"b LINE2R", NULL, "MONO_LOUT"},
 	{"Earphone", NULL, "b HPLOUT"},
 
-	{"LINE1L", NULL, "b Mic Bias"},
-	{"b Mic Bias", NULL, "HS Mic"}
+	{"LINE1L", NULL, "HS Mic"},
+	{"HS Mic", NULL, "b Mic Bias"},
 };
 
 static const char * const spk_function[] = {"Off", "On"};

Hi!

Quoted 12 lines

Quoted 12 lines

Quoted 5 lines

I did this:

I'm not sure which one is "main" microphone and which is headset, but I guess 2V should be "close enough" to 2.5V to produce something different from zeros..?

Main or integrated is digital microphone which does AD conversion itself and headset is analogue. If DMIC is without bias codec will sample plain zeros from DMIC input but analogue input should always produce some random LSB bits from codec's AD converter.

Quoted 7 lines

Quoted 7 lines

If codec produces zeros also from analogue input then I suppose codec ADC is not powered up or similar. One way to hunt regression if bisecting is not possible due reason or another is to dump and diff codec registers from /sys/kernel/debug/regmap/ using both working commit

and head.

I tried 2.6.28... where recording was, but it does not support regmap. Then I tried 3.14, but could not get recording to work there.

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

(quoted diff) +2 -0

 	tlv320aic3x_aux: tlv320aic3x at 19 {

@@ -502,6 +504,8 @@
 
 		DRVDD-supply = <&vmmc2>;
 		IOVDD-supply = <&vio>;
 		DVDD-supply = <&vio>;
 
+
+		ai3x-micbias-vg = <1>;
 

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

};

This should be 2, i.e. 2.5 V according to Documentation/devicetree/bindings/sound/tlv320aic3x.txt. I think 2 V is too low for some headset mics and that was the reason for 2.5 V.

Ok, tried that, but no change.

Quoted 1 line

Can you also try this patch to correct the DAPM route for the

Yes, with the patch below (and dts updates I did) recording works.

Another interesting note is that audio quality is not that horrible when playing 8 kHz, mono signal... it is mostly what I'd expect. Playing 44.1kHz, stereo mp3 .. is not good.

Tested-by Pavel Machek <[email protected]>

Thanks,
Pavel

Quoted 18 lines

sound/soc/omap/rx51.c +2 -2

index 04896d6252a2..7f299357c2d2 100644
@@ -250,14 +250,14 @@ static const struct snd_soc_dapm_route
 audio_map[] = {
 
 	{"FM Transmitter", NULL, "LLOUT"},
 	{"FM Transmitter", NULL, "RLOUT"},
 
-	{"DMic Rate 64", NULL, "Mic Bias"},
-	{"Mic Bias", NULL, "DMic"},
+	{"DMic Rate 64", NULL, "DMic"},
+	{"DMic", NULL, "Mic Bias"},
 
 	{"b LINE2R", NULL, "MONO_LOUT"},
 	{"Earphone", NULL, "b HPLOUT"},
 

Quoted 8 lines

sound/soc/omap/rx51.c +2 -2

-	{"LINE1L", NULL, "b Mic Bias"},
-	{"b Mic Bias", NULL, "HS Mic"}
+	{"LINE1L", NULL, "HS Mic"},
+	{"HS Mic", NULL, "b Mic Bias"},
 

};

static const char * const spk_function[] = {"Off", "On"};

Quoted 23 lines

Quoted 23 lines

sound/soc/omap/rx51.c +4 -4

index 04896d6252a2..7f299357c2d2 100644
@@ -250,14 +250,14 @@ static const struct snd_soc_dapm_route
 audio_map[] = {
 
 	{"FM Transmitter", NULL, "LLOUT"},
 	{"FM Transmitter", NULL, "RLOUT"},
 
-	{"DMic Rate 64", NULL, "Mic Bias"},
-	{"Mic Bias", NULL, "DMic"},
+	{"DMic Rate 64", NULL, "DMic"},
+	{"DMic", NULL, "Mic Bias"},
 
 	{"b LINE2R", NULL, "MONO_LOUT"},
 	{"Earphone", NULL, "b HPLOUT"},
 
-	{"LINE1L", NULL, "b Mic Bias"},
-	{"b Mic Bias", NULL, "HS Mic"}
+	{"LINE1L", NULL, "HS Mic"},
+	{"HS Mic", NULL, "b Mic Bias"},
 

Quoted 3 lines

Quoted 3 lines

};

static const char * const spk_function[] = {"Off", "On"};

Can you try DT and non-DT boot of 3.19? If there is difference?

sound/soc/omap/rx51.c +4 -4

index 04896d6252a2..7f299357c2d2 100644
@@ -250,14 +250,14 @@ static const struct snd_soc_dapm_route audio_map[] = {
 	{"FM Transmitter", NULL, "LLOUT"},
 	{"FM Transmitter", NULL, "RLOUT"},
 
-	{"DMic Rate 64", NULL, "Mic Bias"},
-	{"Mic Bias", NULL, "DMic"},
+	{"DMic Rate 64", NULL, "DMic"},
+	{"DMic", NULL, "Mic Bias"},
 
 	{"b LINE2R", NULL, "MONO_LOUT"},
 	{"Earphone", NULL, "b HPLOUT"},
 
-	{"LINE1L", NULL, "b Mic Bias"},
-	{"b Mic Bias", NULL, "HS Mic"}
+	{"LINE1L", NULL, "HS Mic"},
+	{"HS Mic", NULL, "b Mic Bias"},
 };
 
 static const char * const spk_function[] = {"Off", "On"};

I looked around the diff between 3.18 and 3.19, reverted these, and audio quality is back to reasonable level.

Hi!

Quoted 2 lines

I looked around the diff between 3.18 and 3.19, reverted these, and audio quality is back to reasonable level.

Actually, reverting 368494093354ac613a80c2e1d77602aa12473cf0 seems enough.

Any quick patches to test? Or should we revert so that 3.19-final works ok?

Quoted 5 lines · Pavel Machek

Hi!

Quoted 2 lines

I looked around the diff between 3.18 and 3.19, reverted these, and audio quality is back to reasonable level.

Quoted 5 lines

Actually, reverting 368494093354ac613a80c2e1d77602aa12473cf0 seems enough.

Any quick patches to test? Or should we revert so that 3.19-final works ok?

I'll send the fix in a minute, thanks for finding it ;)

Quoted 25 lines · Pavel Machek

Hi!

If you have any idea about playback problems, help would be still welcome. I'll have to do bisect, otherwise, and it will not be easy.

Quoted 11 lines

In 3.18, sound is nice and clear.

In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound.

Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise.

Any idea what could have caused it?

I tried audio recording this time.

In 2.6.28-nokia, it is neccessary to set "Input select" na "digital mic", then it works. Input select being in "playback" option makes it easy to miss.

In 3.18 and 3.19-rc3, all I can record are zeros.

Quoted 1 line

Does playback/recording work for you on OMAP 3430-based machines?

Same codec (tlv320aic3106) works fine on my am335x and omap-l138 boards. BeagleBoard-xM also fine with twl4030 codec.

I don't have my n900 in hacking mode (it is still in use time-to-time) but

looking at the dts file: you might want to add ai3x-micbias-vg property to the aic3x nodes to select the correct mic bias voltage. I can't recall what is appropriate for n900, but 2.6.28-nokia sources might give you the answer.