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

[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

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

[Stefan Hajnoczi]

On Wed, 24 Jan 2024 at 07:17, 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 
> ---
>  sound/virtio/virtio_card.c| 2 --
>  sound/virtio/virtio_ctl_msg.c | 2 --
>  sound/virtio/virtio_pcm_msg.c | 2 --
>  3 files changed, 6 deletions(-)

Reviewed-by: Stefan Hajnoczi 

>
> diff --git a/sound/virtio/virtio_card.c b/sound/virtio/virtio_card.c
> index e2847c0..b158c3c 100644
> --- a/sound/virtio/virtio_card.c
> +++ b/sound/virtio/virtio_card.c
> @@ -91,8 +91,6 @@ static void virtsnd_event_notify_cb(struct virtqueue 
> *vqueue)
> virtsnd_event_dispatch(snd, event);
> virtsnd_event_send(vqueue, event, true, GFP_ATOMIC);
> }
> -   if (unlikely(virtqueue_is_broken(vqueue)))
> -   break;
> } while (!virtqueue_enable_cb(vqueue));
> spin_unlock_irqrestore(>lock, flags);
>  }
> diff --git a/sound/virtio/virtio_ctl_msg.c b/sound/virtio/virtio_ctl_msg.c
> index 18dc5ac..9dabea0 100644
> --- a/sound/virtio/virtio_ctl_msg.c
> +++ b/sound/virtio/virtio_ctl_msg.c
> @@ -303,8 +303,6 @@ void virtsnd_ctl_notify_cb(struct virtqueue *vqueue)
> virtqueue_disable_cb(vqueue);
> while ((msg = virtqueue_get_buf(vqueue, )))
> virtsnd_ctl_msg_complete(msg);
> -   if (unlikely(virtqueue_is_broken(vqueue)))
> -   break;
> } while (!virtqueue_enable_cb(vqueue));
> spin_unlock_irqrestore(>lock, flags);
>  }
> diff --git a/sound/virtio/virtio_pcm_msg.c b/sound/virtio/virtio_pcm_msg.c
> index 542446c..8c32efa 100644
> --- a/sound/virtio/virtio_pcm_msg.c
> +++ b/sound/virtio/virtio_pcm_msg.c
> @@ -358,8 +358,6 @@ static inline void virtsnd_pcm_notify_cb(struct 
> virtio_snd_queue *queue)
> virtqueue_disable_cb(queue->vqueue);
> while ((msg = virtqueue_get_buf(queue->vqueue, 
> _bytes)))
> virtsnd_pcm_msg_complete(msg, written_bytes);
> -   if (unlikely(virtqueue_is_broken(queue->vqueue)))
> -   break;
> } while (!virtqueue_enable_cb(queue->vqueue));
> spin_unlock_irqrestore(>lock, flags);
>  }
> --
> 2.9.4
>
>

Re: Microphone volume low on linux driver

[Eric Curtin]

*the Windows driver

