Bug 491372 - Doesn't handle switching inputs on one device
Summary: Doesn't handle switching inputs on one device
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pulseaudio
Version: 11
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 479790 492225 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-20 17:05 UTC by Adam Williamson
Modified: 2013-01-10 05:06 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-22 23:48:24 UTC
Type: ---
Embargoed:
mclasen: fedora_requires_release_note?


Attachments (Terms of Use)

Description Adam Williamson 2009-03-20 17:05:06 UTC
This has been discussed in various blog posts and IRC sessions, but I can't find any actual bug filed on it. So I'm filing one. Technically this is an upstream issue, but we need a Fedora report so it can be considered in the context of F11 and marked as a blocker.

gnome-volume-control has, during the F11 rawhide cycle, been replaced by a lobotomized version which no longer exposes any of the underlying mixer channels for any bit of hardware. In an ideal world this would be great, as it avoids unnecessary complexity. In the real world, though, it's a disaster.

Practically speaking, there are many scenarios which require the adjustment of specific mixer channels for very basic sound functionality to work. A common example is cards where a switch-type mixer channel selects analog or S/PDIF output; without an application that exposes these channels, someone who happens to have whatever type of output equipment is not the default will get no audio.

Another is even simpler: how do you select the input channel? If you don't happen to want to record from whatever the default is, you're stuffed, there's no way to select any other input channel.

There are dozens of scenarios like this. How to handle them properly is an interesting long term discussion - there needs to be some kind of useful abstraction layer in ALSA or Pulse, probably - but in the short term, we can't ship F11 without a GUI app installed by default that lets you poke at raw hardware mixers. At present, in a default install of F11, we're going to have to tell an awful lot of people how to a) run and b) use alsamixer invocations like this:

alsamixer -c0
alsamixer -c0 -Vcapture

I'm not looking forward to that.

At the very least, g-v-c needs to expose all useful input channels on the 'Input' tab, and we need to have some way to flip mixer channels labelled IEC958.

Comment 1 Adam Williamson 2009-03-20 18:14:34 UTC
Just to make one thing clearer - on a default Fedora install (i.e. the GNOME live CD or DVD with default package choices) g-v-c is the only GUI mixer you get. On the KDE spin you'd get kmix which lets you make the necessary changes, and ditto with the Xfce mixer on the Xfce spin. But for our default cases, g-v-c is your only option.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 2 Matthias Clasen 2009-03-21 15:27:05 UTC
...a lobotomized version...

Nice that you make your feelings to our work clear right from the start.

Comment 3 Matthias Clasen 2009-03-21 15:28:22 UTC
And just to make that clear: We are not reintroducing a graphical version of alsamixer

Comment 4 Adam Williamson 2009-03-21 16:15:13 UTC
Please don't assume everything in the worst possible light from the start. Being oppositional isn't helping anyone. I actually explained my feelings, viz:

"In an ideal world this would be great, as it avoids unnecessary complexity."

Besides, my feelings are entirely irrelevant. The point is that this change negatively affects functionality. Please don't turn this into another pointless "you hurt my feelings" pissing match.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 5 Matthias Clasen 2009-03-23 14:21:43 UTC
On a more constructive note, it would be good to know if the "Configuration" tab in pavucontrol lets you do what you need. We will have the same functionality in the sound capplet next cycle, it just wasn't ready in time for 2.26

Comment 6 Adam Williamson 2009-03-23 15:44:41 UTC
No, it doesn't, that's a different set of controls. I don't know how to explain it in the correct terms, but that's for cards which let you control things via 'profiles'. For instance, my Chaintech AV-710 finds those settings useful, as on that card, you select the S/PDIF output not by toggling a mixer control but by choosing a specific output profile.

