April 2010 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] USB transfer_buffer allocations on 64bit systems
by Daniel Mack 15 Apr '10

15 Apr '10

Hi, I was pointed to https://bugzilla.kernel.org/show_bug.cgi?id=15580 by Pedro Ribeiro, and unfortunately I'm pretty late in the game. I wasn't aware of that thread until yesterday. While the report is quite confusing, the reason seams pretty clear to me as I've been thru quite some time-demanding debugging of a very similar issue on Mac OS X. But I'm not totally sure whether we really hit the same issue here, so I'd like to have your opinions first. The problem is appearantly the way the transfer buffer is allocated in the drivers. In the snd-usb-caiaq driver, I used kzalloc() to get memory which works fine on 32bit systems. On x86_64, however, it seems that kzalloc() hands out memory beyond the 32bit addressable boundary, which the DMA controller of the 32bit PCI-connected EHCI controller is unable to write to or read from. Am I correct on this conclusion? Depending on the condition of the memory management, things might work or not, and especially right after a reboot, there's a better chance to get lower memory. The fix is to use usb_buffer_alloc() for that purpose which ensures memory that is suitable for DMA. And on x86_64, this also means that the upper 32 bits of the address returned are all 0's. If what I've stated is true, there are quite some more drivers affected by this issue. I collected a list of places where similar fixes are needed, and I can send patches if I get a thumbs-up. Pedro is currently testing a patch I sent out yesterday. Thanks, Daniel

11 88

[alsa-devel] [PATCH] ALSA: Add initial support for Thinkpad T410s HDA codec.
by Jens Taprogge 15 Apr '10

15 Apr '10

