Re: [GnomeMeeting-list] [PATCH] No audio feedback in 0.98 config druid!!!

[Christopher Warner <zanee kernelcode com>]

On Sun, 2003-09-07 at 17:40, Chris Rankin wrote:
>  --- Christopher Warner <zanee kernelcode com> wrote:
> > > d) The OSS interface was adjusting the completely
> > > wrong mixer device anyway. The correct one was
> > > actually "AC97 Capture", not "MIC".
> > 
> > Which is incorrect.. "AC97 Capture" is Alsa..
> > Earlier you mentioned you had an SBLive card using
> > OSS emulation mode. Obviously that's not the
> > case, if AC97 was the correct interface. Siply
> > because it's not an OSS interface. So in all reality
> > it was adjusting the right interface and before you
> > test you can make sure that devices and interfaces
> > are set correctly.
> 
> <Extreme Patience Mode>
> Yes, "AC97 Capture" is an ALSA mixer device. The OSS
> emulation layer works by mapping these ALSA devices to
> their OSS equivalents, so that there is an effective
> OSS "MIC" setting available. And not unreasonably,
> this maps to the ALSA "MIC" device. So when
> gnomemeeting ramps the OSS "MIC" to 100, it *really*
> sets the ALSA "MIC" to 100 instead. However, this is
> the *wrong* ALSA mixer device to use. Under ALSA (with
> the SB Live! anyway), it is best to leave the "MIC"
> device muted and push the "AC97 Capture" to 100
> instead. Unfortunately, the "AC97 Capture" has no OSS
> equivalent.
> 
Did you read what I said? Let me quote for you 
Quote: 
"Which is incorrect.. "AC97 Capture" is Alsa..
> > Earlier you mentioned you had an SBLive card using
> > OSS emulation mode. Obviously that's not the
> > case, if AC97 was the correct interface. Siply
> > because it's not an OSS interface"
Unquote. What's your point? Why are you basically repeating what I said?

> Yes, I know that you can't possibly cater for every
> conceivable mixer device mapping, some of which may or
> may not even be wrong. That is precisely why you
> should LEAVE THE MIXER SETTINGS ALONE, and allow the
> user to adjust them him/herself. 
> 

You made this point earlier.. I said I like the idea 3 times? What is
your new point? Do you want a cookie? I've never done anything like that
but I dunno, I'll ask around.. any specific preference?

> And if you are about to explain to me that the
> SB-Live!'s OSS-to-ALSA mixer mapping is "obviously"
> wrong, then I suggest that you present your case to
> the ALSA developers instead.
> 

Who cares? If we scroll up or read several other posts didn't we come to
a conclusion that makes even stating this irrelevant? 4front
technologies is going to do what works best for them. Damien will do
what works best for the users regarding gnomemeeting. In all reality the
end say will lie with him.

> So if you've QUITE finished calling me a liar and
> lecturing me about how my own Linux box is
> configured...
> </Extreme Patience Mode>
> 
I never did any such thing and I don't care how it's configured.

> > > Since you've obviously never experienced this
> > problem
> > > for yourself, let me suggest what the only real
> > > solution can be:
> > > 1) Rename the "OK" button to "End Test". Do not
> > > disable it.
> > 
> > It's disabled initially because it's a procedure. If
> > you want immediate abort, then an abort button would
> > have to be added which 5 seconds later would be
> > useless if you could End Test... So if anything it
> > should be renamed to End Test.
> 
> These are implementation details. I am giving you the
> "end user" perspective that intuitively there should
> be ONE button, and it should ALWAYS end the test
> immediately. And thereby not FORCE the unluckier of
> your users to endure 5 seconds of LOUD FEEDBACK!
> 
Right as I said from the end users perspective it's a procedure. Please
lookup the definition of procedure. In real life to achieve
functionality or a goal in some systematic problem. You have procedures,
these procedures must be fulfilled to gain the functionality or goal
that you are trying to achieve. Here we are testing the audio devices,
so we record and playback 5 seconds of data. We can either add a button
labeled abort; to abort the procedure or we can end the procedure. 

Adding an abort button is stupid and for 5 seconds we need to fulfill
the procedure requirements. Then a user can End the test, and they don't
have to endure 5 seconds of Loud Feedback, they can end as soon as the
playback begins. Is there a better way to do this; probably. I
personally don't believe your way is that better way. Which even from a
users end perspective would involve extra code that simply is not needed
for 5 seconds worth of playback.

> I neither know nor care how best to achieve this.
> 
> > > 2) Add a MIC mixer control to the test dialog, and
> > > invite the user to adjust if if s/he cannot hear
> > > anything (your third suggestion). Show the user
> > > the current setting, and leave it there.
> > 
> > Adding to the test dialog seems like a good idea.
> > Send the patches..
> 
> I've already sent a patch that meets my needs, thanks.
> However, you might want to consider the plight of the
> rest of your poor users.
> 

Right, except for the fact that not all the "poor users" use Alsa. Or to
be more specific, Alsa with OSS Emulation. Which in the bigger scheme of
things would make your patch irrelevant. This leaves us back to number
2; leaving your patch out. However, the core root of the problem has now
been diagnosed. That is dealing with the mixer settings, which again; I
said I like the ideas.. I'll find you a cookie. 
 
> Sincerely,
> Chris
> 

Lovingly yours,
Christopher
> 
> ________________________________________________________________________
> Want to chat instantly with your online friends?  Get the FREE Yahoo!
> Messenger http://mail.messenger.yahoo.co.uk
> _______________________________________________
> GnomeMeeting-list mailing list
> GnomeMeeting-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-list