Some cards, though, as explained in this report, do it via a switch-type mixer channel. For those cards, the settings available in pavucontrol will do nothing. It also does nothing to help other cases (like the cases where you have to set certain mixer channels to get sound out of all speakers, or the guy whose card has a channel that sets his subwoofer's volume separately so even if he 'mutes' the main output channel he still hears sound from his subwoofer), and nothing to help the case of input channel selection (recording from anything other than the default input channel).

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 7 Matthias Clasen 2009-03-23 16:03:30 UTC
The profiles are a pulseaudio abstraction of what alsa tells it, nothing coming directly from the hardware. Lets bring in Lennart for some actual expertise...

Comment 8 Adam Williamson 2009-03-23 16:22:18 UTC
I apologize for the insufficiency of my expertise...

I thought profiles were exactly the same as using the hw:0,1 syntax that you can use in .asoundrc files, but I'm poking through Lennart's blog and, as you say, they're actually an abstraction (currently on top of that). He does say:

"In a later PA version this functionality will be extended to also allow input connector switching (i.e. microphone vs. line-in) and output connector switching (i.e. internal speakers vs. line-out) on-the-fly."

so it seems that the profile mechanism is the one that PulseAudio intends to use to solve this problem. Which is fine. The problem is that the current timing is likely to lead to us shipping things in F11 in a state where the messy underlying controls have been hidden but the nicely abstracted presentation of them hasn't been done yet, which is, as I keep saying, a regression.

Lennart, are you expecting to have this implemented in PulseAudio in time for F11? If not, what do you suggest F11 should do about it?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 9 Lennart Poettering 2009-03-23 16:37:35 UTC
Adam, you are misunderstanding how SPDIF in ALSA works. The special device "spdif:" will toggle all mixer controls appropriately. It will hence work properly an all cards -- and if it doesn't it's an ALSA bug. Hence the profile logic PA exposes should provide *complete* SPDIF experience -- fiddling with low level alsa mixer controls should never be necessary.

There are few things that the current abstraction code for mixers in PA does not cover though:

1) selecting input sources (i.e. mike vs, line-in, ...). ALSA in this respect is just horribly and badly broken. There is simply no sane way to find out which input sources are available so that we could present a list to the user. Also see this thread: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/014990.html As it appears this is not going to be fixed on the ALSA side anytime soon. Since most modern cards don't have more than one input source in hw we have a decent chance that the default selection of an input source is correct, and it if it isn't that we can fix the ALSA mixer defaults database correctly. But yes, it is suboptimal that PA doesn't allow you to select the input source, but asking users to use "alsamixer -c0" is actually not much worse than what we had here before. Input source selection sucked, and it will continue to suck for a while. Sorry for that.

2) Nonsense features like "3D audio", "Treble", "Bass". On most hardware this is done digitally anyway, so the proper way to implement this is in software (that's why we have SSE and stuff in the first place...). Also, the usefulness of features like that is very questionnable anyway. 

3) Some drivers are broken in respect to Surround sound and instead of exporting 1 6ch mixer track they export 3 2ch tracks. This is seriously broken in ALSA and needs to be fixed there. Due to this confusion the current ALSA utils report channels like "Rear Front Left", which of course makes no sense at all.

4) Some drivers allow controlling channels that are not available in the digital stream. Most common example is having an extra LFE track that is  
synthesized from a stereo stream. This is something we should support eventually. Not sure how to do this best though.

5) Obsolete tracks, like "CD", "PC Speaker", ... No need to support these.

6) We only expose one hw volume track. That is usually "Master". This of course works only if "PCM" is correctly initialized.

So in summary, the only really limiting issue right now is #1, the input source selection. But I don't think this is much of a regression, and also not extremely important.

Comment 10 Lennart Poettering 2009-03-23 16:38:36 UTC
An no, the input selection is not going to be in F11, sorry.

Comment 11 Adam Williamson 2009-03-23 16:52:13 UTC
OK, thanks for the clarifications. I wasn't aware of that wrinkle with how the spdif: control operated, indeed.

I should elaborate on one of the cases I mentioned in my last comment, as that came from IRC so it won't be recorded anywhere. Someone mentioned that, with their setup, the volume of their subwoofer was controlled by a separate channel in the mixer, so even if they mute Master, they still hear sound from the subwoofer. They handle this by joining the subwoofer channel to the master channel, so adjusting one adjusts the other. I guess what we should do for idiosyncratic cases like that is file a bug with ALSA, as the master channel should always control *all* output, right? If so, I'll track down who that was and get him to take it upstream.

I rather disagree on input selection, however. It's something that real people do quite often - they do stuff like recording from the radio, or from their old record collection, or just from the *second* microphone input (another example that was given on IRC - I think by Jesse), and people are mostly trained in how to do this graphically because they've done it before, often in Windows. 'Go to the mixer application and click the appropriate channel' is something that a lot of people pretty much understand. Doing it via alsamixer is not something they understand. So I think we're likely to take some heat for that one.

Is there no way you can distinguish what's likely to be a valid input channel from the info ALSA provides? In the worst case, couldn't we just whitelist the most common names (anything with 'line', 'mic', or 'aux' in it, perhaps?) and display those controls somehow?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 12 Jesse Keating 2009-03-23 16:59:58 UTC
One note here.  My laptop, pretty modern a Dell M1330 from '08 I do believe, has an "intel hda" sound setup (I know that's horribly vague) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)