On Fri, 19 Apr 2019 at 14:17, Eric Curtin  wrote:
>
> Hi Guys,
>
> I have a headset, Linux recognizes it as "HyperX Virtual Surround Sound
> Digital Stereo", I have it set to 150% recording volume. It's a "HyperX
> Cloud II" headset, the Windows seems to work fine. I also tried
> "Digital Stereo (IEC958) Input" mode.
>
> Is there a quirk or similar in the kernel I can set in order to
> increase the recording volume of this device specifically?
>
> Some details about my system (it's xubuntu):
>
> username@hp-zbook-15-g5 14:13:12
> ~/>dpkg -l | grep -i pulseaud
> ii  gstreamer1.0-pulseaudio:amd64
> 1.14.1-1ubuntu1~ubuntu18.04.1
>  amd64GStreamer plugin for PulseAudio
> ii  libcanberra-pulse:amd64   0.30-5ubuntu1
>amd64
> PulseAudio backend for libcanberra
> ii  libpulse-mainloop-glib0:amd64 1:11.1-1ubuntu7.2
>amd64
> PulseAudio client libraries (glib support)
> ii  libpulse0:amd64   1:11.1-1ubuntu7.2
>amd64
> PulseAudio client libraries
> rc  libpulse0:i3861:11.1-1ubuntu7.2
>i386
> PulseAudio client libraries
> ii  libpulsedsp:amd64 1:11.1-1ubuntu7.2
>amd64
> PulseAudio OSS pre-load library
> ii  pavucontrol   3.0-4
>amd64
> PulseAudio Volume Control
> ii  pulseaudio1:11.1-1ubuntu7.2
>amd64
> PulseAudio sound server
> ii  pulseaudio-module-bluetooth   1:11.1-1ubuntu7.2
>amd64
> Bluetooth module for PulseAudio sound server
> ii  pulseaudio-utils  1:11.1-1ubuntu7.2
>amd64
> Command line tools for the PulseAudio sound server
> ii  xfce4-pulseaudio-plugin:amd64 0.4.1-0ubuntu1
>amd64
> Xfce4 panel plugin to control pulseaudio
> username@hp-zbook-15-g5 14:13:15
> ~/git/Domino>lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 18.04.2 LTS
> Release: 18.04
> Codename: bionic
> username@hp-zbook-15-g5 14:13:20
> ~/git/Domino>uname -a
> Linux hp-zbook-15-g5 4.18.0-17-generic #18~18.04.1-Ubuntu SMP Fri Mar
> 15 15:27:12 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
>
> Regards,
>
> Eric

Re: [PATCH 0/4] Introduce the aural error reporting framework

[Thomas Gleixner]

Matteo,

On Tue, 2 Apr 2019, Matteo Croce wrote:
> On Tue, Apr 2, 2019 at 11:33 AM Thomas Gleixner  wrote:
> > Aside of that, where is the android-app to customize and decode the
> > melodies?
> >
> > I surely want to have the music theme of 'Once Upon a Time in the West' on
> > kernel crashes.
> 
> I'm a little rusty with Android programming, so I'll share the script
> I use to convert notes to frequences.
> With some awk magic it can turn notes into a C array, I hope that you
> find it useful.

That's great. Just a few nitpicks on the patches themself. You want to
change msleep() to mdelay() in order to avoid "Scheduling while atomic"
noise and you want to have global serialization because interleaving "La
Paloma" from CPU1 and "Once Upon a Time in the West" from CPU2 sounds
really horrible.

Thanks,

tglx

Re: [PATCH 0/4] Introduce the aural error reporting framework

[Matteo Croce]

On Tue, Apr 2, 2019 at 11:33 AM Thomas Gleixner  wrote:
>
> On Mon, 1 Apr 2019, Peter Zijlstra wrote:
> > On Mon, Apr 01, 2019 at 12:24:51PM +0200, Matteo Croce wrote:
> > > The buzzer driver is simple, requires just a few register writes to work,
> > > the hardware is extremely cheap and is already present on most machines.
> >
> > What, no morse-code register dumps?
>
> Aside of that, where is the android-app to customize and decode the
> melodies?
>
> I surely want to have the music theme of 'Once Upon a Time in the West' on
> kernel crashes.
>
> Thanks,
>
> tglx
>

Hi Thomas,

I'm a little rusty with Android programming, so I'll share the script
I use to convert notes to frequences.
With some awk magic it can turn notes into a C array, I hope that you
find it useful.

Bye,
-- 
Matteo Croce
per aspera ad upstream


notes2freq.sh
Description: application/shellscript

Re: [PATCH 0/4] Introduce the aural error reporting framework

[Thomas Gleixner]

On Mon, 1 Apr 2019, Peter Zijlstra wrote:
> On Mon, Apr 01, 2019 at 12:24:51PM +0200, Matteo Croce wrote:
> > The buzzer driver is simple, requires just a few register writes to work,
> > the hardware is extremely cheap and is already present on most machines.
> 
> What, no morse-code register dumps?

Aside of that, where is the android-app to customize and decode the
melodies?

I surely want to have the music theme of 'Once Upon a Time in the West' on
kernel crashes.

Thanks,

tglx

Re: [PATCH 0/4] Introduce the aural error reporting framework

[Peter Zijlstra]

On Mon, Apr 01, 2019 at 12:24:51PM +0200, Matteo Croce wrote:
> The buzzer driver is simple, requires just a few register writes to work,
> the hardware is extremely cheap and is already present on most machines.

What, no morse-code register dumps?

Re: Grant

[M. M. Fridman]

--
I, Mikhail Fridman have selected you specifically as one of my 
beneficiaries for my Charitable Donation of $5 Million Dollars,


Check the link below for confirmation:

https://www.rt.com/business/343781-mikhail-fridman-will-charity/

I await your earliest response for further directives.

Best Regards,
Mikhail Fridman.

Re: ~100 seconds(!) load time of snd-usb-audio

[Ran Shalit]

On Mon, Aug 20, 2018 at 8:59 AM Ran Shalit  wrote:
>
> Hello,
>
> We encounter the following strange behavior, and struggle with it for
> couple of days now. I hope someone can suggest how to handle it.
>
> 1. We have a sound card, which takes ~100seconds(!) till it finishes
> loading of snd-usb-audio module.
> please see log here:
> https://pastebin.com/raw/BbNgUvLw
> As you can see the last line " usbcore: registered new interface
> driver snd-usb-audio" is printed ~100 seconds after the card is
> detected.
> 2. Testing other sound cards in same system, shows normal behavior.

A little update, we haven't tested this yet, so it's not correct. We
just saw on similar hw/kernel that there is no issue, but haven't test
it yet on the problematic system.
So this section should be ignored.

> 3. Surprisingly, testing same sound card with another distribution
> (ubuntu) shows no such behavior, and things are immediate.
> 4. We already tried several kernels and see the same behavior in all
> the tested kernels 3.18.11, 4.0.8 , 4.4.98.
> 5. I did find similar issues described here, but no resolve is given:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1537465
>
> I would appreciate any suggestion,

Is there a way to debug the reason for snd-usb-audio waiting time ?

> ranran

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

[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: [alsa-devel] first and last audio sample timestamp

[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: audio samples data flow from user mode to kernel mode

[priyaranjan]

Hi Subhashini,

On Sat, Jun 23, 2018 at 4:22 PM, Subhashini Rao Beerisetty
 wrote:
> Hello All,
>
>
>
> I’m trying to understand how audio samples transferred between user mode to
> kernel mode during playback and capture. I’m using aplay & arecord alsa
> utilities for playback and capture.
>
>
>
> Let us take a PCM wav file of sample rate 48000 and it has a total number of
> samples 48 (Approx.Duration in seconds=10). Size of each sample is 8
> bytes(two channels). After invocation of aplay from user mode, how does
> these audio samples gets copied to kernel mode? Can someone explain me on
> this?
>

Usually this is done in corresponding sound/alsa device driver.
The alsa driver should populate the following structure :-

struct snd_pcm_substream {
struct snd_pcm *pcm;
struct snd_pcm_str *pstr;
void *private_data; /* copied from pcm->private_data */
int number;
char name[32]; /* substream name */
int stream; /* stream (direction) */
struct pm_qos_request latency_pm_qos_req; /* pm_qos request */
size_t buffer_bytes_max; /* limit ring buffer size */
struct snd_dma_buffer dma_buffer;
size_t dma_max;
/* -- hardware operations -- */
const struct snd_pcm_ops *ops;

Here, you can find the dma_buffer where you have to populate the
destination(kernel buffer)
I would suggest please have a look at Alsa driver documentation for
further details.
There are lot of important parameters which defines how the copy will
happen from
user-space to kernel space - like period size, period count etc. Also
look at important
functions - snd_pcm_period_elapsed etc

>
>
> Is it possible to capture the timestamps for the first and last audio
> samples that arrive at the driver level?
>
>
>
> Can I consider the .trigger(for playback & capture) callback in
> SNDRV_PCM_TRIGGER_START  case is timestamp for the first audio sample?
>
>
>
> Similarly does .trigger callbacks SNDRV_PCM_TRIGGER_STOP gives the last
> audio sample timestamp?
>
>
>
> Thanks,
>
>
> ___
> Kernelnewbies mailing list
> kernelnewb...@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
--
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: audio samples data flow from user mode to kernel mode

[o]

23.06.2018, 14:52, "Subhashini Rao Beerisetty" :
> Hello All,

Hello,


> I’m trying to understand how audio samples transferred between user mode to 
> kernel mode during playback and capture. I’m using aplay & arecord alsa 
> utilities for playback and capture.
>
> Let us take a PCM wav file of sample rate 48000 and it has a total number of 
> samples 48 (Approx.Duration in seconds=10). Size of each sample is 8 
> bytes(two channels). After invocation of aplay from user mode, how does these 
> audio samples gets copied to kernel mode? Can someone explain me on this?
>
> Is it possible to capture the timestamps for the first and last audio samples 
> that arrive at the driver level?
>
> Can I consider the .trigger(for playback & capture) callback in 
> SNDRV_PCM_TRIGGER_START  case is timestamp for the first audio sample?
>
> Similarly does .trigger callbacks SNDRV_PCM_TRIGGER_STOP gives the last audio 
> sample timestamp?

I think no, because the SNDRV_PCM_TRIGGER_START and SNDRV_PCM_TRIGGER_STOP 
functions only system call to the PCM transmitted.
So, will want two different functions as playback / capture and the method 
depends on you use alsa or pulse.

I think you want to:

snd_mychip_playback_open
snd_mychip_playback_close

snd_mychip_capture_open
snd_mychip_capture_close

Trigger funcs times are not real playback or capture time-stamps.

Regards

Ozgur

> Thanks,
--
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: Grant

[Maratovich M. Fridman]

--
I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to give
my fortune as charity.

Check the link below for confirmation:

http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604

Reply as soon as possible with further directives.

Best Regards,
Mikhail Fridman.
--
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: Grant

[Maratovich M. Fridman]

--
I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to give
my fortune as charity.

Check the link below for confirmation:

http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604

Reply as soon as possible with further directives.

Best Regards,
Mikhail Fridman.
--
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] sound: ALSA PCM Timestamps

[Pierre-Louis Bossart]

On 5/23/18 8:00 AM, Muni Sekhar wrote:

[ Please keep me in CC as I'm not subscribed to the list]

Hi All,

There are several time stamping functions in ALSA:


snd_pcm_status_get_trigger_tstamp

snd_pcm_status_get_trigger_htstamp

snd_pcm_status_get_tstamp

snd_pcm_status_get_htstamp

snd_pcm_status_get_audio_htstamp

snd_pcm_status_get_driver_htstamp


the *_tstamp functions work with a 'struct timeval' which provides 
microsecond resolution.
The *_stamp functions work with a 'struct timespec' which provides 
nanosecond resolution.


The trigger_*tstamp returns the time when the stream started (typically 
when the DMA starts).
The get_tstamp returns the current timestamp measured with the regular 
timekeeping functions, which by subtracting the trigger timestamp 
provides the elapsed time since the start. You can specify if you want 
the REALTIME/MONOTONIC/MONOTONIC_RAW timestamp type, depending on your 
application.
The audio timestamp returns the current timestamp but measured using 
audio-specific counters. If the audio clocks are not aligned with the 
system time (e.g. if they use different oscillators or the audio clock 
source is external), there will be a drift between audio timestamps and 
system timestamp.







I would like to understand what points in time the resulting functions
represent and what is the corresponding kernel mode callback for those
API’s.


I'd be really grateful if someone took the time to help me clearing my doubt.





--
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: sound: latency and synchronization measurements

[Muni Sekhar]

On Fri, May 18, 2018 at 6:42 PM, Greg KH  wrote:
> On Fri, May 18, 2018 at 06:07:29PM +0530, Muni Sekhar wrote:
>> [ Please keep me in CC as I'm not subscribed to the list]
>>
>> Hi All,
>>
>> I am trying to characterize the audio synchronization between two
>> systems. There is a mechanism to route audio between two systems, we
>> run ‘aplay’ at one system and ‘arecord’ in other system.
>>
>> We need to measure the time difference when audio sample is out at one
>> port and arriving at another port in different system.
>>
>> I plan to add printk’s in “struct snd_pcm_ops” call backs, but does
>> these call backs tells when it received first and last audio
>> frames\samples?
>>
>> Or else please suggest any other best method.
>
> First off you need a "shared timer/clock" between the two systems in
> order to have a chance to determine what actually happens here.  Good
> luck with that!  :)
Yes, we do have the shared clock.

>
> Also, there's been tons of research in this area over the years, please
> look into that, odds are these problems have been solved already.  I
> know of several commercial devices that already handle this just fine.
>
Can you point me some information on this.


> best of luck!
>
> greg k-h



-- 
Thanks,
Sekhar
--
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: sound: latency and synchronization measurements

[Muni Sekhar]

On Fri, May 18, 2018 at 6:53 PM, Aris Aris  wrote:
> Hi,
>
> You could try bitbanging any availiable peripheral(i.e gpio) from each
> system at the callbacks and have a logic analyzer measuring and reporting
> time delay.
Thank you very much Aris for this information.
I am fairly new to sound sub system, I’m glad if you can point me on
the callbacks.

Does the sound driver will be notified aplay\arecord open via
“snd_xxx_open(struct snd_pcm_substeam *substream)” callback?
Which callbacks of sound driver will tell when it received first and
last audio frames\samples?


>
> Best regards,
>
> Aris
>
> On Fri, May 18, 2018 at 3:37 PM, Muni Sekhar 
> wrote:
>>
>> [ Please keep me in CC as I'm not subscribed to the list]
>>
>> Hi All,
>>
>> I am trying to characterize the audio synchronization between two
>> systems. There is a mechanism to route audio between two systems, we
>> run ‘aplay’ at one system and ‘arecord’ in other system.
>>
>> We need to measure the time difference when audio sample is out at one
>> port and arriving at another port in different system.
>>
>> I plan to add printk’s in “struct snd_pcm_ops” call backs, but does
>> these call backs tells when it received first and last audio
>> frames\samples?
>>
>> Or else please suggest any other best method.
>>
>>
>> --
>> Thanks,
>> Sekhar
>>
>> ___
>> Kernelnewbies mailing list
>> kernelnewb...@kernelnewbies.org
>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>



-- 
Thanks,
Sekhar
--
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: Donation

[M. M. Fridman]

I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to give
my fortune as charity.

Check the link below for confirmation:

http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604

Reply as soon as possible with further directives.

Best Regards,
Mikhail Fridman.
--
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] pulseaudio\aplay\arecord

[Sriram Periyasamy]

On Tue, Mar 20, 2018 at 06:42:04PM +0530, Muni Sekhar wrote:
> [ Please keep me in CC as I'm not subscribed to the list]
> 
> Hi All,
> 
> 
> 
> We are using the Ubuntu 16.04.3 LTS (4.4.0-28-generic) kernel. I’ve a
> sound card hardware which supports analog loopback. During analog
> loopback test, aplay fails with
> “aplay: pcm_write:1940: write error: Input/output error”.
> 
> In our system, I noticed that once the sound driver is loaded,
> PulseAudio daemon autospawns and taking over control of the sound
> device. Does the ‘pulseaudio’ causes ‘aplay’ failure?

No, it doesn't in your scenario. Until pulseaudio opens the device
and writes samples to it, you can use aplay. You may have to debug
the data flow in your loopback device to fix your issue.

> 
> Can we use aplay\arecord if already pulseaudio daemon is running?

Yes, you can use until any sound application triggers pulseaudio to
start using the device.

Thanks,
Sriram.
> 
> 
> 
> -- 
> Thanks,
> Sekhar
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
--
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] aplay\arecord compare utility

[Ricard Wanderlof]

On Fri, 23 Feb 2018, Muni Sekhar wrote:

>  [ Please keep me in CC as I'm not subscribed to the list]
> 
> I?m using an alsa utilities(aplay & arecord) for sound loopback
> testing. From Linux host , sending & receiving the wav file.
> 
> At end I want to compare the sent & received wav file. Does Linux has
> any utility to support this one?

If the wav headers are identical, you can just use cmp or diff. Otherwise, 
you can extract the raw audio using sox, which gives you files with just 
the audio samples in them, and then you can use cmp or diff to compare 
them. It won't work though if the files aren't actually identical, for 
instance if there is an offset of a couple of samples in one compared to 
the other.

If I had to compare two wav files which were offset by a small number of 
samples, I'd open them in Audacity, manually align them, then sum the 
result, write to a new file and verify that the file just contained zeros.

/Ricard
-- 
Ricard Wolf Wanderlöf   ricardw(at)axis.com
Axis Communications AB, Lund, Swedenwww.axis.com
Phone +46 46 272 2016   Fax +46 46 13 61 30
--
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: Distress Call Please don't ignore

[Sandra Younes]

Good Day,

Forgive my indignation if this message comes to you as a surprise and may 
offend your personality for contacting you without your prior consent and 
writing through this channel.

I came across your name and contact on the course of my personal searching when 
i was searching for a foreign reliable partner. I was assured of your 
capability and reliability after going true your profile.

I'm (Miss. Sandra) from Benghazi libya, My father of blessed memory by name 
late General Abdel Fattah Younes who was shot death by Islamist-linked militia 
within the anti-Gaddafi forces on 28th July, 2011 and after two days later my 
mother with my two brothers was killed one early morning by the rebels as 
result of civil war that is going on in my country Libya, then after the burial 
of my parents, my uncles conspired and sold my father's properties and left 
nothing for me. On a faithful morning, I opened my father's briefcase and 
discover a document which he has deposited ($6.250M USD) in a bank in a Turkish 
Bank which has a small branch in Canada with my name as the legitimate/next of 
kin. Meanwhile i have located the bank,and have also discussed the possiblity 
of transfering the fund. My father left a clause to the bank that i must 
introduce a trusted foreign partner who would be my trustee to help me invest 
this fund; hence the need for your assistance,i request that you be my t
rustee and assist me in e

You will also be responsible for the investment and management of the fund for 
me and also you will help me get a good school where i will further my 
education.
I agreed to give you 40% of the $6.250M once the transfer is done. this is my 
true life story, I will be glad to receive your respond soonest for more 
details to enable us start and champion the transfer less than 14 banking days 
as i was informed by the bank manager.

Thanks for giving me your attention,

Yours sincerely,
Miss. Sandra Younes
--
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: Grant -> Reply To fmayrhoferfam...@gmail.com

[The Mayrhofer's]

--
Good Day,

My wife and I have awarded you with a donation of $ 1,000,000.00  
Dollars from part of our Jackpot Lottery of 50 Million Dollars,  
respond with your details for claims to our private email on:  
fmayrhoferfam...@gmail.com .


We await your earliest response and God Bless you.

Friedrich And Annand Mayrhofer.
Private Email: fmayrhoferfam...@gmail.com

--
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:

[H.A]

With profound love in my heart, I Kindly Oblige your interest to very important 
proposal.. It is Truly Divine and require your utmost attention..

S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je 
velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost.

  Kontaktujte me prímo pres: helenarobert...@gmail.com pro úplné 
podrobnosti.complete.


HELINA .A ROBERTS

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
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 2/4] hid-lenovo: Add support for X1 Tablet cover LED control

[Dennis Wassenberg]

Hi Jiri,

Thanks for your comments. I added comments in-lined.

Best regards,

Dennis

On 19.12.2016 10:54, Jiri Kosina wrote:
> Hi Dennis,
> 
> thanks a lot for the patch.
> 
> On Fri, 9 Dec 2016, Dennis Wassenberg wrote:
> 
>> +int hid_lenovo_led_set(enum hid_lenovo_led_type led, bool on)
>> +{
>> +struct led_classdev *dev = NULL;
>> +struct lenovo_led_list_entry *entry;
>> +
>> +if (led >= HID_LENOVO_LED_MAX)
>> +return -EINVAL;
>> +
>> +hid_lenovo_initial_leds[led] = on ? LED_FULL : LED_OFF;
>> +
>> +list_for_each_entry(entry, _lenovo_leds, list) {
>> +if (entry->type == led) {
>> +dev = entry->dev;
>> +break;
>> +}
>> +}
> 
> How exactly is this synchronized against lenovo_remove_tpx1cover()?
> 
In case of that the tpx1cover is disconnected it will be removed from 
hid_lenovo_leds list. That means not included at the hid_lenovo_leds list. In 
this case dev is still NULL and the function will return -ENODEV. The static 
array hid_lenovo_initial_leds is still set to store the current state of a LED 
type. This is used to set the LED appropriately if the tpx1cover is replugged.

Maybe I should add a mutex to protect the hid_lenovo_leds list operations in 
hid-lenovo.c to fix the case if a unplug occurred concurrently to setting an 
led?!

>> +
>> +if (!dev)
>> +return -ENODEV;
>> +
>> +if (!dev->brightness_set)
>> +return -ENODEV;
>> +
>> +dev->brightness_set(dev, on ? LED_FULL : LED_OFF);
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(hid_lenovo_led_set);
> 
> Does this really need to be exported to the whole universe? (I guess this 
> will be further discussed in 4/4).

No, it is sufficient if thinkpad-helper can access it.
> 
--
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 4/4] hda: thinkpad_helper: Add support for hid-lenovo LED control

[Dennis Wassenberg]

Hi Jiri,

"led_set_func_hid_lenovo" is set to "hid_lenovo_led_set"

+#if IS_ENABLED(CONFIG_HID_LENOVO)
+static int hda_fixup_thinkpad_hid_prepare(struct hda_codec *codec)
+{
+   struct hda_gen_spec *spec = codec->spec;
+   int ret = 0;
+
+   if (!is_thinkpad(codec))
+   return -ENODEV;
+   if (!led_set_func_hid_lenovo)
+   led_set_func_hid_lenovo = symbol_request(hid_lenovo_led_set);

"hid_lenovo_led_set" is introduced in "[PATCH v2 2/2] hda: thinkpad_helper: Add 
support for hid-lenovo LED control". This means that "[PATCH 4/4] hda: 
thinkpad_helper: Add support for hid-lenovo LED control" can only work with 
applied "[PATCH 1/4] hid-lenovo: Add support for X1 Tablet cover special keys" 
and "[PATCH v2 2/2] hda: thinkpad_helper: Add support for hid-lenovo LED 
control".

Best regards,

Dennis
On 19.12.2016 11:09, Jiri Kosina wrote:
> On Fri, 9 Dec 2016, Dennis Wassenberg wrote:
> 
>> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
>> +if (led_set_func_tpacpi)
>> +led_set_func_tpacpi(TPACPI_LED_MUTE, !enabled);
>> +#endif
>> +#if IS_ENABLED(CONFIG_HID_LENOVO)
>> +if (led_set_func_hid_lenovo)
>> +led_set_func_hid_lenovo(HID_LENOVO_LED_MUTE, !enabled);
> 
> Where does led_set_func_hid_lenovo() come from? I don't see it in Linus' 
> tree as of today. Is that something else than tpacpi_led_set()?
> 
> Thanks,
> 
--
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 4/4] hda: thinkpad_helper: Add support for hid-lenovo LED control

[Jiri Kosina]

On Fri, 9 Dec 2016, Dennis Wassenberg wrote:

> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
> + if (led_set_func_tpacpi)
> + led_set_func_tpacpi(TPACPI_LED_MUTE, !enabled);
> +#endif
> +#if IS_ENABLED(CONFIG_HID_LENOVO)
> + if (led_set_func_hid_lenovo)
> + led_set_func_hid_lenovo(HID_LENOVO_LED_MUTE, !enabled);

Where does led_set_func_hid_lenovo() come from? I don't see it in Linus' 
tree as of today. Is that something else than tpacpi_led_set()?

Thanks,

-- 
Jiri Kosina
SUSE Labs

--
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 4/4] hda: thinkpad_helper: Add support for hid-lenovo LED control

[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: [2.6 patch] schedule obsolete OSS drivers for removal (version 2)

[Adrian Bunk]

On Tue, Aug 09, 2005 at 01:13:51PM -0400, Lee Revell wrote:
 On Fri, 2005-07-29 at 17:32 +0200, Adrian Bunk wrote:
  This patch schedules obsolete OSS drivers (with ALSA drivers that 
  support the same hardware) for removal.
  
  Scheduling the via82cxxx driver for removal was ACK'ed by Jeff Garzik.
  
 
 Someone on linux-audio-user just pointed out that the OSS USB audio and
 midi modules were never deprecated, much less scheduled to be removed.
 
 Maybe the best way to deprecate them is to move them to Sound - OSS,
 that's where they belong anyway.

I'd deprecate them without moving them.

I'll send a patch unless someone tells that any functionality of these 
drivers is lacking in ALSA.

 Lee

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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: [Alsa-devel] Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Andrew Haninger]

On 7/31/05, Adrian Bunk [EMAIL PROTECTED] wrote:
 Can you send me the bug numbers in the ALSA bug tracking system if you
 have to send bug reports, so that I can track when these issues will be
 resolved?
Thorsten: Please remember to include the list(s) when emailing those
links/numbers. I'd like to be able to watch it, too, and add any
information that I can, rather than entering a duplicate bug.

Thanks.

-Andy
-
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: [Alsa-devel] Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Thorsten Knabe]

On Mon, 1 Aug 2005, Andrew Haninger wrote:


Thorsten: Please remember to include the list(s) when emailing those
links/numbers. I'd like to be able to watch it, too, and add any
information that I can, rather than entering a duplicate bug.


Hello.

I have taken a closer look at the ALSA AD1816 sound driver during the last 
weekend. Here are my findings:


On vanilla Linux 2.6.12.3 and 2.6.13-rc4 modprobe hangs in D-state when 
loading the snd-ad1816a module. No messages have been logged to the syslog 
and the system is otherwise stable. Of course the sound card is unusable.
On Linux 2.6.8 (as shipped with current Debian Sarge), vanilla Linux 
2.6.10 and Linux 2.6.11.12 the module loads fine.


I have done some tests with xmms(Debian), kphone(VoIP-Phone/Debian) and 
iaxcomm(VoIP-Phone/self-made). Audio playback with xmms is always fine 
using either ALSA or OSS emulation. Using OSS emulation with one of the 
VoIP phones, playback and recording stop a few seconds after the call is 
started. Using the ALSA interface with kphone works, but there is a 
continuous clicking approximately 3 times per second. Also audio latency 
is poor compared to the OSS driver. iaxcomm does not support the ALSA 
audio interface, thus no problems here. :-)

The native OSS driver is fine on all kernels with all tested applications.

Also the ALSA driver does not have an equivalent for the 
ad1816_clockfreq option of the OSS driver. The AD1816 chip requires a 
33MHz reference clock, however some cards use a different (mostly 
32.125MHz) clock, thus the audio sample rate has to be corrected before it 
is written to the hardware registers for proper playback and recording 
speed.


I have not filed any bug reports to the ALSA bug tracking system so far, 
but will do so tomorrow and add the corresponding bug numbers to this 
thread.


Thorsten

--
___
 || / E-Mail: [EMAIL PROTECTED]
 |horsten |/\nabeWWW: http://linux.thorsten-knabe.de
-
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: [2.6 patch] schedule obsolete OSS drivers for removal

[Adrian Bunk]

On Wed, Jul 27, 2005 at 01:38:37AM +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.

I've left it on the list of OSS drivers scheduled for removal based on 
Takashi's comment that the volume button problem should be fixed now.

If this problem is still present in 2.6.13-rc4, please open a bug at the 
ALSA bug tracking system [1] and tell me the bug number so that I can 
track it.

 Zoran

cu
Adrian

[1] https://bugtrack.alsa-project.org/alsa-bug/

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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: [Alsa-devel] Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Jaroslav Kysela]

On Thu, 28 Jul 2005, Thorsten Knabe wrote:

 On Tue, 26 Jul 2005, Adrian Bunk wrote:
 
  This patch schedules obsolete OSS drivers (with ALSA drivers that
  support the same hardware) for removal.
 
 Hello Adrian.
 
 I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two 
 problems of the ALSA AD1816 driver, that do not show up with the OSS 
 driver:
 - According to my own experience and user reports audio is choppy with 
   some VoIP Softphones like gnophone at least when used with the ALSA 
   OSS emulation layer, whereas the OSS driver is crystal clear.
 - Users reported, that on some HP Kayak systems the on-board AD1816A was 
   not properly detected by the ALSA driver or was detected, but there 
   was no audio output. I'm not sure if the problem is still present in 
   the current ALSA driver, as I do not own such a system.
 
 Maybe the OSS driver should stay in the kernel, until those problems are 
 fixed in the ALSA driver.

The problem is that nobody reported us mentioned problems. We have no 
bug-report regarding the AD1816A driver. Perhaps, it would be a good idea 
to add a notice to the help file and/or driver that the ALSA driver should 
be tested and bugs reported to the ALSA bug-tracking-system.

Thanks,
Jaroslav

-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
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: [2.6 patch] schedule obsolete OSS drivers for removal

[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: [2.6 patch] schedule obsolete OSS drivers for removal

[Alan Cox]

On Mer, 2005-07-27 at 16:43 -0400, Jeff Garzik wrote:
 ISTR Alan saying there was some ALi hardware that either wasn't in ALSA, 
 or most likely didn't work in ALSA.  If Alan says I'm smoking crack, 
 then you all can ignore me :)

The only big thing I know that still needed OSS (and may still do so) is
the support for AC97 wired touchscreens and the like. Has that been
ported to ALSA ?

-
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: [2.6 patch] schedule obsolete OSS drivers for removal

[Jaroslav Kysela]

On Thu, 28 Jul 2005, Alan Cox wrote:

 On Mer, 2005-07-27 at 16:43 -0400, Jeff Garzik wrote:
  ISTR Alan saying there was some ALi hardware that either wasn't in ALSA, 
  or most likely didn't work in ALSA.  If Alan says I'm smoking crack, 
  then you all can ignore me :)
 
 The only big thing I know that still needed OSS (and may still do so) is
 the support for AC97 wired touchscreens and the like. Has that been
 ported to ALSA ?

