[gstreamer-bugs] [Bug 336075] ALSA emu10k1 mixer tracks are wrongly classified as playback tracks

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=336075
 GStreamer | gst-plugins-base | Ver: 0.10.x





------- Comment #16 from Sam Morris  2006-05-08 18:59 UTC -------
(In reply to comment #14)
> I think, I should undo my decision swapping the meaning of gstreamer 'record'
> and 'mute' for capture tracks. 'GST_MIXER_TRACK_RECORD' is just a confusing
> appellation. Should be 'GST_MIXER_TRACK_RECORD_AUDIBLE' or something like that.
> But I'm not the only one, who got confused. The gnome-volume-control author
> bound the record toggle button with the gstreamer record flag instead with the
> mute flag...

Hm. So the mute flag of an output track maps to the pswitch, and the record
flag of an input track also maps to the pswitch? How then can I set the
cswitch?

Hm, also, what happens if I set the mute flag of an input track or the record
flag of an output? :)

> > Speaking from an HIG perspective I think the way that alsamixer (and now
> > gnome-volume-control) present exclusive capture groups is unintuitive. I 
> > have a couple of ideas about how to fix this, what do you think about them?
> 
> Uff, Ahhh, HIG! Sorry, but I'm definitly the last person who you should talking
> about HIG stuff... :)

Well, I was hoping for comments on the sanity of the changes that would be
necessary to gstalsamixer... I was hoping to trick you into modifying it for
me. ;)

Once we get gnome-volume-control cooperating with the gstalsamixer I can take a
crack at implementing them myself though. :)


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.