This particular laptop has an input on the front for a microphone, as well as a built in microphone.  There are times when I need to use the built in microphone, and times when I need to plug in a microphone.  The way rawhide currently is, the only way I can pick which to use is to call alsamixer -c0.  Ideally, plugging in a mic would automatically kill the built in mic, just like how the speakers vs headphones work, but that isn't happening.

In my scenario, I can't think of a way that just picking a good default will work, as any default will leave me unable to which which source I record from.  Am I just an extreme odd case, or is there some plan to support my scenario?

Comment 13 Lennart Poettering 2009-03-23 17:11:49 UTC
(In reply to comment #11)

> I rather disagree on input selection, however. It's something that real people
> do quite often - they do stuff like recording from the radio, or from their old
> record collection, or just from the *second* microphone input (another example
> that was given on IRC - I think by Jesse), and people are mostly trained in how
> to do this graphically because they've done it before, often in Windows. 'Go to
> the mixer application and click the appropriate channel' is something that a
> lot of people pretty much understand. Doing it via alsamixer is not something
> they understand. So I think we're likely to take some heat for that one.

Of course, "alsamixer" is nothing we should be exposing to the user. But as mentioned the status quo ante was not much better. Input selection is just broken with ALSA, and if that is exposed to the user via the old g-v-c or in alsamixer is not much of a difference.

Again, we need this fixed. But I wouldn't consider the new g-v-c much of a regression in this area. 

And unfortunately this is post-F11 material. I am waiting for ALSA to clean up things in this area first. But they explicitly said that this is not going to happen soon. Sorry.
 
> Is there no way you can distinguish what's likely to be a valid input channel
> from the info ALSA provides? In the worst case, couldn't we just whitelist the
> most common names (anything with 'line', 'mic', or 'aux' in it, perhaps?) and
> display those controls somehow?

I have outlined a couple of possible algorithms in the alsa-devel thread mentioned. But doing this is very problematic. Patches always welcome, though.

Comment 14 Lennart Poettering 2009-03-23 17:15:50 UTC
(In reply to comment #12)
> One note here.  My laptop, pretty modern a Dell M1330 from '08 I do believe,
> has an "intel hda" sound setup (I know that's horribly vague) 00:1b.0 Audio
> device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
> 
> This particular laptop has an input on the front for a microphone, as well as a
> built in microphone.  There are times when I need to use the built in
> microphone, and times when I need to plug in a microphone.  The way rawhide
> currently is, the only way I can pick which to use is to call alsamixer -c0. 
> Ideally, plugging in a mic would automatically kill the built in mic, just like
> how the speakers vs headphones work, but that isn't happening.
> 
> In my scenario, I can't think of a way that just picking a good default will
> work, as any default will leave me unable to which which source I record from. 
> Am I just an extreme odd case, or is there some plan to support my scenario?  

Yes, cases like yours I am aware of. In fact with the advent of jack sensing many cards now are designed that input source switching is done entirely in software in contrast to hardware how it used to be done. Unfortunately jack sensing is only supported on two chips by ALSA for now, and I have no card with neither. 

Again, yes, input source switch is necessary, as is proper handling of jack sensing. But OTOH I cannot see much of a regression here. And this stuff is simply too complex and too lacking in the lower layers of our stack that we could do something about it in the F11 timeframe. Sorry.

Comment 15 Matthias Clasen 2009-03-23 17:21:56 UTC
> I apologize for the insufficiency of my expertise...

I was referring to myself there...

Comment 16 Jesse Keating 2009-03-23 17:56:40 UTC
Ok, the only thing that really tripped me up was that I was used to fiddling with the graphical mixer to get what I needed to happen, and for a day or so I was lost before somebody clued me in that I had to use alsamixer -c0  (just plain alsamixer was of no help).

I agree that the new UI is tonnes better for a large set of people, its just worse for the set of people I happen to be in.

Comment 17 Bastien Nocera 2009-03-23 18:29:36 UTC
Re-titling, and removing from the F11 blockers.

As PA doesn't advertise the different possible inputs, it's impossible for us to switch between them for now. And reassigned to PA.

Comment 18 Adam Williamson 2009-03-23 18:30:27 UTC
Lennart, just to clarify the level I'm thinking on here: the difference is that g-v-c is a GUI app that's obviously discoverable on the menus and works by pointing and clicking.

alsamixer:

a) Joe User will not stumble across it unless he already knows how to use it
b) Joe User will never figure out the '-c0' wrinkle in a month of Sundays
c) ditto the '-Vcapture' wrinkle
d) Joe User is not comfortable using console fake-GUI apps like alsamixer: he probably won't automatically figure out that you can 'scroll' it by keeping on moving to the right, and he probably won't guess that you toggle which channel is the active one by highlighting it and pressing space