We're working on this issue right now.

Jaroslav

-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
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: [2.6 patch] schedule obsolete OSS drivers for removal

[Zoran Dzelajlija]

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.

Zoran

-
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: [2.6 patch] schedule obsolete OSS drivers for removal

[Adrian Bunk]

On Tue, Jul 26, 2005 at 11:57:04AM -0400, Jeff Garzik wrote:
 Lee Revell wrote:
 On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote:
 
 This patch schedules obsolete OSS drivers (with ALSA drivers that 
 support the same hardware) for removal.
 
 
 How many non-obsolete OSS drivers were there?
 
 someone needs to test the remaining PCI ID(s) that are in i810_audio but 
 not ALSA.

I've grep'ed a second time for every single PCI ID in the OSS 
i810_audio, and I still haven't found WTF you are talking about.

Once again my question:

I though I found every single PCI ID from this driver in ALSA.
Which PCI IDs did I miss?

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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: [2.6 patch] schedule obsolete OSS drivers for removal

[John W. Linville]

On Wed, Jul 27, 2005 at 08:24:28PM +0200, Adrian Bunk wrote:

 I've grep'ed a second time for every single PCI ID in the OSS 
 i810_audio, and I still haven't found WTF you are talking about.

I looked as well, and I found nothing either.

Jeff, can you enlighten us?

