[alsa-devel] HDA Beep Device for Asus EeeBox EB1501P
Hi,
I own an Asus EeeBox EB1501P with an ALC662 codec and had no HDA mixer channel for the speaker beep device. After digging somewhat in the kernel source I found that I only need to add a single line in the beep_white_list in patch_realtek.c. May be this entry can be included in the mainstream drivers:
SND_PCI_QUIRK(0x1043, 0x8376, "EeePC", 1),
After recompiling the driver with this entry, the mixer device for the beep channel appears and the digital beep sound is emitted on the connected speakers.
... with one problem:
If I use echo -e "\a" in a shell or run the beep command utility the sound appears only on second and following invocations. Whenever the frequency changes with the beep command the first invocation stays silent or just produce some click due to ALSA driver power saving. On all further invocations with same frequency the requested tone is generated on external speakers. There is no difference in behavior if the commands are called in a terminal emulator or directly on a virtual text console.
Does this happen only on my machine or is this a known problem? Is there anything I can do to fix this behavior?
The kernel I used for testing is 3.8.0 from Gentoo Sources.
Feel free to ask for any information you may need for debugging.
Thx for any help ahead Harald
At Wed, 20 Feb 2013 22:51:53 +0100, Harald Becker wrote:
Hi,
I own an Asus EeeBox EB1501P with an ALC662 codec and had no HDA mixer channel for the speaker beep device. After digging somewhat in the kernel source I found that I only need to add a single line in the beep_white_list in patch_realtek.c. May be this entry can be included in the mainstream drivers:
SND_PCI_QUIRK(0x1043, 0x8376, "EeePC", 1),
After recompiling the driver with this entry, the mixer device for the beep channel appears and the digital beep sound is emitted on the connected speakers.
Could you submit a proper patch for it?
... with one problem:
If I use echo -e "\a" in a shell or run the beep command utility the sound appears only on second and following invocations. Whenever the frequency changes with the beep command the first invocation stays silent or just produce some click due to ALSA driver power saving. On all further invocations with same frequency the requested tone is generated on external speakers. There is no difference in behavior if the commands are called in a terminal emulator or directly on a virtual text console.
Does this happen only on my machine or is this a known problem? Is there anything I can do to fix this behavior?
So, the behavior above disappears if you disable the power save? Does the patch like below have any influence on the behavior?
thanks,
Takashi
--- diff --git a/sound/pci/hda/hda_beep.c b/sound/pci/hda/hda_beep.c index 0849aac..63c9909 100644 --- a/sound/pci/hda/hda_beep.c +++ b/sound/pci/hda/hda_beep.c @@ -39,13 +39,23 @@ static void snd_hda_generate_beep(struct work_struct *work) struct hda_beep *beep = container_of(work, struct hda_beep, beep_work); struct hda_codec *codec = beep->codec; + int tone;
if (!beep->enabled) return;
+ tone = beep->tone; + if (tone && !beep->playing) { + snd_hda_power_up(codec); + beep->playing = 1; + } /* generate tone */ snd_hda_codec_write(codec, beep->nid, 0, - AC_VERB_SET_BEEP_CONTROL, beep->tone); + AC_VERB_SET_BEEP_CONTROL, tone); + if (!tone && beep->playing) { + beep->playing = 0; + snd_hda_power_down(codec); + } }
/* (non-standard) Linear beep tone calculation for IDT/STAC codecs @@ -115,14 +125,23 @@ static int snd_hda_beep_event(struct input_dev *dev, unsigned int type, return 0; }
+static void turn_off_beep(struct hda_beep *beep) +{ + cancel_work_sync(&beep->beep_work); + if (beep->playing) { + /* turn off beep */ + snd_hda_codec_write(beep->codec, beep->nid, 0, + AC_VERB_SET_BEEP_CONTROL, 0); + beep->playing = 0; + snd_hda_power_down(beep->codec); + } +} + static void snd_hda_do_detach(struct hda_beep *beep) { input_unregister_device(beep->dev); beep->dev = NULL; - cancel_work_sync(&beep->beep_work); - /* turn off beep for sure */ - snd_hda_codec_write(beep->codec, beep->nid, 0, - AC_VERB_SET_BEEP_CONTROL, 0); + turn_off_beep(beep); }
static int snd_hda_do_attach(struct hda_beep *beep) @@ -170,12 +189,8 @@ int snd_hda_enable_beep_device(struct hda_codec *codec, int enable) enable = !!enable; if (beep->enabled != enable) { beep->enabled = enable; - if (!enable) { - cancel_work_sync(&beep->beep_work); - /* turn off beep */ - snd_hda_codec_write(beep->codec, beep->nid, 0, - AC_VERB_SET_BEEP_CONTROL, 0); - } + if (!enable) + turn_off_beep(beep); return 1; } return 0; @@ -198,7 +213,7 @@ int snd_hda_attach_beep_device(struct hda_codec *codec, int nid) snprintf(beep->phys, sizeof(beep->phys), "card%d/codec#%d/beep0", codec->bus->card->number, codec->addr); /* enable linear scale */ - snd_hda_codec_write(codec, nid, 0, + snd_hda_codec_write_cache(codec, nid, 0, AC_VERB_SET_DIGI_CONVERT_2, 0x01);
beep->nid = nid; diff --git a/sound/pci/hda/hda_beep.h b/sound/pci/hda/hda_beep.h index 4dc6933..cb88464 100644 --- a/sound/pci/hda/hda_beep.h +++ b/sound/pci/hda/hda_beep.h @@ -36,6 +36,7 @@ struct hda_beep { hda_nid_t nid; unsigned int enabled:1; unsigned int linear_tone:1; /* linear tone for IDT/STAC codec */ + unsigned int playing:1; struct work_struct beep_work; /* scheduled task for beep event */ struct mutex mutex; };
Hi !
22-02-2013 16:11 Takashi Iwai tiwai@suse.de:
I own an Asus EeeBox EB1501P with an ALC662 codec and had no HDA mixer channel for the speaker beep device. After digging somewhat in the kernel source I found that I only need to add a single line in the beep_white_list in patch_realtek.c. May be this entry can be included in the mainstream drivers:
SND_PCI_QUIRK(0x1043, 0x8376, "EeePC", 1),
Could you submit a proper patch for it?
Sorry, no. Do not have the right source base for creating patches. It is just a single line to add the system ID for my EeeBox to the beep_white_list table in patch_realtek.c. Are you able to create a patch for this?
If I use echo -e "\a" in a shell or run the beep command utility the sound appears only on second and following invocations. Whenever the frequency changes with the beep command the first invocation stays silent or just produce some click due to ALSA driver power saving. On all further invocations with same frequency the requested tone is generated on external speakers. There is no difference in behavior if the commands are called in a terminal emulator or directly on a virtual text console.
Does this happen only on my machine or is this a known problem? Is there anything I can do to fix this behavior?
So, the behavior above disappears if you disable the power save?
Can't do further testing on this (see below), but it did not look to depend on the power saving feature. Power saving produces a noticeable speaker click (sic!). That click was there even on first invocation. So the speakers got turned on but no sound was produced.
Does the patch like below have any influence on the behavior?
I recreated my kernel changing several configuration parameters centering about the problem to get the IT87 hwmon module to load instead of ATK0110. Finally I managed to get this working using the kernel option acpi_enforce_resources=lax. Now *ALL* hardware devices/functions of my EeeBox 1501P seam to work correct, including fan speed control.
In addition this changed behavior of HDA Beep device. It now works correct on all invocations of beep utility. So I can't reproduce behavior. I do not know if my configuration modifications changed something or I did something wrong on my first tests. So please drop this issue request for now and just add the system ID to the beep_white_list. With this my EeeBox 1501P works fine, now!
If any trouble reappear, I will drop a new request on this. Sorry for the noise.
Thx for your assistance Harald
At Sat, 23 Feb 2013 21:01:54 +0100, Harald Becker wrote:
Hi !
22-02-2013 16:11 Takashi Iwai tiwai@suse.de:
I own an Asus EeeBox EB1501P with an ALC662 codec and had no HDA mixer channel for the speaker beep device. After digging somewhat in the kernel source I found that I only need to add a single line in the beep_white_list in patch_realtek.c. May be this entry can be included in the mainstream drivers:
SND_PCI_QUIRK(0x1043, 0x8376, "EeePC", 1),
Could you submit a proper patch for it?
Sorry, no. Do not have the right source base for creating patches. It is just a single line to add the system ID for my EeeBox to the beep_white_list table in patch_realtek.c. Are you able to create a patch for this?
OK, I added the patch now.
If I use echo -e "\a" in a shell or run the beep command utility the sound appears only on second and following invocations. Whenever the frequency changes with the beep command the first invocation stays silent or just produce some click due to ALSA driver power saving. On all further invocations with same frequency the requested tone is generated on external speakers. There is no difference in behavior if the commands are called in a terminal emulator or directly on a virtual text console.
Does this happen only on my machine or is this a known problem? Is there anything I can do to fix this behavior?
So, the behavior above disappears if you disable the power save?
Can't do further testing on this (see below), but it did not look to depend on the power saving feature. Power saving produces a noticeable speaker click (sic!). That click was there even on first invocation. So the speakers got turned on but no sound was produced.
Does the patch like below have any influence on the behavior?
I recreated my kernel changing several configuration parameters centering about the problem to get the IT87 hwmon module to load instead of ATK0110. Finally I managed to get this working using the kernel option acpi_enforce_resources=lax. Now *ALL* hardware devices/functions of my EeeBox 1501P seam to work correct, including fan speed control.
In addition this changed behavior of HDA Beep device. It now works correct on all invocations of beep utility. So I can't reproduce behavior. I do not know if my configuration modifications changed something or I did something wrong on my first tests. So please drop this issue request for now and just add the system ID to the beep_white_list. With this my EeeBox 1501P works fine, now!
If any trouble reappear, I will drop a new request on this. Sorry for the noise.
Alright. If you see a problem again, let us know.
thanks,
Takashi
Hi Takashi !
Just to inform you ...
25-02-2013 09:56 Takashi Iwai tiwai@suse.de:
If I use echo -e "\a" in a shell or run the beep command utility the sound appears only on second and following invocations. Whenever the frequency changes with the beep command the first invocation stays silent or just produce some click due to ALSA driver power saving. On all further invocations with same frequency the requested tone is generated on external speakers. There is no difference in behavior if the commands are called in a terminal emulator or directly on a virtual text console.
The problem reoccurred with kernel 3.8.2. As my box is currently very busy, I can't do rapid rebooting. As soon as this is possible, I try to create a step by step description on how to reproduce the problem.
So, the behavior above disappears if you disable the power save?
Some quick tests showed you are probably right and the problem depends on the power saving feature. Beeps are produced as long as power saving (timeout) has not occurred, and beep misses if device is in power saving mode.
As soon as my box is ready for rapid rebooting I will dig somewhat deeper into this.
-- Harald
At Tue, 5 Mar 2013 09:20:07 +0100, Harald Becker wrote:
Hi Takashi !
Just to inform you ...
25-02-2013 09:56 Takashi Iwai tiwai@suse.de:
If I use echo -e "\a" in a shell or run the beep command utility the sound appears only on second and following invocations. Whenever the frequency changes with the beep command the first invocation stays silent or just produce some click due to ALSA driver power saving. On all further invocations with same frequency the requested tone is generated on external speakers. There is no difference in behavior if the commands are called in a terminal emulator or directly on a virtual text console.
The problem reoccurred with kernel 3.8.2. As my box is currently very busy, I can't do rapid rebooting. As soon as this is possible, I try to create a step by step description on how to reproduce the problem.
So, the behavior above disappears if you disable the power save?
Some quick tests showed you are probably right and the problem depends on the power saving feature. Beeps are produced as long as power saving (timeout) has not occurred, and beep misses if device is in power saving mode.
Did you try my previous patch?
As soon as my box is ready for rapid rebooting I will dig somewhat deeper into this.
OK, thanks.
Takashi
participants (2)
-
Harald Becker
-
Takashi Iwai