I'm just working on a basic UI level here. I know the fundamental setup displayed by old g-v-c and alsamixer are basically the same: both are just a list of each of the available channels and the settings for them. But most users are more comfortable with the graphical-pointy-clicky interaction you get with old g-v-c versus the console keyboardy-pokey interaction you get with alsamixer. That's the level I'm looking at here, not anything more complicated than that :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 19 Adam Williamson 2009-03-23 18:32:45 UTC
bastien, I'd still rather look at whether we can include some kind of workaround for this in F11. If not in g-v-c by exposing the ALSA mixers, at least by shipping an old-skool graphical mixer (possibly gnome-alsamixer, which doesn't appear to be currently available as a package...) by default.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 20 Matthias Clasen 2009-03-23 20:19:45 UTC
Setting the release note flag here, just in case.

Comment 21 Reinout van Schouwen 2009-03-24 19:27:54 UTC
(In reply to comment #9)

> 5) Obsolete tracks, like "CD", "PC Speaker", ... No need to support these.

I think you're mistaken on that last one. As I documented in http://vanschouwen.info/nerdynotes/?p=229 recently, being able to set the PC Speaker volume is rather important when the sound is routed through your line-out (as is the case on my system).

Comment 22 Lennart Poettering 2009-03-25 18:33:17 UTC
(In reply to comment #21)
> (In reply to comment #9)
> 
> > 5) Obsolete tracks, like "CD", "PC Speaker", ... No need to support these.
> 
> I think you're mistaken on that last one. As I documented in
> http://vanschouwen.info/nerdynotes/?p=229 recently, being able to set the PC
> Speaker volume is rather important when the sound is routed through your
> line-out (as is the case on my system).  

Uh. No.

General consensus is that the PC speaker needs to die. For good. The default mixer settings should set its volume level to 0. if that is not the case for you, then make sure to file a bug about that.

The PC speaker is archaic. Who understands the difference between the PC speaker and the real speaker anyway? Sorry, but there is never going to be support for the PC speaker in PA. Only over my dead body.

PC Speaker, die, die, die!

Comment 23 Matthias Clasen 2009-03-25 18:46:57 UTC
Reinout, you are not getting a system beep on the pc speaker anymore for event sounds. These beeps are using the alert sound from the sound theme, and their volume can be controlled  very well in the sound capplet.

Comment 24 Adam Williamson 2009-03-25 19:24:35 UTC
Reinout runs Mandriva, he's just commenting here as the issue is not Fedora-specific. In MDV, the PC Speaker volume is still at 80% by default, last time I checked. It's not excepted in the MDV default-volume-setting script.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 25 Matthias Clasen 2009-03-26 01:09:12 UTC
*** Bug 492225 has been marked as a duplicate of this bug. ***

Comment 26 Rudolf Kastl 2009-03-31 15:02:12 UTC
personally i think that auto jack sensing is not enough for having proper management of input jacks/devices. to properly handle things id definitely need the possibility to seperatly enable/disable all input devices/jacks and adjust their volume properly. 
atleast if we want gnome to be useable for people that do even basic audio recording not only for recording a single instrument with multible microphone or recording multible input channels concurrently into seperate tracks. 
i am pretty sure there are more use cases for that matter. a requirements analysis for the mixer tool wouldnt hurt i guess.

Comment 27 Lennart Poettering 2009-04-03 16:22:47 UTC
*** Bug 479790 has been marked as a duplicate of this bug. ***

Comment 28 Roland Roberts 2009-04-03 17:04:24 UTC
I'll add a comment hear from Bug 479790 since many of you may not look over there.  

I have a Dell Latitude D820 which uses the Intel HDA STAC92xx card.  In F8, I could plug a dual powered microphone into the microphone/line-in jack and record stereo.  I actively used this setup.  When I went to F10, I lost that ability.  My wife's MacBook is now used instead :-).  

It's disappointing to hear this won't get fixed for F11.  But if you are collecting use cases, add this one since for me, F10 is a significant regression in functionality.

Comment 29 Eddie Lania 2009-04-10 16:33:33 UTC
If no input channels are going to be controlled by anything, how then am/will I be able to mute my microphone and unmute my line in channels?

I tried alasamixer -c0 and that gives me all the channels but the microphone channel does not respond to mute/unmute switching.

Now, by default, the volume of my microphone is enabled at startup and that is not very convenient.

How can I change this?

Regards,

Eddie.

Comment 30 Adam Williamson 2009-04-14 16:38:16 UTC
Here's a thread with five people who needed to adjust levels in alsamixer -c0 to get acceptable sound:

http://forums.fedoraforum.org/showthread.php?p=1199189#post1199189

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 31 Adam Williamson 2009-04-14 16:39:16 UTC
Eddie: try alsamixer -c0 -Vcapture .

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 32 David Woodhouse 2009-04-23 09:26:59 UTC
Hm, I have  a USB audio device which is hooked into the sound system
throughout my home, and mpd uses it to play music. 

(I use line in/out between rooms. I certainly don't want each room in the house being slightly out of sync with the others, so I don't multicast over the network.)

That USB audio device is connected in _addition_ to the device I usually use for sound output that's local to the machine in question. When doing things other than mpd, I sometimes want to use the local speakers and sometimes want to use the USB audio device.

Is upgrading to Fedora 11 going to introduce a regression?

My father has a USB turntable, and is working on transferring things he has on vinyl onto the computer. Sometimes he records from that, and sometimes he records from the built-in microphone. He may sometimes also want to plug something into the microphone socket of his laptop, or record via line-in.

Should I refrain from upgrading his computer to Fedora 11 too?

Comment 33 Adam Williamson 2009-04-23 17:59:51 UTC
david: I can't quite grok your first case, but in the second, your father will need to use something other than gnome-volume-control to switch the input channel.

Don't get me wrong, this isn't a flat-out 'you can't do this stuff any more' deal-breaker. All you and your father need to know is that gnome-volume-control doesn't do this stuff any more and you need to use something else - alsamixer, the XFCE mixer, whatever. What I'm worried about is the impact from several thousand people finding out that g-v-c doesn't do this stuff any more, and not having any easy indication of what *does*.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 34 Lennart Poettering 2009-04-23 23:17:52 UTC
(In reply to comment #32)
> Hm, I have  a USB audio device which is hooked into the sound system
> throughout my home, and mpd uses it to play music. 
> 
> (I use line in/out between rooms. I certainly don't want each room in the house
> being slightly out of sync with the others, so I don't multicast over the
> network.)
> 
> That USB audio device is connected in _addition_ to the device I usually use
> for sound output that's local to the machine in question. When doing things
> other than mpd, I sometimes want to use the local speakers and sometimes want
> to use the USB audio device.
> 
> Is upgrading to Fedora 11 going to introduce a regression?

I don't quite follow what you want to do? PA allows you to move streams between devices during playback with interruptions, if that's what you are asking. Just right-click on the stream and move it to the new device. That's it.

> My father has a USB turntable, and is working on transferring things he has on
> vinyl onto the computer. Sometimes he records from that, and sometimes he
> records from the built-in microphone. He may sometimes also want to plug
> something into the microphone socket of his laptop, or record via line-in.
> 
> Should I refrain from upgrading his computer to Fedora 11 too?  

If it is really that unbearable to you to go to alsamixer -c0 or install some other low-level mixer, then yes, I fear, F11 is nothing for you. Sorry to disappoint you.

Comment 35 Lennart Poettering 2009-04-23 23:18:39 UTC
(In reply to comment #34)

> devices during playback with interruptions, if that's what you are asking. Just
> right-click on the stream and move it to the new device. That's it.

In pavucontrol that is.

Comment 36 Bug Zapper 2009-06-09 12:27:21 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 37 Lennart Poettering 2009-07-22 23:48:24 UTC
This is fixed in Rawhide btw, since a while already.

Comment 38 Adam Williamson 2009-07-23 18:05:11 UTC
By 'fixed' I guess you mean it's fixed in PA itself, as I don't see any UI for it in g-v-c yet...I suppose I should file a new bug on gnome-media.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 39 Adam Williamson 2009-07-23 18:05:59 UTC
ah, I see pavucontrol has a UI already. Nice. It seems to give sane choices on both of my cards.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 40 Matthias Clasen 2009-07-23 18:28:55 UTC
UI is in upstream gnome-media git. Expected to land in rawhide sometime next week.

Comment 41 Bastien Nocera 2009-07-23 18:57:59 UTC
(In reply to comment #40)
> UI is in upstream gnome-media git. Expected to land in rawhide sometime next
> week.  

Profile switching is in gnome-media master, not input switching.


Note You need to log in before you can comment on or make changes to this bug.