[pulseaudio-discuss] Missing second HDA playback device

[Jon Smirl]

On Sun, Jan 18, 2009 at 11:01 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Sun, 18.01.09 10:22, Jon Smirl (jonsmirl at gmail.com) wrote:
>
>> I definitely have two playback devices:
>>
>> jonsmirl at terra:/etc$ hal-device | grep playback
>> 28: udi = '/org/freedesktop/Hal/devices/pci_8086_284b_alsa_playback_1'
>>   info.udi = '/org/freedesktop/Hal/devices/pci_8086_284b_alsa_playback_1'
>>  (string)
>>   alsa.type = 'playback'  (string)
>> 29: udi = '/org/freedesktop/Hal/devices/pci_8086_284b_alsa_playback_0'
>>   info.udi = '/org/freedesktop/Hal/devices/pci_8086_284b_alsa_playback_0'
>>  (string)
>>   alsa.type = 'playback'  (string)
>> jonsmirl at terra:/etc$
>>
>> playback_0 is analog out
>> playback_1 is SPDIF out
>>
>> module module-hal-detect does not load the second one.
>
> Things are not always as easy as they might seem.
>
> Currently ALSA exports no way to find out what ways to access the
> audio devices are exclusive and what ways are not. Also it is
> generally not defined what an ALSA "subdevice" actually refers to. In
> your case #0 and #1 are each independant PCMs as it

If HAL/ALSA create two sink devices couldn't you make both of theses
sinks visible in pulse and then let me manually pick the one I want?
The confusing point here is that I had to manually create sink 1 in
pulse.

D: module-hal-detect.c: Not loaded device
/org/freedesktop/Hal/devices/pci_8086_284b_alsa_playback_1

What criteria did pulse use for suppressing this device? Did it check
if it was SPDIF and then suppress it on that basis?

> appears. However for other cards #1 might be the front speakers of a
> suround setup, #1 the rear speakers and so on. The actual logic
> mapping of these subdevices is done by the device strings "front:",
> "iec958:", "surround51:" and so on in ALSA userspace. Also, on some
> devices you can either do 7.1 playback and no recording, or you can do
> stereo duplex -- but you cannot do 7.1 playback and stereo
> recording. Similar limitations can apply with the combination of SPDIF
> and other ways to access the audio device for playback/capturing.
>
> There is just no way right now to automatically discover the
> subdevices we can use independantly and which ones we cannot.
>
> In current git there are the beginnings of a logic that autoprobes the
> available "profiles" and their possible combinations and then allows
> to switch between them dynamically during runtime. This is still very
> much incomplete however. (Load module-alsa-card into your server
> instead of module-alsa-source/-sink and it will show you the possible
> configs of your card when you do an "ls-cards" in pacmd).
>
> Doing this autoprobing is ugly and slow, but the easiest way for now
> to overcome this limitation in the underlying ALSA layers for now.
>
> In summary: supporting multiple subdevices and SPDIF like this is much
> more difficult then it might appear, but I am working on it.
>
> Also see #139.
>
> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net         ICQ# 11060553
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>



-- 
Jon Smirl
jonsmirl at gmail.com