This would be using:
pa_context_set_card_profile_by_index() to set the profile
profile data is included in pa_card_info (http://0pointer.de/lennart/projects/pulseaudio/doxygen/structpa__card__info.html)

list-cards in pacmd can be used for debugging.

UI-wise, this would be another tab (last one) and we'd also be able to test speakers if the device has been switched to surround (see bug 519438).

Why do you think you need another tab?

I'll send you the IRC logs, we spent 2 hours discussing it with Lennart...

(In reply to comment #3)
> I'll send you the IRC logs, we spent 2 hours discussing it with Lennart...

For other readers. There's only one profile per sound card. Different profiles have different focuses, and will result in different sink/source setups, for example:
- recording via SPDIF (no sinks, only one source)
- outputting via 5.1 (no source, one sink)
etc.

Because the profiles aren't either sinks or sources, and switching between them would create sources and sinks, we can't show them in the input or output tab. Otherwise you'd end up switching to a recording-focused profile in the output tab, and your sink would just disappear.

A big mess.

The only use case I can see is to switch from a stereo profile to a surround sound one. So I'd add a drop-down to that effect in the output tab, and only there.

(In reply to comment #5)
> The only use case I can see is to switch from a stereo profile to a surround
> sound one. So I'd add a drop-down to that effect in the output tab, and only
> there.
> 

Uh, and and what about switching between Analog and SPDIF input? 

Also, note that on BT you can use the profile stuff to switch between A2DP and HSP. And for other devices there might be other profiles.

I think it would be reasonable to display something like the following, for input:
Internal microphone
Line in
Digital audio in

Output:
Internal speakers [Headphones] (depending on jack sensing)
Digital audio out
5.1 Surround


I have no idea what BT, A2DP, and HSP are.  So far, I am strongly opposed to exposing card and profile information directly to the user.  I do not like that we even show the device at all right now (eg. HDA Intel - Blahblah).

Lennart, how can we use PA to give us something like what I've described here?

The 'profiles' PA exposes are configuration profiles of the sounds *cards* -- not of sinks or sources. That means, depending on which profile is chosen for a card a different number of sinks and sources with different settings are enabled. That might be 0 sinks, and 1 source. Or 1 sink and 0 sources, or 1 sink and 1 source, or 0 sinks and 0 sources, or 2 sinks and 0 sources, and so on. Any combination is thoretically possible in the API.

Now, more specifically for ALSA cards this is used to switch between different channel mappings, between analog/digital in/output and in the not so distant future also for different input/output connectors (line in vs. internal mike, ...). As an example the following profiles might be defined for one specific ALSA card:

  "Analog Stereo Input Internal Microphone, No Output"

  "Analog Stereo Input Line-In, No Output"

  "Analog Stereo Input Internal Microphone, Analog Stereo Output"

  "Analog Stereo Input Line-In, Analog Stereo Output"

  "Analog Stereo Input Internal Microphone, Digital IEC985 Stereo Output"

  "Analog Stereo Input Line-In, Digital IEC985 Stereo Output"

  "Analog Stereo Input Internal Microphone, Analog Stereo Output, Digital IEC985 Stereo Output"

  "Analog Stereo Input Line-In, Analog Stereo Output, Digital IEC985 Stereo Output"

  "Disabled" (aka "No Input, No Output")

  "No Input, Analog Stereo Output"

  "No Input, Digital IEC985 Stereo Output"

  "No Input, Analog Stereo Output, Digital IEC985 Stereo Output"

  "No Input, Analog 5.1 Output"

This is actually a very realistic example. Interesting is the following: this card allows simultaneous use of SPDIF (aka IEC985) output and analog output, but only in stereo! Also, It allows 5.1 output only when nothing else is going on. And then, this card allows switching between two input connectors. So in summary, this list of profiles includes profiles with 1 source, no sink; 1 source, 1 sink; 1 source, 2 sinks; 0 sources, 0 sinks; 0 sources, 1 sink; 0 sources, 2 sinks. 

What this means for your question is that you cannot simply break this down to a single list of input profiles and another one for output profiles, because in some situations there is more than one output and in other situations there is no output at all! Similarly for input. Or speaking with the example above: if you had just one list for input and another one for output, then if the user selects "Surround 5.1" for output the result might be that the source simply goes away because the card is effectively simplex in 5.1 mode. The UI should not hide this fact!

Regarding Bluetooth: There's A2DP which is a 'hifi' protocol and practically simplex. There's another protocol HSP/HFP which is 'lofi' (i.e. for telephony) but always duplex. In PA this is exposed as profiles. In this case we have three profiles:

   "A2DP, Hifi Stereo Output"
   "HSP, Telephony Mono Duplex"
   "Disabled"

In this case you have one profile with no sink/no source, another one with just 1 sink and a third one with both a sink and a source.

So again, the crux is that selecting a configuration is *not* per-sink or per-source -- it is in almost all cases per-card!

Now, you could of course filter entries from this list in the UI, under the assumption that some of the profiles don't make much sense (e.g. the profiles that appear to be 'subsets' of others). However I am strongly against this, because the set of profiles defined for a card is highly dependant on the software or hardware underneath. Filtering entries would require g-v-c to really understand what those profiles actually mean. And in the BT case for example, simply filtering based on 'subsets' will lead to wrong results, because HSP might appear as superset of A2DP since the former has one sink/one source and the latter only one sink. And for the ALSA case this is not that different: some cards allow only 48khz when in duplex mode but 192khz in simplex mode. Or 16 bit in duplex mode but 24 bit in simplex. Hence some of profiles make more sense then it might appear at first.

A note about jack sensing: this is still a bit in flux. But the way i plan to expose this in PA is that when we have sensing information PA will deduce the profile that is "most similar" to the current profile and matches the sensed connectors. That profile is then stored in pa_card_info as an additional field "suggested_profile". This might then be shown in the UI in some way. There will also be an additional module in PA that will simply switch to this suggested profile whenever it changes.

Man, that really sucks.  The concept of cards is not something that we should expose in the UI.  Your argument for why we cannot have separate lists of options not very compelling to me either.

Terms like this should not appear in the interface:
IEC985
A2DP
HSP

Needs some design work here.  We should not let the API or ALSA be defining how we present this to the user...

At least, PulseAudio could try to be clever to switch automatically from HSP to A2DP, but that will need some work and discussion :) 

It's not the API nor ALSA that defines how to present this to the user here. It's the simple fact that the hardware is built the way it is built. Playback and recording are not independant units.

Regarding the term "IEC958": Better known than this is probably the name "S/PDIF" which is mostly synonymous, which however has the problem that the S stands for Sony and the P stands for Philips -- both of which are trademarks. Hiding the connector name completely and just calling it "Digital" is counterproductive I believe: after all this is for selecting output connectors, and those connectors have a name we should simply use instead of coming up with our own. Someone who understands the concept of different output connectors should be able to name identify and name them properly.

Something similar is true for BT. In some way the we need to tell the user what this is actually about. 

You can of course put it at the end of the profile name in brackets if that is of any help to you. "Digital Output (IEC958)", "Hi-Fi Output (A2DP)" and "Telephony Input and Output (HSP/HFP)".

For testing, in pacmd:
# listing
list-cards
# setting
set-card-profile <card index> <profile name>
eg.
set-card-profile 2 output-analog-surround-51+input-analog-stereo

FWIW, I've looked at the code, and my current plan is, for each sink's card that supports it show the available speaker layout. Similarly to http://blogs.gnome.org/rodrigo/files/2008/06/paprefs-speaker-setup.png

For example, for my sound card it shows:
output-analog-stereo+input-analog-stereo: Output Analog Stereo + Input Analog Stereo (priority 1010)
output-analog-stereo+input-iec958-stereo: Output Analog Stereo + Input IEC958 Digital Stereo (priority 1005)
output-analog-stereo: Output Analog Stereo (priority 1000)
output-iec958-stereo+input-analog-stereo: Output IEC958 Digital Stereo + Input Analog Stereo (priority 510)
output-iec958-stereo+input-iec958-stereo: Output IEC958 Digital Stereo + Input IEC958 Digital Stereo (priority 505)
output-iec958-stereo: Output IEC958 Digital Stereo (priority 500)
output-analog-surround-41+input-analog-stereo: Output Analog Surround 4.1 + Input Analog Stereo (priority 710)
output-analog-surround-41+input-iec958-stereo: Output Analog Surround 4.1 + Input IEC958 Digital Stereo (priority 705)
output-analog-surround-41: Output Analog Surround 4.1 (priority 700)
output-analog-surround-50+input-analog-stereo: Output Analog Surround 5.0 + Input Analog Stereo (priority 710)
output-analog-surround-50+input-iec958-stereo: Output Analog Surround 5.0 + Input IEC958 Digital Stereo (priority 705)
output-analog-surround-50: Output Analog Surround 5.0 (priority 700)
output-analog-surround-51+input-analog-stereo: Output Analog Surround 5.1 + Input Analog Stereo (priority 810)
output-analog-surround-51+input-iec958-stereo: Output Analog Surround 5.1 + Input IEC958 Digital Stereo (priority 805)
output-analog-surround-51: Output Analog Surround 5.1 (priority 800)
input-analog-stereo: Input Analog Stereo (priority 10)
input-iec958-stereo: Input IEC958 Digital Stereo (priority 5)
off: Off (priority 0)

We'd filter this down to only a few profiles, the highest scoring for each output type:
output-analog-stereo+input-analog-stereo: Output Analog Stereo + Input Analog Stereo (priority 1010)
output-analog-surround-41+input-analog-stereo: Output Analog Surround 4.1 + Input Analog Stereo (priority 710)
output-analog-surround-50+input-analog-stereo: Output Analog Surround 5.0 + Input Analog Stereo (priority 710)
output-analog-surround-51+input-analog-stereo: Output Analog Surround 5.1 + Input Analog Stereo (priority 810)
output-iec958-stereo+input-analog-stereo: Output IEC958 Digital Stereo + Input Analog Stereo (priority 510)

That gives us a drop-down menu with:
Stereo
4.1
5.0
5.1
S/PDIF (Digital)

The only problem being whether we can rely on the profile names being of this type. We can certainly do special casing for the Bluetooth case as well.

I'm sure Lennart would want us supporting all the different profiles, but I think that we're covering the biggest use cases here, and we can always change our take on this problem when bug reports come in.

I'd expect pavucontrol to be able to change all the profiles, but this isn't something for gnome-volume-control.

I tried to explain why this won't fly. But here I go again:

- The 'priority' value is not exported, it is not bound in the API and shouldn't be. It is an internally used value to figure out a good initial default that matches the configuration in daemon.conf. I.e. it is not static, it is already bound to configuration. Clients can't see this value, nor should they.

- Names like "output-analog-surround-50+input-analog-stereo" are supposed to be simple identifiers, not something you should parse. These identifiers will also change in future, e.g when the ability to choose hardware outputs (i.e. Line-Out vs. Headphones) and hardware inputs is added (i.e. Line-In vs. Mic). Also, the ones listed above are specific to the ALSA module, and hence not portable. Different profile names are used on Bluetooth, and especially for other modules.

- I think it is very difficult to understand to the user that if he selects "5.1" in your suggested solution the ability to record simply goes away. 

- You ignore the Bluetooth case.

- You hide the ability to choose hardware outputs/inputs.

I find this entire discussion so pointless. The fact that there is only a single list of configurations to select one from is already very abstracted and simplified. Further simplification and bending to make something that is a property of a card to be a property of a sink or source is not a good idea. 

Selecting a profile for a card is nothing that must be visible directly in the mixer UI. It can be hidden in a very simple dialog that is only indirectly reachable. For example a dialog that shows two drop down lists -- one for the card and another one for the profile for the card.

I was hoping that g-v-c would take over from pavucontrol and I could end maintaining pavucontrol. 

Not sure how Windows does it, but they have a much better view of the profiles available. This is for the same soundcard I pasted the profiles above:
http://people.fedoraproject.org/~hadess/gnome-volume-control/windows%207/Capture.PNG
http://people.fedoraproject.org/~hadess/gnome-volume-control/windows%207/Capture1.PNG

They only show 2 devices/cards/sinks for the USB audio device as outputs, and the input show whether they're available. If the user wanted to turn one on, he'd get told that it will change the available outputs, which seems fair enough to me.

You also see that they do separate speaker arrangements from profile/active output selection.

I don't think the current PA API allows us to present it like this to users.

More screenshots at:
http://people.fedoraproject.org/~hadess/gnome-volume-control/windows%207/
http://people.fedoraproject.org/~hadess/gnome-volume-control/macos%20x/

I have now added a bit code to PA for exporting the 'priority' value to the clients, intended to be used for sorting the available profiles in the UI. That said I still don't think using it is a good idea to use it for what you want to use it.

Here are my thoughts on this:

- We really want to show the user a meaningful list of possible 'devices', with understandable names/icons (the two windows screenshots that Bastien has in comment #15 are good examples). Useful information to include in the list: connection type like USB, and availability (e.g. if an input device can not be combined with the currently selected output device, mark it as unavailable)

- I think we want to have a list of output devices and a list of input devices, not some combined 'per-card profile' list. If selecting a different output device invalidates the current choice of input, we'll just inform the user about it. 

The discussion about useful icons for this got stuck here:
http://lists.freedesktop.org/archives/xdg-list/2009-March/010290.html
I propose to just ignore the name discussion here, and go ahead and get a set of useful icons from a cooperative artist.

Just a quick update: I am currently working on output/input switching for ALSA devices. This will complicate profile switching considerably and add a lot of additional profiles for each card. Also, for SPDIF I will need to add an option to switch between 44 and 48khz because that setting needs to be set correctly for the connected amp and there is no way to autodetect it.

I will also beef up the meta information you get for the profiles which should make it easier to filter out profiles and show icons and stuff like that.

In PA 0.9.16 there are now "ports" for sinks/sources, that are similar to "profiles" of cards: they are identified by a name and only one can be selected at a time. A "port" is used to implement switching between Line/int Mic/ext Mic... for sources, and Headphones/Speakers/... for sinks (if the hw has a switch like this). They are queried similarly to card profiles and set similarly as well. Check the doxygen docs for details, but this should be pretty straightforward.

The distinctions between profiles and ports are not always clear, the line on what is exposed a card profile and what as a sink/source port is blurry, and only defined by technical reasons but not really because it might make sense in the ui. Sorry for that. So generally a profile change might have a really big effect on the availability of sinks and the number of sinks by a card (same for sources), and the low level setup for them while ports are used fr more lightweight switching, i.e. only the last step of the routing. 

Unfortunately it is not really possible to determine the availability of ports before a sink/source actually got created and setup.

generally the number of ports per sink/source is very small (i.e. two, maybe three), but for older sound cards there might be 10 or so.

from a more high-level, user viewpoint switching profiles is probably something you need to do only if you buy new equipment like a new surround set or during initial installation or so, while "ports" you use to switch between different mics you connected or suchlike. Setting a port should probably be accessible more easily then setting card profiles.

At this point the data exported in the profile still does not contain full meta data about the sinks/sources it would create. I contrast what I wrote above I am no longer (or again not) convinced that this is really something that should be exported in the UI. I don't think it would be a good idea to select a profile by going via the channel map you want. The reason for that is that this would only work for normal standard consumer sound cards. However sound cards like those sold for podcasts ("prosumer") today have multiple independant audio plugs (i.e. on one you play your podcast music, on the other you listen with your headset what you could play next). I think "prosumer" hw needs to be covered properly by pa, they are not "pro" cards that are out of focus for us. If you select a profile for one of those cards you should be selecting it based on the textual names of the plug (i.e. those cards are usually external and have a socket called "A/Headphones" or so and another one called "B"), not the channel map. That'd be only secondoary. If PA is now run on a card like that you well get profile names that are very much unlike the ones that are generated for normal consumer cards. I.e. for these devices they could look like this: "Output Analog Stereo Channel A/Headphones + Output Analog Stereo Channel B" while on normal consumer cards named sockets are not known and this would show up as "Output Analog Stereo". In summary, card profiles can have very different meanings on different cards:

- on bluetooth they expose HSP vs. A2DP and hence duplex vs. output-only
- on consumer cards they expose various surround configs and combinations of no/one input and no/one output
- on "prosumer" cards they expose various labeled input/output configurations

Now, implementing a config UI that would first ask for the speaker setup and then select the profile automatically from that seems like the wrong approach. I'd rather see that the user selects one of these nicely named profiles from a drop-down box and could then verify the speaker setup for all sinks (and sources?) that are activated by it.

Also note that different profiles of one card might be completely unrelated to each other and can consist of more than one, or two, or three sinks/sources. What Mathias suggesting above in graying out unavailable options might hence work nicely on simple cases, but you'd have cases were doing this would expose a strange dialog because it might happen that not a single sink/source might be shared by the various profiles, and you might need to show 4 lists at once? 

Dunno, i have changed my mind about all of this in the last weeks quite  a few times forth and back. I guess I am simply afraid that when I expose all the information on sinks/sources a particular profile might create, for allowing implementation of what Mathias suggested that we'd then end up with an UI that works for the trivial cases, but breaks for bt/prosumer/... cards, and all the stuff that might come later. I do acknowledge that for standard consumer cards configuration with selecting the channel map first and then deducing a working profile from that might be good. But for anything that doesn't qualify as "standard consumer card" this doesn't work. A possible way out of this is to be able to distuingish the two cases and show a different UI for them. dunno.

I have not added switching of sampling rates (for the SPDIF case). I decided that it makes more sense to add that eventually though by a seperate pa_context_set_sink_sample_spec() or so.

The priority field is now exported in the profile data and in the port data too.

(In reply to comment #5)
> The only use case I can see is to switch from a stereo profile to a surround
> sound one. So I'd add a drop-down to that effect in the output tab, and only
> there.

I have a very simple use case. A computer-controlled surround system in a room where the sofa is facing another wall (basically 4 identical speakers in each corner of the room + one sub + one central I'll ignore for the sake of the argument)

So when you're doing stuff at the computer you want your "front" speakers to be different from when you're relaxing on the sofa (and disable central channel since it only faces the sofa)

Card profile switching is now in master.