Re: [2.6 patch] schedule obsolete OSS drivers for removal

2005-07-28 Thread Takashi Iwai
At Wed, 27 Jul 2005 01:38:37 +0200,
Zoran Dzelajlija wrote:
 
 Zach Brown [EMAIL PROTECTED] wrote:
  Adrian Bunk wrote:
   This patch schedules obsolete OSS drivers (with ALSA drivers that 
   support the same hardware) for removal.
 
   I've Cc'ed the people listed in MAINTAINERS as being responsible for one 
   or more of these drivers, and I've also Cc'ed the ALSA people.
 
  I haven't touched the maestro drivers in so long (for near-total lack of
  docs, etc.) that I can't be considered authoritative for approving it's
  removal. If people are relying on it I certainly don't know who they
  are.  In better news, Takashi should now have the pile of maestro
  hardware that I used in the first pass to help him maintain the ALSA
  driver..
 
 The OSS maestro driver works better on my old Armada E500 laptop.  I tried
 ALSA after switching to 2.6, but the computer hung with 2.6.8.1 or 2.6.10 if
 I touched the volume buttons.  With OSS they just work.  The four separate
 dsp devices also look kind of more useful.

The bug around h/w volume control should have been fixed in the recent
version of ALSA drivers.  Hopefully everything will get merged into
2.6.13...


Takashi
-
To unsubscribe from this list: send the line unsubscribe linux-sound in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] hda: thinkpad_helper: Add support for hid-lenovo LED control

