2011/4/20 Takashi Iwai tiwai@suse.de

At Tue, 12 Apr 2011 10:17:32 +0800, Raymond Yau wrote:

...

Since commit 148c2b8e7c12b4ab8a039995fa9904e7e1300cc4. Front channels via fxbus 8 and 9

No sound from the front jack of SB Live! platinum CT4760P when the application using "front" device but sound from front jack when

application

...

using hw:0,0 and /dev/dsp

Error message " I: (alsa-lib)setup.c: Cannot lock ctl elem*"* when Pulseaudio server open "front" device for playback and capture at the

same

...

time because of locked "EMU10K1 Send PCM Volume"

These are two different problems. The latter can be solved by removing the locks in hooks.

But reverting the whole FX routing causes a regression, so can't be taken as is. If the FX route 8/9 can't be used for the front output on some models, the driver should notify it somehow and we need to handle differently for them. Typically, the driver sets a different driver-name so that alsa-lib can use the corresponding card config file.

I'll fix the lock issue first.

thanks,

Takashi

Your patch only fix the lock issue only.

If one application using "front" device for playback , the audio signal changed from right to left when the other application using "rear" device for recording.,

if one application using "hw:0,0" for playback , stop to hear any audio whenever other application using "rear" device for recording

so this look like the playback is affected whenever other application use "front" or "rear" device for capturing,

At Sat, 23 Apr 2011 11:33:20 +0800, Raymond Yau wrote:

2011/4/20 Takashi Iwai tiwai@suse.de

...

At Tue, 12 Apr 2011 10:17:32 +0800, Raymond Yau wrote:

...

Since commit 148c2b8e7c12b4ab8a039995fa9904e7e1300cc4. Front channels via fxbus 8 and 9

But reverting the whole FX routing causes a regression, so can't be taken as is. If the FX route 8/9 can't be used for the front output on some models, the driver should notify it somehow and we need to handle differently for them. Typically, the driver sets a different driver-name so that alsa-lib can use the corresponding card config file.

I'll fix the lock issue first.

After commit b6a48404088d91514b9e78c3237976a5aa87cb14 to get back the "Front Playback Volume"

It seem that CT4760P has the following behaviour

Playing audio using

1. hw:0,0

"Wave Playback Volume" , "Master Playback Volume" and "PCM Playback Volume" control the volume of front jack

"Wave Surround Volume" pan the audio to "rear" jack

"Front Playback Volume"" and "Surround Playback Volume" have no effect on front jack and rear jack

2. front:0

"Front" Playback Volume" , "Master Playback Volume" and "PCM Playback Volume" control the volume of front jack

no sound from rear jack (i.e. Wave Surround Playback Volume" does not has any effect on rear jack)

3. rear:0

"Surround Playback Volume" control the volume of the rear jack

"Master Playback Volume" and "Wave Surround Volume" have no effect on rear jack

4. device 3

using alsa-jack plugin and jackd -d alsa -P hw:0,3 -o 16

"Wave Playback Volume" control the volume of playback_1 and playback_2 "Front Playback Volume" control the volume of playback_9 and playback_10

with high_res_gpr_volume=0 (EMU10K1_GPR_TRANSLATION_TABLE100)

Those Playback Volume controls except Master and PCM have fixed step 0.4 dB

range '0 - 100' dbmin -9999999 (TLV_DB_GAIN_MUTE ) dbmax 0

with high_res_gpr_volume=1 (EMU10K1_GPR_TRANSLATION_NONE)

Those Playback Volume controls except Master and PCM have linear scale

range '0 - 2147483647' dbmin -9999999 (TLV_DB_GAIN_MUTE ) dbmax 0

So, the issues are:

1. "Wave Front" and "Wave Rear" mixers aren't reflected to front and rear PCM 2. "Master" doesn't control the rear jack 3. When recorded from front or rear PCM, the playback is affected

? Any other issues?

2 is a long-standing known issue, and it's irrelevant with the routing. 1 and 3 are routing issues.

Is it a bug for PA server to add TLV_DB_GAIN_MUTE - infinite dB range of "Front" and "Surround" and those finite dB range of "Master" and "PCM" ?

Hrm, not sure. Could you elaborate?

thanks,

Takashi