[pulseaudio-discuss] ALSA sink enumeration and multiple devices/subdevices
Recent NVIDIA GPUs include an audio controller that hosts a number of different ALSA PCM objects. For example, consider the following output from aplay -L: hdmi:CARD=NVidia_1,DEV=0 HDA NVidia, NVIDIA HDMI HDMI Audio Output hdmi:CARD=NVidia_1,DEV=1 HDA NVidia, NVIDIA HDMI HDMI Audio Output hdmi:CARD=NVidia_1,DEV=2 HDA NVidia, NVIDIA HDMI HDMI Audio Output hdmi:CARD=NVidia_1,DEV=3 HDA NVidia, NVIDIA HDMI HDMI Audio Output Each of these may correspond to a specific connector on the graphics board. However, pactl list and various other mechanisms show only a single Pulse sink for this card: Sink #0 Name: alsa_output.pci-_01_00.1.hdmi-stereo device.string = hdmi:1 Sink #1 ... // from another card If I hack /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf to change hdmi-stereo's device-strings value to e.g. hdmi:%f,0, hdmi:%f,1, etc., then I can cause pulseaudio to open whichever subdevice I wish. This proves to me that this is simply an enumeration issue and nothing more fundamental. Is this simply something that's not been implemented in the pulseaudio server, or is there a bug that's preventing the server from exposing a sink per ALSA device/subdevice? Looking at the code, I believe this is because pa_alsa_profile_set_probe is called once per card, and probes ALSA device names of the form hdmi:%f where %f is simply replaced by the card number; there is no attempt to iterate over N devices within an ALSA card, or even M subdevices within an ALSA device. Perhaps the whole (or a significant portion) of the body of pa_alsa_profile_set_probe should be wrapped in: for device in all-devices-of(card): for subdevice in all-subdevices-of(card, device) // existing for all profiles loop here and device, subdevice also passed into pa_alsa_open_by_template, and interpolated into the device name string? -- nvpublic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ALSA sink enumeration and multiple devices/subdevices
pl bossart wrote: If I hack /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf to change hdmi-stereo's device-strings value to e.g. hdmi:%f,0, hdmi:%f,1, etc., then I can cause pulseaudio to open whichever subdevice I wish. This proves to me that this is simply an enumeration issue and nothing more fundamental. I beg to disagree.. I have done similar work and I think there's something fundamentally broken in the ALSA/PulseAudio interaction for HDMI support(See my posts on the ALSA mailing list). On my Intel IbexPeak, there's only one HDMI device, but it is detected even though there's no cable connected. I can play audio on HDMI even if I unplug the cable. I would assume this is the same case for your Nvidia system, even if you hacked the profile definition, you would end-up with a set of detected profiles, but only one may work and only if there's a cable connected. That would beat any audio policy/device manager/intelligent routing logic. Sure, but I think my issue is pretty orthogonal to yours. What I'm talking about is that pulseaudio is incapable of ever sending audio to anything other than the default device/subdevice within a card, irrespective of whether a cable is plugged in and signal being transmitted. What you're talking about is allowing pulseaudio to determine whether a cable is plugged in and a signal being transmitted, and dynamically hide/unhide (or enabled/disable) those sinks based on that information. Incidentally, that information is already available to the ALSA driver; on HDMI, the PresenceDetect and ELD Valid bits in /proc/asound/card*/eld* encode the information pulseaudio would need to use for this. However, I'm not completely convinced that pulseaudio *should* dynamically hide/unhide the audio sinks. I suppose in an automatic mode, pulseaudio should simply send audio to whichever sink makes sense, and an HDMI sink that's not transmitting a signal perhaps doesn't make sense. However, I really don't like the idea of not having any kind of manual override which simply says I want my audio to come out this HW device that I know I have no matter what, even if there's some reason it won't work, like no signal being transmitted... But again, that discussion is something outside the scope of this thread. For HDMI, I think the right solution is to have some ALSA hot-plug event trapped by PulseAudio. Otherwise it's going to be really confusing for users. With Nvidia hardware, they would have to manually select which profile they want to play on, when they will want to play on the device that has a cable attached. Along the same lines, there's currently no means to know how many channels the receiver supports. We could add HDMI stereo/surround40/surround51/surround 71 profiles, but this is the least user-friendly solution. Again we do need some hot-plug event to set the relevant number of channels for the PulseAudio HDMI sink based on ELD/EDID information. -- nvpublic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ALSA sink enumeration and multiple devices/subdevices
pl bossart wrote: What I'm talking about is that pulseaudio is incapable of ever sending audio to anything other than the default device/subdevice within a card, irrespective of whether a cable is plugged in and signal being transmitted. ok, I am not sure I understand why there are several devices in the first place. Can you elaborate on what these 4 devices are? Can all these devices be used concurrently with different streams,ie up to 4 independent HDMI outputs/cables? Or is each device stereo only, and the hardware will multiplex channel pairs on the same HDMI link? The GPU has four[1] sets of DVI/HDMI/DP pins on the package, and on any given board, some subset of these is routed out to actual connectors. For example, there may be two DVI ports and an HDMI port. [1] I assume since there are 4 HD audio codecs... For each of these sets of pins, and hence each connector on the board, there is an HD audio codec. If/when a video signal is being transmitted across a given connector, the corresponding HD audio codec may be used to transmit audio along with that signal. There is a 1:1 mapping between HD audio codec ID (and hence ALSA device-ID) and physical connector. The exact mapping probably varies from board to board depending on OEM design. Note that right now, these 4 HD audio codecs are arranged as 1 ALSA card with 4 devices contained within. I could imagine this could also be exposed as 1 ALSA card with 1 ALSA device and 4 ALSA subdevices, depending on HD audio node configuration. In practice, NVIDIA GPUs only support sending video signals over at most two of these connectors at once, and hence the HD audio controller only allows two audio streams to be configured at once. The exact set used can be dynamically reconfigured by changing xorg.conf or using NVIDIA's tools to manipulate a running X server; similar to xrandr. Each of these audio streams may be up to multi-channel, depending on TV or receiver capabilities. In other words, there aren't 4 stereo-only streams that get mapped into a single video stream to make a single multi- channel stream. I could imagine someone wanting to use pulseaudio to send two entirely different audio streams to two different monitors at the same time. I imagine (complete guess) that Intel's and AMD's HDMI support works similarly, although the number of separate ALSA devices (or subdevices), the maximum number of streams that can operate at once, and the maximum capabilities of each stream (e.g. stereo vs. multi-channel) probably differ. In other words, this architecture is somewhat driven by Intel's HD audio codec architecture. That said, I suppose this could be exposed as 1 PCI device, and hence 1 ALSA card, per video connector. That'd be a lot of extra HW to put on the chip though. -- nvpublic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pavucontrol. Also Nvidia HDMI
Christopher K. wrote at Monday, February 21, 2011 5:46 PM: ... My second question is about sound over hdmi with an Nvidia GTX460 (NVC4 /GF104 family): aplay -L gives hdmi:CARD=NVidia,DEV=0 - pcm3p/ hdmi:CARD=NVidia,DEV=1 - pcm7p/ hdmi:CARD=NVidia,DEV=2 - pcm8p/ hdmi:CARD=NVidia,DEV=3 - pcm9p/ but only pcm7p actually does anything. For some background, please see: ftp://download.nvidia.com/XFree86/gpu-hdmi-audio-document/gpu-hdmi-audio.html -- nvpublic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] EDID-like data for audio: Port correlation between ALSA and X
(starting a new cross-mailing-list thread following some small discussion on this topic on alsa-devel) Background: Many recent graphics cards support sending an audio stream over HDMI or DisplayPort. This is supported by an HD-audio controller built into the graphics card. It'd be nice if configuration tools could easily determine which ALSA devices correspond to which X displays. Current implementation details: The X driver reads the EDID from the display, reformats it as an ELD (EDID-Like Data), as specified by the Intel HD-audio specification, and somehow communicates this into the HD-audio controller that's embedded into the graphics card, using a card-specific mechanism. The HD-audio controller then communicates the ELD to the driver in a standard-specified manner: The HW triggers an unsolicited response to notify the ALSA driver of a change in the data, and then the ALSA driver reads the ELD data using HD-audio commands (verbs). Finally, the eventual idea is that user-space applications will be able to read the ELD data from the ALSA driver for each PCM. In the HD-audio controller, there is a pin widget for each video output (HDMI port, DP port). ELD data is associated with a specific pin widget. ALSA creates a single PCM or audio device per pin widget. New discussion: We need some way of tying pin widgets or ALSA PCMs to the X display path that the audio data will be merged into. Option A: We can pass some X-specific data in the ELD. The ELD contains an 8-byte Port_ID field for this purpose. The display driver is supposed to fill this with some meaningful data, and ALSA (or an application) is supposed to interpret the field. Some possibilities for this field are: A1) An XRandR property, such as ConnectorNumber or Output. To me, this seems the simplest option overall; the X driver already has access to this information, so it should be fairly easy to place it into the ELD. The only downside here is that the NVIDIA binary driver doesn't currently implement recent XRandR versions, so we probably couldn't do this right now. A2) NVIDIA's graphics driver fills this field with an internal display ID value, which I believe is usable without our NV-CTRL X extension. This obviously isn't ideal for applications interpreting this data, since the format isn't cross-vendor. Applications don't want to interpret the ELD in N different ways. Option B: We can invent some X/XRandR property that refers to some ALSA HW or SW property. Applications can then enumerate this X/XRandR property for all outputs, and use that data to access the appropriate ALSA device. That data could be: B1) ALSA PCM name (e.g. hw:1,3). While perhaps technically feasible, it'd be pretty painful to determine this from the X driver. Sysfs parsing of ALSA-related data would probably work, but this kind of thing would be better done elsewhere than the X driver, especially if the ELD handoff is implemented in the kernel by a KMS driver. B2) HD-audio controller pin widget ID. This requires the X driver to know the internal architecture of the HD-audio controller. While technically perhaps not too hard, it'd most likely mean maintaining tables of audio-related data in the X driver, which is probably not something we'd want to do. Equally, the pin widget ID might not be the most useful thing to an application. AFAIK, ALSA doesn't have an API for exposing this information at present, except through user-oriented debug files in /proc. Does anyone see any other options? Do people agree that option A1 is the best? Related issues: There are issues correlating ALSA and X data such as XRandR connector numbers in the face of multiple X servers, remote X servers, VT-switching, etc. However, I believe most of these issues need to be solved outside the context of this discussion anyway, and hence probably don't affect this discussion much. Probably, PulseAudio already interfaces with DeviceKit or SomethingKit to solve some of these issues? Thanks for reading! -- nvpublic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