Dear ALSA Maintainers, attached please find a patch that adds support for at least the T410s HDA codec. Most likely it will also add support for the T410 and T510 based models. The patch was derived from Ideapad support. Support for the laptop's and docking-station output connectors as well as the docking-station microphone connector and the laptops internal devices has been tested. Since it has been developed without a data-sheet available, support for digital outputs and the laptop's microphone input may well be incorrect. Microphone mute functionality is not included: The microphone mute button seems to be reported through thinkpad_acpi key 0000101b. The mute button LED seems to be wired to thinkpad_acpi led number 15. Please apply. Signed-off-by: Jens Taprogge <jens.taprogge(a)taprogge.org> --- sound/pci/hda/patch_conexant.c | 153 ++++++++++++++++++++++++++++++++++++++- 1 files changed, 149 insertions(+), 4 deletions(-) diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 61682e1..2a488f6 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -115,6 +115,7 @@ struct conexant_spec { unsigned int port_d_mode; unsigned int dell_vostro:1; unsigned int ideapad:1; + unsigned int thinkpad:1; unsigned int ext_mic_present; unsigned int recording; @@ -2031,6 +2032,9 @@ static void cxt5066_update_speaker(struct hda_codec *codec) /* Port D (HP/LO) */ pinctl = ((spec->hp_present & 2) && spec->cur_eapd) ? spec->port_d_mode : 0; + /* Mute if Port A is connected on Thinkpad */ + if (spec->thinkpad && (spec->hp_present & 1)) + pinctl = 0; snd_hda_codec_write(codec, 0x1c, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, pinctl); @@ -2211,6 +2215,50 @@ static void cxt5066_ideapad_automic(struct hda_codec *codec) } } +/* toggle input of built-in digital mic and mic jack appropriately + order is: external mic -> dock mic -> interal mic */ +static void cxt5066_thinkpad_automic(struct hda_codec *codec) +{ + unsigned int ext_present, dock_present; + + static struct hda_verb ext_mic_present[] = { + {0x14, AC_VERB_SET_CONNECT_SEL, 0}, + {0x17, AC_VERB_SET_CONNECT_SEL, 1}, + {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_VREF80}, + {0x23, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + {0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + {} + }; + static struct hda_verb dock_mic_present[] = { + {0x14, AC_VERB_SET_CONNECT_SEL, 0}, + {0x17, AC_VERB_SET_CONNECT_SEL, 0}, + {0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_VREF80}, + {0x23, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + {} + }; + static struct hda_verb ext_mic_absent[] = { + {0x14, AC_VERB_SET_CONNECT_SEL, 2}, + {0x23, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN}, + {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + {0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + {} + }; + + ext_present = snd_hda_jack_detect(codec, 0x1b); + dock_present = snd_hda_jack_detect(codec, 0x1a); + if (ext_present) { + snd_printdd("CXT5066: external microphone detected\n"); + snd_hda_sequence_write(codec, ext_mic_present); + } else if (dock_present) { + snd_printdd("CXT5066: dock microphone detected\n"); + snd_hda_sequence_write(codec, dock_mic_present); + } else { + snd_printdd("CXT5066: external microphone absent\n"); + snd_hda_sequence_write(codec, ext_mic_absent); + } +} + /* mute internal speaker if HP is plugged */ static void cxt5066_hp_automute(struct hda_codec *codec) { @@ -2223,7 +2271,8 @@ static void cxt5066_hp_automute(struct hda_codec *codec) /* Port D */ portD = snd_hda_jack_detect(codec, 0x1c); - spec->hp_present = !!(portA | portD); + spec->hp_present = !!(portA); + spec->hp_present |= portD ? 2 : 0; snd_printdd("CXT5066: hp automute portA=%x portD=%x present=%d\n", portA, portD, spec->hp_present); cxt5066_update_speaker(codec); @@ -2274,6 +2323,20 @@ static void cxt5066_ideapad_event(struct hda_codec *codec, unsigned int res) } } +/* unsolicited event for jack sensing */ +static void cxt5066_thinkpad_event(struct hda_codec *codec, unsigned int res) +{ + snd_printdd("CXT5066_thinkpad: unsol event %x (%x)\n", res, res >> 26); + switch (res >> 26) { + case CONEXANT_HP_EVENT: + cxt5066_hp_automute(codec); + break; + case CONEXANT_MIC_EVENT: + cxt5066_thinkpad_automic(codec); + break; + } +} + static const struct hda_input_mux cxt5066_analog_mic_boost = { .num_items = 5, .items = { @@ -2292,7 +2355,7 @@ static void cxt5066_set_mic_boost(struct hda_codec *codec) AC_VERB_SET_AMP_GAIN_MUTE, AC_AMP_SET_RIGHT | AC_AMP_SET_LEFT | AC_AMP_SET_OUTPUT | cxt5066_analog_mic_boost.items[spec->mic_boost].index); - if (spec->ideapad) { + if (spec->ideapad | spec->thinkpad) { /* adjust the internal mic as well...it is not through 0x17 */ snd_hda_codec_write_cache(codec, 0x23, 0, AC_VERB_SET_AMP_GAIN_MUTE, @@ -2780,6 +2843,64 @@ static struct hda_verb cxt5066_init_verbs_ideapad[] = { { } /* end */ }; +static struct hda_verb cxt5066_init_verbs_thinkpad[] = { + {0x1e, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN}, /* Port F */ + {0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN}, /* Port E */ + + /* Port G: internal speakers */ + {0x1f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, + {0x1f, AC_VERB_SET_CONNECT_SEL, 0x00}, /* DAC1 */ + + /* Port A: HP, Amp */ + {0x19, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + {0x19, AC_VERB_SET_CONNECT_SEL, 0x00}, /* DAC1 */ + + /* Port B: Mic Dock */ + {0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + + /* Port C: Mic */ + {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + + /* Port D: HP Dock, Amp */ + {0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + {0x1c, AC_VERB_SET_CONNECT_SEL, 0x00}, /* DAC1 */ + + /* DAC1 */ + {0x10, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE}, + + /* Node 14 connections: 0x17 0x18 0x23 0x24 0x27 */ + {0x14, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0) | 0x50}, + {0x14, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)}, + {0x14, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(2) | 0x50}, + {0x14, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, + {0x14, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)}, + {0x14, AC_VERB_SET_CONNECT_SEL, 2}, /* default to internal mic */ + + /* Audio input selector */ + {0x17, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE | 0x2}, + {0x17, AC_VERB_SET_CONNECT_SEL, 1}, /* route ext mic */ + + /* SPDIF route: PCM */ + {0x20, AC_VERB_SET_CONNECT_SEL, 0x0}, + {0x22, AC_VERB_SET_CONNECT_SEL, 0x0}, + + {0x20, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, + {0x22, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, + + /* internal microphone */ + {0x23, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN}, /* enable int mic */ + + /* EAPD */ + {0x1d, AC_VERB_SET_EAPD_BTLENABLE, 0x2}, /* default on */ + + /* enable unsolicited events for Port A, B, C and D */ + {0x19, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | CONEXANT_HP_EVENT}, + {0x1c, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | CONEXANT_HP_EVENT}, + {0x1a, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | CONEXANT_MIC_EVENT}, + {0x1b, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | CONEXANT_MIC_EVENT}, + { } /* end */ +}; + static struct hda_verb cxt5066_init_verbs_portd_lo[] = { {0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, { } /* end */ @@ -2798,6 +2919,8 @@ static int cxt5066_init(struct hda_codec *codec) cxt5066_vostro_automic(codec); else if (spec->ideapad) cxt5066_ideapad_automic(codec); + else if (spec->thinkpad) + cxt5066_thinkpad_automic(codec); } cxt5066_set_mic_boost(codec); return 0; @@ -2819,20 +2942,22 @@ static int cxt5066_olpc_init(struct hda_codec *codec) } enum { - CXT5066_LAPTOP, /* Laptops w/ EAPD support */ + CXT5066_LAPTOP, /* Laptops w/ EAPD support */ CXT5066_DELL_LAPTOP, /* Dell Laptop */ CXT5066_OLPC_XO_1_5, /* OLPC XO 1.5 */ CXT5066_DELL_VOSTO, /* Dell Vostro 1015i */ CXT5066_IDEAPAD, /* Lenovo IdeaPad U150 */ + CXT5066_THINKPAD, /* Lenovo ThinkPad T410s, others? */ CXT5066_MODELS }; static const char *cxt5066_models[CXT5066_MODELS] = { - [CXT5066_LAPTOP] = "laptop", + [CXT5066_LAPTOP] = "laptop", [CXT5066_DELL_LAPTOP] = "dell-laptop", [CXT5066_OLPC_XO_1_5] = "olpc-xo-1_5", [CXT5066_DELL_VOSTO] = "dell-vostro", [CXT5066_IDEAPAD] = "ideapad", + [CXT5066_THINKPAD] = "thinkpad", }; static struct snd_pci_quirk cxt5066_cfg_tbl[] = { @@ -2843,6 +2968,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = { SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5), SND_PCI_QUIRK(0x1028, 0x0402, "Dell Vostro", CXT5066_DELL_VOSTO), SND_PCI_QUIRK(0x17aa, 0x3a0d, "ideapad", CXT5066_IDEAPAD), + SND_PCI_QUIRK(0x17aa, 0x215e, "Lenovo Thinkpad", CXT5066_THINKPAD), {} }; @@ -2950,6 +3076,22 @@ static int patch_cxt5066(struct hda_codec *codec) /* input source automatically selected */ spec->input_mux = NULL; break; + case CXT5066_THINKPAD: + codec->patch_ops.init = cxt5066_init; + codec->patch_ops.unsol_event = cxt5066_thinkpad_event; + spec->mixers[spec->num_mixers++] = cxt5066_mixer_master; + spec->mixers[spec->num_mixers++] = cxt5066_mixers; + spec->init_verbs[0] = cxt5066_init_verbs_thinkpad; + spec->thinkpad = 1; + spec->port_d_mode = PIN_OUT; + spec->mic_boost = 2; /* default 20dB gain */ + + /* no S/PDIF out */ + spec->multiout.dig_out_nid = 0; + + /* input source automatically selected */ + spec->input_mux = NULL; + break; } return 0; @@ -2969,6 +3111,8 @@ static struct hda_codec_preset snd_hda_preset_conexant[] = { .patch = patch_cxt5066 }, { .id = 0x14f15067, .name = "CX20583 (Pebble HSF)", .patch = patch_cxt5066 }, + { .id = 0x14f15069, .name = "CX20585", + .patch = patch_cxt5066 }, {} /* terminator */ }; @@ -2977,6 +3121,7 @@ MODULE_ALIAS("snd-hda-codec-id:14f15047"); MODULE_ALIAS("snd-hda-codec-id:14f15051"); MODULE_ALIAS("snd-hda-codec-id:14f15066"); MODULE_ALIAS("snd-hda-codec-id:14f15067"); +MODULE_ALIAS("snd-hda-codec-id:14f15069"); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("Conexant HD-audio codec"); -- 1.7.0.4

2 1

Re: [alsa-devel] [Cooker] Totem playing videos at fast-forward speed ?
by Herton Ronaldo Krzesinski 15 Apr '10

15 Apr '10

Em Ter 13 Abr 2010, às 18:57:51, Éric Piel escreveu: > Op 07-04-10 00:23, Herton Ronaldo Krzesinski schreef: > > Em Ter 06 Abr 2010, às 18:52:08, Éric Piel escreveu: > >> Op 06-04-10 22:29, Frank Griffin schreef: > >>> Anssi Hannula wrote: > >>>> Try mplayer: > >>>> mplayer file > >>>> > >>> > >>> Same speedup symptom as Totem > >>> > >>>> and mplayer without audio: > >>>> mplayer -ao null file > >>>> > >>> > >>> Back to normal speed. > >>> > >> > >> Hi, > >> I'm experiencing a similar problem on a machine with an intel HDA. It > >> happens only with a kernel 2.6.34-rc*. With a vanilla 2.6.33, everything > >> is fine. Is your kernel the normal cooker kernel? > >> > >> Does anyone know if there are some update to alsa in this kernel > >> compared to the vanilla kernel? > > > > yes, there is some pcm_lib changes applied from 2.6.34-rc* because of > > pulseaudio. Would be good to know if reverting these changes on 2.6.34 fixes > > the problem: > > ALSA: pcm_lib - fix xrun functionality > > ALSA: pcm_native - fix runtime->boundary calculation > > ALSA: pcm_lib - return back hw_ptr_interrupt > > ALSA: pcm_core: Fix wake_up() optimization > > ALSA: pcm_lib - fix wrong delta print for jiffies check > > ALSA: pcm_lib: fix "something must be really wrong" condition > > ALSA: pcm_lib - optimize wake_up() calls for PCM I/O > > ALSA: pcm_lib - cleanup & merge hw_ptr update functions > > ALSA: pcm_lib - add possibility to log last 10 DMA ring buffer positions > > ALSA: pcm_lib.c - convert second xrun_debug() parameter to use defines > Hi, > I've done a bisection on a vanilla kernel, and it turned out to be > 7b3a177b0d4f92b3431b8dca777313a07533a710, aka ALSA: pcm_lib: fix > "something must be really wrong" condition . > > So I'd recommend to drop it from the mandriva kernel, and get confirmed > it is fixed. Ok adding alsa-devel to CC, may be the issue is known. Eric, from later messages you only experience the problem when bdl_pos_adj isn't set to 1 right? Anyway Frank said that his bdl_pos_adj is set to 32 on two machines (hda-intel), and on one of them the problem happens, while in the other not. I guess we could have a problem then on commit 7b3a177b0d4f92b3431b8dca777313a07533a710 > > See you, > Eric > -- []'s Herton

2 1

[alsa-devel] imx-ssi fixes
by Sascha Hauer 15 Apr '10

15 Apr '10

Just a resend of the patches I sent yesterday with an updated commit message. Sascha

3 4

[alsa-devel] [PATCH] ALSA: hda - via - fix master mute and automute with VT1812/VT2002P
by Herton Ronaldo Krzesinski 14 Apr '10

14 Apr '10

On VIA VT1812/VT2002P, the "Master Front Playback Switch" doesn't mute first line-out. This is an issue, for example I saw a laptop with VT1812 and only one line-out (main speaker) that doesn't mute main speaker, because the master switch doesn't act on first line-out, and first line-out nid in array is assigned to speaker as expected by autoconfig code. But there is one more issue also: main switches and automute code deal with mute on same Amp-Outs, which can cause conflicts, thus if you mute "Master Front Playback Switch" and remove headphone for example, it will not respect the mixer setting. To solve it, we can change the pin type instead of muting Amp-Out, which is done here. Signed-off-by: Herton Ronaldo Krzesinski <herton(a)mandriva.com.br> --- sound/pci/hda/patch_via.c | 23 +++++++++-------------- 1 files changed, 9 insertions(+), 14 deletions(-) Hi, I'm attaching the codec file of the laptop with the issue, this is kernel log relevant info: autoconfig: line_outs=1 (0x24/0x0/0x0/0x0/0x0) speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) hp_outs=1 (0x33/0x0/0x0/0x0/0x0) mono: mono_out=0x0 inputs: mic=0x29, fmic=0x2b, line=0x0, fline=0x0, cd=0x0, aux=0x0 diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index 9ddc373..d6e6f40 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -295,8 +295,6 @@ static int analog_input_switch_put(struct snd_kcontrol *kcontrol, .put = analog_input_switch_put, \ .private_value = HDA_COMPOSE_AMP_VAL(0, 3, 0, 0) } -static void via_hp_bind_automute(struct hda_codec *codec); - static int bind_pin_switch_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { @@ -343,13 +341,10 @@ static int bind_pin_switch_put(struct snd_kcontrol *kcontrol, snd_hda_codec_amp_stereo( codec, spec->autocfg.speaker_pins[i], HDA_OUTPUT, 0, HDA_AMP_MUTE, 0); - /* unmute */ - via_hp_bind_automute(codec); - } else { if (lmute) { /* Mute all left channels */ - for (i = 1; i < spec->autocfg.line_outs; i++) + for (i = 0; i < spec->autocfg.line_outs; i++) snd_hda_codec_amp_update( codec, spec->autocfg.line_out_pins[i], @@ -364,7 +359,7 @@ static int bind_pin_switch_put(struct snd_kcontrol *kcontrol, } if (rmute) { /* mute all right channels */ - for (i = 1; i < spec->autocfg.line_outs; i++) + for (i = 0; i < spec->autocfg.line_outs; i++) snd_hda_codec_amp_update( codec, spec->autocfg.line_out_pins[i], @@ -2129,18 +2124,18 @@ static void via_hp_bind_automute(struct hda_codec *codec) if (!spec->hp_independent_mode) { /* Mute Line-Outs */ for (i = 0; i < spec->autocfg.line_outs; i++) - snd_hda_codec_amp_stereo( - codec, spec->autocfg.line_out_pins[i], - HDA_OUTPUT, 0, - HDA_AMP_MUTE, hp_present ? HDA_AMP_MUTE : 0); + snd_hda_codec_write(codec, + spec->autocfg.line_out_pins[i], + 0, AC_VERB_SET_PIN_WIDGET_CONTROL, + hp_present ? 0 : PIN_OUT); if (hp_present) present = hp_present; } /* Speakers */ for (i = 0; i < spec->autocfg.speaker_outs; i++) - snd_hda_codec_amp_stereo( - codec, spec->autocfg.speaker_pins[i], HDA_OUTPUT, 0, - HDA_AMP_MUTE, present ? HDA_AMP_MUTE : 0); + snd_hda_codec_write(codec, spec->autocfg.speaker_pins[i], 0, + AC_VERB_SET_PIN_WIDGET_CONTROL, + present ? 0 : PIN_OUT); } -- 1.7.0.4

2 3

Re: [alsa-devel] asus xonar d1
by Clemens Ladisch 14 Apr '10

14 Apr '10

Lars Schotte wrote: > > What controls are missing? > > hmm. i dont know, i thought there will be more on such a card. because > on creatives and hd audio usually you have tons of controls and there > only 5 or so. The D1/DX hardware doesn't have that many controls because there aren't so many inputs or outputs. > and 3 of them is 7.1 output so its a bit confusing. There is one "Master" control with 8 channels. How this is displayed is up to the mixer application. (alsamixer isn't ideal in this respect, older versions even less so.) > to fedora 13 the controls are noticably faster, to my old debian lenny > even w/ the 2.6.32 kernel they lag. on fedora 13 w/ 2.6.33 they are > fast as usual, seems like you fixed that already ;-) . Yes, the driver now doesn't write registers that have not changed. In theory, this shouldn't make too much of a difference unless the mixer tries to set the same volume repeatedly. Regards, Clemens

1 0

[alsa-devel] ALSA application programming: route audio from one PCM to another
by Stefan Schoenleitner 14 Apr '10

14 Apr '10

Hi, I finally managed to write an ALSA I/O plugin that does what I want. The plugin supports both playback and capture. Now I would like to write a simple audio application that takes audio samples * from the microphone and plays it back on my plugin and * from the plugin (capture) and plays it back on the speakers Hence as long as the application is running, it should do the above. * Is there a special ALSA way to route audio from one PCM to another ? * If not, I suppose it would just work if I open the plugin PCM and the hw PCM at the same time and copy audio frames between them ? cheers, stefan

2 4

[alsa-devel] Procfs cleanup in ALSA core
by Takashi Iwai 14 Apr '10

14 Apr '10

Hi, the another fixes are clean-ups of procfs interface in ALSA core. The patches below are found in sound git tree topic/core-cleanup branch. (This branch also contains the BKL-cleanup branch, too). [PATCH 1/5] ALSA: info - Use standard types for info callbacks [PATCH 2/5] ALSA: info - Check file position validity in common layer [PATCH 3/5] ALSA: info - Implement common llseek for binary mode [PATCH 4/5] ALSA: core - Define llseek fops [PATCH 5/5] ALSA: Update the documentation for changes of proc files Takashi

1 5

[alsa-devel] BKL removal from ALSA core
by Takashi Iwai 14 Apr '10

14 Apr '10

Hi, I recently cleaned up ALSA core code a bit. The first attemp is the removal of BKL, at least, in ALSA side. There are still in sound_core.c and OSS drivers, but who cares ;) The patches below are in sound git tree topic/bkl branch. [PATCH 1/3] ALSA: pcm - Remove BKL from async callback [PATCH 2/3] ALSA: info - Remove BKL [PATCH 3/3] ALSA: Remove BKL from open multiplexer Takashi

1 3

[alsa-devel] [RFC] ALSA: pcm_lib - read/write IO improvement
by Jarkko Nikula 14 Apr '10

14 Apr '10

Hi I've noticed a problem with the ALSA read/write IO as it tries to pad buffer as full/empty as possible after each wake-up. Then there is no wake-up during the next period interrupt since avail < avail_min and effectively there could be very short time left for wake-up on an interrupt after that. What I've seen on OMAP3 and Intel HDA that typically avail_max is only a frame or two less than size of two periods. I.e. very near to xrun when using a buffer with two periods. I came up with two ideas. The first one won't do padding and the second one which does the padding as currently but checks are there available frames in the next period and does a wake-up if necessary (even if the avail < avail_min). With the first one, the avail_max is typically a few frames more than the size of one period. With the second one it's a few frames less than size of one period. So by not doing the padding the distance to xrun is about the same and the wake-up semantics remains the same. I understood from the thread below that not all applications like if the wake-up happens before avail >= avail_min what would happen with the second idea. http://mailman.alsa-project.org/pipermail/alsa-devel/2009-December/023986.h… -- Jarkko ========================== RFC 1 ========================== From: Jarkko Nikula <jhnikula(a)gmail.com> Subject: [PATCH] ALSA: pcm_lib - Do not copy less than avail_min amount of frames in RW IO Copying less than avail_min amount of frames after each wake-up, i.e. by padding buffer as full/empty as possible by following the running HW pointer can actually cause xrun to be more possible than without padding. Padding causes that the avail is less than the avail_min when the next period interrupt occurs and thus no wake-up at that time. However, period interrupt following that one will see a situation where the avail is near the size of two periods. I.e. there could be only few frames left before xrun would happen if the buffer size is only two periods. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> --- sound/core/pcm_lib.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index a2ff861..a47a010 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -1821,7 +1821,7 @@ static snd_pcm_sframes_t snd_pcm_lib_write1(struct snd_pcm_substream *substream, if (runtime->status->state == SNDRV_PCM_STATE_RUNNING) snd_pcm_update_hw_ptr(substream); avail = snd_pcm_playback_avail(runtime); - if (!avail) { + if (avail < runtime->control->avail_min) { if (nonblock) { err = -EAGAIN; goto _end_unlock; @@ -2043,7 +2043,7 @@ static snd_pcm_sframes_t snd_pcm_lib_read1(struct snd_pcm_substream *substream, if (runtime->status->state == SNDRV_PCM_STATE_RUNNING) snd_pcm_update_hw_ptr(substream); avail = snd_pcm_capture_avail(runtime); - if (!avail) { + if (avail < runtime->control->avail_min) { if (runtime->status->state == SNDRV_PCM_STATE_DRAINING) { snd_pcm_stop(substream, SNDRV_PCM_STATE_SETUP); -- ========================== RFC 2 ========================== From: Jarkko Nikula <jhnikula(a)gmail.com> Subject: [PATCH] ALSA: pcm_lib - Do wake-up and copy if the next period has available frames It is possible that the next period has only a few frames before xrun would happen after next interrupt but wakeup does not happen now since the avail is less than the avail_min threshold. This patch adds a wake-up and copy check if the appl_ptr is less than end of next period so that application can transfer data already now. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> --- sound/core/pcm_lib.c | 17 +++++++++++++---- 1 files changed, 13 insertions(+), 4 deletions(-) diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index a2ff861..424873d 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -268,7 +268,7 @@ static void xrun_log_show(struct snd_pcm_substream *substream) int snd_pcm_update_state(struct snd_pcm_substream *substream, struct snd_pcm_runtime *runtime) { - snd_pcm_uframes_t avail; + snd_pcm_uframes_t avail, next_end; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) avail = snd_pcm_playback_avail(runtime); @@ -287,7 +287,11 @@ int snd_pcm_update_state(struct snd_pcm_substream *substream, return -EPIPE; } } - if (avail >= runtime->control->avail_min) + next_end = runtime->hw_ptr_interrupt + 2 * runtime->period_size - 1; + if (next_end >=runtime->boundary) + next_end -= runtime->boundary; + if (avail >= runtime->control->avail_min || + runtime->control->appl_ptr <= next_end) wake_up(runtime->twake ? &runtime->tsleep : &runtime->sleep); return 0; } @@ -1707,7 +1711,7 @@ static int wait_for_avail_min(struct snd_pcm_substream *substream, int is_playback = substream->stream == SNDRV_PCM_STREAM_PLAYBACK; wait_queue_t wait; int err = 0; - snd_pcm_uframes_t avail = 0; + snd_pcm_uframes_t avail = 0, next_end; long tout; init_waitqueue_entry(&wait, current); @@ -1750,7 +1754,12 @@ static int wait_for_avail_min(struct snd_pcm_substream *substream, avail = snd_pcm_playback_avail(runtime); else avail = snd_pcm_capture_avail(runtime); - if (avail >= runtime->control->avail_min) + next_end = runtime->hw_ptr_interrupt + + 2 * runtime->period_size - 1; + if (next_end >=runtime->boundary) + next_end -= runtime->boundary; + if (avail >= runtime->control->avail_min || + runtime->control->appl_ptr <= next_end) break; } _endloop: --

3 3