John
-- 
John W. Linville
[EMAIL PROTECTED]
-
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: [2.6 patch] schedule obsolete OSS drivers for removal

[Rogério Brito]

On Jul 27 2005, Lee Revell wrote:
 On Wed, 2005-07-27 at 01:38 +0200, Zoran Dzelajlija wrote:
  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.
 
 Please test a newer ALSA version, like the one in 2.6.12.

I have an Armada V300 laptop that uses the maestro2 chipset (and I
wouldn't be surprised if your E500 used that very same chip) and it
works fine with the ALSA provided in kernels since the 2.6.10-mm era
(actually, I think it worked fine with even earlier kernels, but I am
not sure).


Just another datapoint, Rogério.

-- 
Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
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: [2.6 patch] schedule obsolete OSS drivers for removal

[Andrew Haninger]

On 7/26/05, Adrian Bunk [EMAIL PROTECTED] wrote:
  config SOUND_OPL3SA2
 tristate Yamaha OPL3-SA2 and SA3 based PnP cards
 -   depends on SOUND_OSS
 +   depends on SOUND_OSS  OBSOLETE_OSS_DRIVER
 help
   Say Y or M if you have a card based on one of these Yamaha sound
   chipsets or the SAx, which is actually a SA3. Read
Forgive me if I'm misreading this (I'm hardly a coder and no kernel
hacker) but, as it stands, the OPL3SA2 driver provided by ALSA and the
main kernel tree work but are not correctly detected by ALSA's
detection routines (in alsaconf) on the 2.6 kernel. The OSS drivers
work, as well, but (AFAIK) there are no methods of automatic
configuration with the OSS drivers.

So, for people who don't feel like configuring ALSA with their OPL3SA2
card, the OSS modules may be easier to configure and thus should be
left in until the ALSA/2.6 kernel problems are worked out with the
OPL3SA2.

-Andy
-
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: [2.6 patch] schedule obsolete OSS drivers for removal

[Zach Brown]

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..

- z
-
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: [2.6 patch] schedule obsolete OSS drivers for removal

[Krzysztof Halasa]

Zach Brown [EMAIL PROTECTED] writes:

 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.

Maestro3 ALSA does work fine for me.
-- 
Krzysztof Halasa
-
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