Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: James Courtier-Dutton <James@superbug.demon.co.uk>
To: Takashi Iwai <tiwai@suse.de>
Cc: Jaroslav Kysela <perex@suse.cz>, p z oooo <pzad@pobox.sk>,
	alsa-devel@lists.sourceforge.net
Subject: Re: Not important oops
Date: Thu, 22 Jan 2004 00:29:44 +0000	[thread overview]
Message-ID: <400F1978.4030901@superbug.demon.co.uk> (raw)
In-Reply-To: <s5h3ca96scx.wl@alsa2.suse.de>

Takashi Iwai wrote:
> At Wed, 21 Jan 2004 19:49:39 +0100 (CET),
> Jaroslav wrote:
> 
>>On Wed, 21 Jan 2004, Takashi Iwai wrote:
>>
>>
>>>At Wed, 21 Jan 2004 13:55:53 +0100,
>>>p z oooo wrote:
>>>
>>>>Hi,
>>>>
>>>>When I remove control through hwdep layer on emu10k1 
>>>>driver when in use by oss emulation I got oops. 
>>>>This is because oss emulation holds pointer to this control.
>>>>Is there any api to disable an then enable oss emulation or 
>>>>only proc interface ???
>>>
>>>hmm weird, the access to ctl elements in mixer_oss.c is restricted
>>>with card->controls_rwsem.  since snd_emu10k1_del_controls issues
>>>down_write() for it, it must be safe...
>>
>>I think that he meant that slot->kcontrol members are not removed. 
> 
> 
> ah yes, i overlooked that.
> 
> 
>>We need probably rebuild the OSS mixer -> ALSA control connections when
>>a control - which is used with the OSS mixer code - was removed.
> 
> 
> or, store only the snd_ctl_elem_id instead of kcontrol, and retrieve
> the control at each time.  since the access to the mixer element is
> less frequent than pcm, the overhead by this won't be too much, i
> think.
> 
> but rebuilding would be better, when the mixer elements are completely
> changed and become incompatible with the old setting.
> 
> we can use notify handler for this (e.g. SND_MIXER_OSS_NOTIFY_RECONFIGURE).
> (but the caller should be blocked until the notification is processed,
>  otherwise there would be a race condition.)
> 
> 
> Takashi
> 
While you are looking at the oss emulation mixer, there is another bug 
there.

User application does VOL++.
OSS has a range from 0-100
ALSA uses hardware range of 0-31.
THus: -
OSS VOL=0
OSS VOL++
ALSA VOL stays at 0
OSS READ VOL, = 0;

It seems like to emulate OSS correctly, one needs to hold volume values 
in the OSS mixer emulation code, instead of just passing them through to 
the ALSA mixer.

Cheers
James



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

  reply	other threads:[~2004-01-22  0:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-21 12:55 Not important oops p z oooo
2004-01-21 18:40 ` Takashi Iwai
2004-01-21 18:49   ` Jaroslav Kysela
2004-01-21 18:58     ` Takashi Iwai
2004-01-22  0:29       ` James Courtier-Dutton [this message]
2004-01-22 11:41         ` Jaroslav Kysela

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=400F1978.4030901@superbug.demon.co.uk \
    --to=james@superbug.demon.co.uk \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=perex@suse.cz \
    --cc=pzad@pobox.sk \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox