Include Port Selection

[anduchs]

Since it was requested twice now, I should probably add port selection.

Question: How ?

1. Just append ports to devices Pro: Con: Name is too wide already, so no way to choose.
2. An additional drop-down for each device. Pro: Con: Three clicks is much and no way to "just select default port" on that device
3. Right-Click overlay Pro: Con: somewhat misleading regarding UI-behaviour
4. Right-Click drop-down from devices in submenu Pro: Con: hugely misleading regarding UI-behaviour
5. Left-Click toggles device selection, Right-Click toggles port selection on current device Pro: Con: somewhat misleading regarding UI
6. is impossible, 2. lacks the "default device port" option. I tend to go for 5. or maybe 3. How important is "device+port selection in one step" (3. over 5.) ?

[garrett]

I think it's expected behavior to expose everything available in "output" in the control center.

Are there any typical examples where there are more than one audio card? Most people probably have 1 card visible and want to switch between different outputs. The most common case I can think of regarding multiple chipsets for audio would be having a USB audio output. But I would think it is much more of a corner case than switching between headphones and HDMI out.

Do all cards have similar output names?

On this screenshot of my system, you can see "HDMI / DisplayPort", "Speakers", and "Analog Output". As I only have one card, I really don't care about the "Built-in Audio" part of the string. It would probably make sense to display this first part of the string and only show the device name, in parenthesis most likely, after an audio item that's not unique. That is, if I have 2 cards, one called "Built-in Audio" and another called "USB audio"; the USB device wouldn't have HDMI / DisplayPort support, so just show "HDMI / DisplayPort". However, where the two may clash, such as displaying "Analog Output", you could show "Analog Output (Built-in Audio)" and "Analog Output (USB Audio)".

If you are concerned about the string length, inverting the values and displaying something like "Built-in Audio: Analog Output" and "USB Audio: Analog Output" might be better. It'd have to be tested though. If the previous solution works (using parenthesis), it would probably be a better choice of the two, as people would be more likely concerned about the connection of audio.

---

Note: I have a USB audio input device (a webcam with a microphone). While it's different as it is input instead of output, it's very similar conceptually.

In this case "Internal Microphone" tells me more than enough; I don't need to know the technical details that it comes from the "built-in audio" support.

I care more about "Internal Microphone" versus "Sony Playstation Eye" than "Built-in Audio" and "Analog 4-channel Input", hence the preference above for "Friendly Output Name (Audio Source)" when friendly names clash and audio sources differ.

[garrett]

So, if I understand your list above, I'd just say that the extension should provide a flat list of all outputs from all devices and try to keep the names friendly and simple (unless there's a clash).

In probably something like 80% of cases, this would be a list of 2 - 3 outputs to switch between. (In the case of only 1 output, people simply wouldn't install the extension. It's only installed when there's a need for it.) For the remaining 20%, it would probably be a list of 3 - 7 (wild guess) of different outputs between different chips (like internal card vs. USB, or 2 internal cards, etc.).

(Note: The figures are completely made up, but I am fairly certain it would be an overwhelming majority for people to want to quickly switch between internal speakers, external speakers and/or headphones versus those with multiple cards. But the great thing is that the extension should be able to meet the needs of both groups of people quite well.)

[anduchs]

Well, you know how open-source works regarding "scratching one's own itches"... My scenario is a desktop with "internal audio", with "Nvidia-HDMI" and with a "USB Headset". So I have to choose between three devices and always use the default port on each of them.

So that's also my problem with the continuous list: The Nvidia-Card has 4 (HDMI-)ports (at least in software) and only one is meaningful. I don't want to clutter the drop-down with two thirds meaningless entries... I'll see what I can do though...

[garrett]

Ah, excellent! Thanks.

I figured there would be multiple setups. It would be great if we could have it work best for both of us (and everyone else too) with minimal clicking around.

Does GNOME remember the default port between your 3 devices?

Is there a way to detect if a port has something plugged into it? (Sometimes I see headphones and other times I see speakers. It seems to guess, but perhaps it might not have a plugged in state, but only know about what might be plugged in. However, I guess some devices won't report the state and others, such as internal speakers, are always connected... so it might not be a catch-all solution to hide unplugged ports.)

[garrett]

BTW, here's output from alsa-info (part of alsa-utils, at least in Fedora) from my system: http://www.alsa-project.org/db/?f=c0241af94cc30c51a34f45a98f790fcbe18e96d8 — it may be useful, as it has a ton of information about sound hardware. (It would be interesting to compare the output across machines.)

[anduchs]

Ok, I pushed a branch "ports"... Please check if that works...

Unfortunately, I would not want to put in on the website just now, since the port-updating is still somewhat hackish (there is no "port-changed"-signal)

[garrett]

Thanks for working on this!

I'm testing it here on the ports branch and when I have "HDMI / DisplayPort" selected, it claims "No more devices" on the expanded area. When switching it in GNOME Settings to either "Speakers" or "Analog Output", it allows me to select only "Speakers" or "Analog Output" from the dropdown — but not "HDMI / DisplayPort".

Summary: What's on the branch isn't working properly for me. :frowning:

---

Perhaps my setup might be a little odd — the laptop itself provides all of the mentioned outputs itself, but also is docked, where the analog output is duplicated and HDMI out also exists (but not DisplayPort, which is a detail that matters to my high-res monitor). I'm not sure if the dock is getting in the way of the selection; it could be that both of the same outputs are simultaneous and chosen at the hardware level, or it could be that the software can see a difference but doesn't show it.

The "HDMI / DisplayPort" output I'm currently using is attached directly to the laptop's DisplayPort and not the dock's HDMI output, by-the-way.

I'm not sure if it helps at all, but here's a screenshot of "everything" exposed by alsamixer:

(The USB camera is just a microphone; the ThinkPad specific device seems to be a beep. Default is PulseAudio. It's on the most interesting part with all the switches and sliders.)

[anduchs]

Hmmmm... Could you please do the following:

Alt+F2: lg to start gnome-shells console (with 3.12 you can paste commands into there)

And then look through: Main.panel.statusArea.aggregateMenu._volume._control.get_sinks()[0].name Main.panel.statusArea.aggregateMenu._volume._control.get_sinks()[1].name etc ... Main.panel.statusArea.aggregateMenu._volume._control.get_sinks()[0].get_ports()[0].port Main.panel.statusArea.aggregateMenu._volume._control.get_sinks()[0].get_ports()[1].port etc ...

That's the info from gnome volume control that I rely on for my addon...

[garrett]

[anduchs]

Hmmm.... That looks like the extension shows the correct information... So if the displayed info is wrong, that's a GVC bug, I'm afraid... Do pavucontrol and the gnome-audio-settings show the correct devices ?

[garrett]

Oddly, under Pavucontrol's "Output Devices", only "HDMI / DisplayPort" is shown as the only port (that's all there is in the dropdown):

But if I switch to either "Speakers" or "Analog Output" in GNOME's settings... ...then the output for Pavucontrol is different in the dropdown:

[anduchs]

What does pavucontrol give under configuration->"Builtin Audio"->profile dropdown ?

I somewhat guess that you will be able to choose between "analog" and "digital" there in some way... That would explain all of this...

Question remains: How the hell does ControlCenter do the device-detection here ?!?

Could you also upload your pactl list cards pactl list sinks to some pastebin ? That should be more compact than all these screenshots...

[garrett]

Here's a screenshot of pavucontrol's configuration tab:

...and the output of both pactl listings: https://gist.github.com/garrett/0ecf0c0b001ff60a6421

Specifically: https://gist.githubusercontent.com/garrett/0ecf0c0b001ff60a6421/raw/dcb1447ce2816ad452e95fafc2b79c475f9e672f/pactl-list-cards.txt & https://gist.githubusercontent.com/garrett/0ecf0c0b001ff60a6421/raw/3bafd8f3710a89644053438679b2fbb57dec6f17/pactl-list-sinks.txt

[anduchs]

OK, that's what I was afraid of... The soundcard can only run either HDMI or analog output and the selection needs to be done via the profile.

Unfortunately, libgnome-volume-control does not provide BOXED_TYPES for CardPorts and CardProfiles, so I cannot even access this stuff from javascript right now.

Here is my internal todo-list for this feature. If you know something about GIR-annotation regarding point 1, that would be of great help (seems to be the most complicated item to me right now).

I'm also afraid that given the number of steps and the need to get patches upstreamed with gnome, this might take a looooooong time...

I'm highly sorry for that... :-(

TODO for libgnome-volume-control:

• Find out how to GIR-annotate GLists which are fields of BOXED_TYPES
• Add copy & free functions for GvcProfile (GvcCard.{h,c})
• Make GvcProfile a BOXED_TYPE (GvcCard.c)
• Add copy function for GvcCardPort (GvcCard.{h,c})
• Make GvcCardPort a BOXED_TYPE (GvcCard.c)

TODO for this extension

• Have extension detect if GvcProfile and GvcCardPort are available:
  • Keep old code path if not available
  • Iterate over GvcCards and GvcCardPorts for port-list detection
  • Include test of available and direction
  • TODO: what about Bluetooth- (and other) cards that offer no ports whatsoever ?
  • Switch Card's Profile on output-selection (from profile-list)
  • Needs to be synchronized with the currently selected input port if on the same card.
  • Maybe should already be done for port-list-detection in case a card does not offer arbitrary combinations.
  • Switch to Card
  • Switch to Port
  • Maybe gvc_mixer_control_change_output can help with the last 3 steps, even though that function just returns after profile-swap. TODO: investigate further...

[anduchs]

OK, forget all this... There is some obscure (at least to me) UIDevice Class in libgnome-volume-control. I only have to find out, how to get the list and then it should hopefully work...

[anduchs]

Ok, I pushed a new branch "ports2" Would you mind testing it ?

[Mno-hime]

Re "ports2": Neat! That‘s what I was originally looking for. Now I am able to change output on my sound card via a menu in Shell. Thanks!

[garrett]

The ports2 branch seems to work fine here on my computer too! Thanks!

[garrett]

BTW: I have a Bluetooth speaker and a Bluetooth widget that accepts audio over Bluetooth (and has a jack for speakers), so I can test them out if you'd like. (I don't use either with my computer normally, but I should be able to.)

[Mno-hime]

On the first image ports2 claims "no more devices" other than Speakers (Sound app proves otherwise) and on the second one when proved otherwise (i.e. that other device exists and I am able to select it) ports2 show all available devices + "no more devices" -- which indeed is not "incorrect" :), but I feel it's sort of redundancy.

Right now I am not sure how that happened but I suggest you to do some testing with suspend and plugging/unplugging jack while in suspend mode.

[anduchs]

@garrett yes, please test them out, that would be great

[anduchs]

@Mno-hime I noticed some weird behaviours as well. Not only during suspend (on my machine no detection happens at all on resume), but also when disabling and enabling the extension. There seems to be some problems about the propagation of state on startup from gvc to the extension. Im investigating this next weekend.

Thanks for the testing ! Does the extension work correctly after a fresh boot (no suspend and no disabling of the extension) ? Also what happens after restarting gnome-shell (Alt+F2 r)

[anduchs]

Ok, I pushed an update to branch ports2 that improved stability on my machine.

Please test it everyone...

[Mno-hime]

Tested... and it's great - absolutely no problem spotted. Thanks.

[neitsab]

Hi, it does work on my system as well, although I've had a few issues with suspend and resume (my laptop normally suspended on lid close but automatically resumed after 10 seconds). However, I cannot attest with certainty whether this was due to the extension, and I haven't been able to reproduce it, so.. I'm just mentioning it in case, but my guess is it was unrelated.

Many thanks for this branch, which provides a much appreciated functionality!

[anduchs]

Interesting.... the most recent update was specifically due to suspend&resume problems I had on my machine. I had hoped to have them fixed now... Are you certain, that the problems were on this latest version or maybe an older one ? Could you test some more ?

If this was stable, I'd publish it as update to the website otherwise...

[neitsab]

Hey, sorry for the delay but I can confirm with 100% certainty the suspend & resume problem I had encountered wasn't due to the extension, but indeed to a random kernel dysfunction.

I've been using this branch since then and haven't met any new problems. It allows me to switch perfectly between HDMI, internal speakers, USB speakers, headphones... and I often suspend and resume my laptop without any problem whatsoever. Personally I suggest you merge this branch in master, the provided convenience is really worth it. :+1: for the great work!

[anduchs]

Awesome... Thanks for the feedback...