2016-09-12 Thread Takashi Iwai
On Mon, 12 Sep 2016 12:47:03 +0200,
Dennis Wassenberg wrote:
> 
> Make the thinkpad_helper able to support not only led control over
> acpi with thinkpad_acpi driver but also led control over hid-lenovo.
> The hid-lenovo driver adapted the led control api of thinkpad_acpi.
> 
> Signed-off-by: Dennis Wassenberg 
> ---
>  sound/pci/hda/thinkpad_helper.c | 149 
> ++--
>  1 file changed, 111 insertions(+), 38 deletions(-)
> 
> diff --git a/sound/pci/hda/thinkpad_helper.c b/sound/pci/hda/thinkpad_helper.c
> index 62741a7..c24a4a9 100644
> --- a/sound/pci/hda/thinkpad_helper.c
> +++ b/sound/pci/hda/thinkpad_helper.c
> @@ -2,79 +2,152 @@
>   * to be included from codec driver
>   */
>  
> -#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
> -
> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI) || IS_ENABLED(CONFIG_HID_LENOVO)
>  #include 
> +#include 
>  #include 
>  
> -static int (*led_set_func)(int, bool);
> +static int (*led_set_func_tpacpi)(int, bool);
> +static int (*led_set_func_hid_lenovo)(int, bool);
>  static void (*old_vmaster_hook)(void *, int);
>  
>  static bool is_thinkpad(struct hda_codec *codec)
>  {
> + return (codec->core.subsystem_id >> 16 == 0x17aa);
> +}
> +
> +static bool is_thinkpad_acpi(struct hda_codec *codec)
> +{
>   return (codec->core.subsystem_id >> 16 == 0x17aa) &&
>  (acpi_dev_found("LEN0068") || acpi_dev_found("IBM0068"));
>  }
>  
> -static void update_tpacpi_mute_led(void *private_data, int enabled)
> +static void update_thinkpad_mute_led(void *private_data, int enabled)
>  {
>   if (old_vmaster_hook)
>   old_vmaster_hook(private_data, enabled);
>  
> - if (led_set_func)
> - led_set_func(TPACPI_LED_MUTE, !enabled);
> + if (led_set_func_tpacpi)
> + led_set_func_tpacpi(TPACPI_LED_MUTE, !enabled);
> +
> + if (led_set_func_hid_lenovo)
> + led_set_func_hid_lenovo(HID_LENOVO_LED_MUTE, !enabled);
>  }
>  
> -static void update_tpacpi_micmute_led(struct hda_codec *codec,
> +
> +
> +static void update_thinkpad_micmute_led(struct hda_codec *codec,
> struct snd_kcontrol *kcontrol,
> struct snd_ctl_elem_value *ucontrol)
>  {
> - if (!ucontrol || !led_set_func)
> + if (!ucontrol)
>   return;
>   if (strcmp("Capture Switch", ucontrol->id.name) == 0 && 
> ucontrol->id.index == 0) {
>   /* TODO: How do I verify if it's a mono or stereo here? */
>   bool val = ucontrol->value.integer.value[0] || 
> ucontrol->value.integer.value[1];
> - led_set_func(TPACPI_LED_MICMUTE, !val);
> + if (led_set_func_tpacpi)
> + led_set_func_tpacpi(TPACPI_LED_MICMUTE, !val);
> + if (led_set_func_hid_lenovo)
> + led_set_func_hid_lenovo(HID_LENOVO_LED_MICMUTE, !val);
>   }
>  }
>  
> -static void hda_fixup_thinkpad(struct hda_codec *codec,
> - const struct hda_fixup *fix, int action)
> +static int hda_fixup_thinkpad_acpi(struct hda_codec *codec)
>  {
>   struct hda_gen_spec *spec = codec->spec;
> - bool removefunc = false;
> + int ret = -ENXIO;
>  
> - if (action == HDA_FIXUP_ACT_PROBE) {
> - if (!is_thinkpad(codec))
> - return;
> - if (!led_set_func)
> - led_set_func = symbol_request(tpacpi_led_set);
> - if (!led_set_func) {
> - codec_warn(codec,
> -"Failed to find thinkpad-acpi symbol 
> tpacpi_led_set\n");
> - return;
> - }
> + if (!is_thinkpad(codec))
> + return -ENODEV;
> + if (!is_thinkpad_acpi(codec))
> + return -ENODEV;
> + if (!led_set_func_tpacpi)
> + led_set_func_tpacpi = symbol_request(tpacpi_led_set);

This would be performed even if CONFIG_THINKPAD_ACPI=n when
CONFIG_HID_LENOVO!=n.  You'd need to have a proper ifdef surrounding
the function.


> + if (!led_set_func_tpacpi) {
> + codec_warn(codec,
> +"Failed to find thinkpad-acpi symbol 
> tpacpi_led_set\n");
> + return -ENOENT;
> + }
>  
> - removefunc = true;
> - if (led_set_func(TPACPI_LED_MUTE, false) >= 0) {
> - old_vmaster_hook = spec->vmaster_mute.hook;
> - spec->vmaster_mute.hook = update_tpacpi_mute_led;
> - removefunc = false;
> - }
> - if (led_set_func(TPACPI_LED_MICMUTE, false) >= 0) {
> - if (spec->num_adc_nids > 1)
> - codec_dbg(codec,
> -   "Skipping micmute LED control due to 
> several ADCs");
> - else {
> - spec->cap_sync_hook = update_tpacpi_micmute_led;
> -  

Re: [alsa-devel] first and last audio sample timestamp

2018-06-25 Thread Takashi Iwai
On Fri, 22 Jun 2018 16:00:10 +0200,
Subhashini Rao Beerisetty wrote:
> 
> [ Please keep me in CC as I'm not subscribed to the list]
> 
> Hi All,
> 
> 
> 
> Hello all,
> 
> 
> I’m using aplay and arecord utilities for playback and capture. I need to
> capture the timestamps for the first and last audio samples that arrive at
> the driver level.
> 
> For this I’m capturing the CLOCK_MONOTONIC_RAW timestamp at the
> .trigger(for playback & capture) callback in SNDRV_PCM_TRIGGER_START  case
> – is it the correct timestamp for the first audio sample arrived at the
> driver level?
> 
> Similarly does .trigger callbacks SNDRV_PCM_TRIGGER_STOP gives the last
> audio sample timestamp?

No, it's the timestamp upon calling the trigger callback.
It has nothing to do directly with the first or the last sample.
(But usually the start trigger is the time of the first sample for
 capture, though.)


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [alsa-devel] first and last audio sample timestamp

2018-06-25 Thread Takashi Iwai
On Mon, 25 Jun 2018 16:58:26 +0200,
Subhashini Rao Beerisetty wrote:
> 
> On Mon, Jun 25, 2018 at 8:23 PM, Takashi Iwai  wrote:
> 
> > On Mon, 25 Jun 2018 16:50:20 +0200,
> > Subhashini Rao Beerisetty wrote:
> > >
> > > On Mon, Jun 25, 2018 at 8:04 PM, Takashi Iwai  wrote:
> > >
> > > > On Fri, 22 Jun 2018 16:00:10 +0200,
> > > > Subhashini Rao Beerisetty wrote:
> > > > >
> > > > > [ Please keep me in CC as I'm not subscribed to the list]
> > > > >
> > > > > Hi All,
> > > > >
> > > > >
> > > > >
> > > > > Hello all,
> > > > >
> > > > >
> > > > > I’m using aplay and arecord utilities for playback and capture. I
> > need to
> > > > > capture the timestamps for the first and last audio samples that
> > arrive
> > > > at
> > > > > the driver level.
> > > > >
> > > > > For this I’m capturing the CLOCK_MONOTONIC_RAW timestamp at the
> > > > > .trigger(for playback & capture) callback in SNDRV_PCM_TRIGGER_START
> > > > case
> > > > > – is it the correct timestamp for the first audio sample arrived at
> > the
> > > > > driver level?
> > > > >
> > > > > Similarly does .trigger callbacks SNDRV_PCM_TRIGGER_STOP gives the
> > last
> > > > > audio sample timestamp?
> > > >
> > > > No, it's the timestamp upon calling the trigger callback.
> > > > It has nothing to do directly with the first or the last sample.
> > > > (But usually the start trigger is the time of the first sample for
> > > >  capture, though.)
> > > >
> > >
> > > Okay then if start trigger is the time of the first sample for capture,
> > > then is stop trigger is for last sample?
> >
> > No, it's not necessarily the last sample.  It's the just time you stop
> > the stream.  The stop might happen some time after the last sample got
> > received.  The accuracy in that regard pretty much depends on the
> > hardware and the driver implementation.
> >
> Thanks for the clarification. What about for playback scenario?

A similar situation.  The timestamp at stop trigger is the time you
stopped the stream, and it's not about the "last" sample time.

BTW, for the accurate timestamping, check
Documentation/sound/design/timestamping.rst.


Takashi


> 
> 
> >
> >
> > Takashi
> >
> > > For example, i'm printing the
> > > timestamp as given below. Similarly in which call back I can use the
> > > getrawmonotonic()
> > > for playback case.
> > >
> > > static int snd_mychip_capture_trigger(struct snd_pcm_substream
> > *substream,
> > > int cmd)
> > >
> > > {
> > >
> > > struct timespec ts;
> > >
> > >
> > >
> > > switch(cmd) {
> > >
> > > case SNDRV_PCM_TRIGGER_START:
> > >
> > > getrawmonotonic();
> > >
> > > printk("1st audio sample received time:
> > > [%.6lu:%.9lu]\n",ts.tv_sec, ts.tv_nsec);
> > >
> > > break;
> > >
> > > case SNDRV_PCM_TRIGGER_STOP:
> > >
> > > getrawmonotonic();
> > >
> > > printk("Last audio sample received time:
> > > [%.6lu:%.9lu]\n",ts.tv_sec, ts.tv_nsec);
> > >
> > > break;
> > >
> > > }
> > >
> > >
> > >
> > > }
> > >
> > >
> > > >
> > > >
> > > > Takashi
> > > >
> >
> [2  ]
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ALSA: virtio: remove duplicate check if queue is broken

2024-01-24 Thread Takashi Iwai
On Wed, 24 Jan 2024 13:08:34 +0100,
Li RongQing wrote:
> 
> virtqueue_enable_cb() will call virtqueue_poll() which will check if
> queue is broken at beginning, so remove the virtqueue_is_broken() call
> 
> Signed-off-by: Li RongQing 

Applied now.  Thanks.


Takashi