Dynamic HDMI PCM creation

Dynamic HDMI PCM creation

[Takashi Iwai]

Hi David,

as we discussed at Plumbers, I tried some hack to create/delete
HDMI/DP PCM stream per hotplug/unplug.  Test patches are found in
sound-unstable git tree topic/hdmi-dynamic-pcm branch
  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git

The patches are all small and easy, but it's still in a pretty rough
cut.  It won't handle some cases, e.g. unplug during suspend, or
such, I'm afraid.  After all, it's just a test.

With these patches, the PCM device appears and disappears properly
upon HDMI/DP hotplug/unplug on my system.  On mine, it appears as
/dev/snd/pcmC0D8 as it's an Intel on-board.  So far, so good.

Now the problem is that PA gets confused when this happens.  It can
switch to HDMI/DP, but then the analog output disappears from PA's
profile.  You cannot switch back to analog output after that, even
after you unplug HDMI/DP cable.

Or, it might be my PA version...  I'll check newer one.
But it'd be good if you also check in your side.


thanks,

Takashi

Re: Dynamic HDMI PCM creation

[David Henningsson]

On 09/10/2012 03:01 PM, Takashi Iwai wrote:
> Hi David,
>
> as we discussed at Plumbers, I tried some hack to create/delete
> HDMI/DP PCM stream per hotplug/unplug.  Test patches are found in
> sound-unstable git tree topic/hdmi-dynamic-pcm branch
>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
>
> The patches are all small and easy, but it's still in a pretty rough
> cut.  It won't handle some cases, e.g. unplug during suspend, or
> such, I'm afraid.  After all, it's just a test.
>
> With these patches, the PCM device appears and disappears properly
> upon HDMI/DP hotplug/unplug on my system.  On mine, it appears as
> /dev/snd/pcmC0D8 as it's an Intel on-board.  So far, so good.
>
> Now the problem is that PA gets confused when this happens.  It can
> switch to HDMI/DP, but then the analog output disappears from PA's
> profile.  You cannot switch back to analog output after that, even
> after you unplug HDMI/DP cable.
>
> Or, it might be my PA version...  I'll check newer one.
> But it'd be good if you also check in your side.

Hmm.

As you probably know, PA does extensively test opening device strings at 
startup, and then never again.
As such, I can understand that PA gets confused if you start adding and 
removing PCM devices, because that changes whether and how different 
device strings can be opened.

Looking forward, with HDMI, it's a reality that this will happen. And 
therefore we need to deal with it in PA somehow, even if this is 
non-trivial. So the first question would be - what notification 
mechanism should we have to trigger "reprobing"? Are we recommended to 
use the jack detection kcontrol API, or is there something else that 
tells us that suddenly "hdmi:1,2" will actually be worth trying again?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Dynamic HDMI PCM creation

[Takashi Iwai]

At Mon, 17 Sep 2012 12:15:23 +0200,
David Henningsson wrote:
> 
> On 09/10/2012 03:01 PM, Takashi Iwai wrote:
> > Hi David,
> >
> > as we discussed at Plumbers, I tried some hack to create/delete
> > HDMI/DP PCM stream per hotplug/unplug.  Test patches are found in
> > sound-unstable git tree topic/hdmi-dynamic-pcm branch
> >    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
> >
> > The patches are all small and easy, but it's still in a pretty rough
> > cut.  It won't handle some cases, e.g. unplug during suspend, or
> > such, I'm afraid.  After all, it's just a test.
> >
> > With these patches, the PCM device appears and disappears properly
> > upon HDMI/DP hotplug/unplug on my system.  On mine, it appears as
> > /dev/snd/pcmC0D8 as it's an Intel on-board.  So far, so good.
> >
> > Now the problem is that PA gets confused when this happens.  It can
> > switch to HDMI/DP, but then the analog output disappears from PA's
> > profile.  You cannot switch back to analog output after that, even
> > after you unplug HDMI/DP cable.
> >
> > Or, it might be my PA version...  I'll check newer one.
> > But it'd be good if you also check in your side.
> 
> Hmm.
> 
> As you probably know, PA does extensively test opening device strings at 
> startup, and then never again.
> As such, I can understand that PA gets confused if you start adding and 
> removing PCM devices, because that changes whether and how different 
> device strings can be opened.
> 
> Looking forward, with HDMI, it's a reality that this will happen. And 
> therefore we need to deal with it in PA somehow, even if this is 
> non-trivial. So the first question would be - what notification 
> mechanism should we have to trigger "reprobing"? Are we recommended to 
> use the jack detection kcontrol API, or is there something else that 
> tells us that suddenly "hdmi:1,2" will actually be worth trying again?

The kcontrol API is already implemented, so it's good to support for
it.

If we do check the dynamic PCM probing for HDMI, I'd propose for
adding a new PCM class SNDRV_PCM_CLASS_HDMI or such, and set this
class in patch_hdmi.c.  Then PA can check the sysfs entry and
decide whether to reprobe the HDMI entry.


Takashi

Re: Dynamic HDMI PCM creation

[Jaroslav Kysela]

Date 17.9.2012 12:40, Takashi Iwai wrote:
> At Mon, 17 Sep 2012 12:15:23 +0200,
> David Henningsson wrote:
>>
>> On 09/10/2012 03:01 PM, Takashi Iwai wrote:
>>> Hi David,
>>>
>>> as we discussed at Plumbers, I tried some hack to create/delete
>>> HDMI/DP PCM stream per hotplug/unplug.  Test patches are found in
>>> sound-unstable git tree topic/hdmi-dynamic-pcm branch
>>>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
>>>
>>> The patches are all small and easy, but it's still in a pretty rough
>>> cut.  It won't handle some cases, e.g. unplug during suspend, or
>>> such, I'm afraid.  After all, it's just a test.
>>>
>>> With these patches, the PCM device appears and disappears properly
>>> upon HDMI/DP hotplug/unplug on my system.  On mine, it appears as
>>> /dev/snd/pcmC0D8 as it's an Intel on-board.  So far, so good.
>>>
>>> Now the problem is that PA gets confused when this happens.  It can
>>> switch to HDMI/DP, but then the analog output disappears from PA's
>>> profile.  You cannot switch back to analog output after that, even
>>> after you unplug HDMI/DP cable.
>>>
>>> Or, it might be my PA version...  I'll check newer one.
>>> But it'd be good if you also check in your side.
>>
>> Hmm.
>>
>> As you probably know, PA does extensively test opening device strings at 
>> startup, and then never again.
>> As such, I can understand that PA gets confused if you start adding and 
>> removing PCM devices, because that changes whether and how different 
>> device strings can be opened.
>>
>> Looking forward, with HDMI, it's a reality that this will happen. And 
>> therefore we need to deal with it in PA somehow, even if this is 
>> non-trivial. So the first question would be - what notification 
>> mechanism should we have to trigger "reprobing"? Are we recommended to 
>> use the jack detection kcontrol API, or is there something else that 
>> tells us that suddenly "hdmi:1,2" will actually be worth trying again?
> 
> The kcontrol API is already implemented, so it's good to support for
> it.

You refer ELD interface?

> If we do check the dynamic PCM probing for HDMI, I'd propose for
> adding a new PCM class SNDRV_PCM_CLASS_HDMI or such, and set this

I'm not sure if HDMI devices are different than others. For example, for
digital S/PDIF inputs, the input stream parameters can change too
including the signal presence. It would be good to propose one mechanism
for all plug-and-play wiring schemas.

> class in patch_hdmi.c.  Then PA can check the sysfs entry and
> decide whether to reprobe the HDMI entry.

Please, could you describe more, why we need to have dynamic PCMs for
HDMI? I would prefer to have just a notification, if the cable is
connected and the PCM layer is ready (ELD stuff). Also, if some physical
connectors are not used on some hardware, they should/may be blacklisted
so the driver won't create PCM devices for them.

Also, the stream parameter checks seems missing in the HDMI PCM
implementation. It may be good to fail with -EIO when the cable is not
connected or unplugged and, eventually, if the end-point PCM parameters
are changed.

If the dynamic HDMI PCMs are implemented, are the device numbers fixed
(related) to physical connectors?

					Thanks,
						Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: Dynamic HDMI PCM creation

[Takashi Iwai]

At Mon, 17 Sep 2012 13:03:56 +0200,
Jaroslav Kysela wrote:
> 
> Date 17.9.2012 12:40, Takashi Iwai wrote:
> > At Mon, 17 Sep 2012 12:15:23 +0200,
> > David Henningsson wrote:
> >>
> >> On 09/10/2012 03:01 PM, Takashi Iwai wrote:
> >>> Hi David,
> >>>
> >>> as we discussed at Plumbers, I tried some hack to create/delete
> >>> HDMI/DP PCM stream per hotplug/unplug.  Test patches are found in
> >>> sound-unstable git tree topic/hdmi-dynamic-pcm branch
> >>>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
> >>>
> >>> The patches are all small and easy, but it's still in a pretty rough
> >>> cut.  It won't handle some cases, e.g. unplug during suspend, or
> >>> such, I'm afraid.  After all, it's just a test.
> >>>
> >>> With these patches, the PCM device appears and disappears properly
> >>> upon HDMI/DP hotplug/unplug on my system.  On mine, it appears as
> >>> /dev/snd/pcmC0D8 as it's an Intel on-board.  So far, so good.
> >>>
> >>> Now the problem is that PA gets confused when this happens.  It can
> >>> switch to HDMI/DP, but then the analog output disappears from PA's
> >>> profile.  You cannot switch back to analog output after that, even
> >>> after you unplug HDMI/DP cable.
> >>>
> >>> Or, it might be my PA version...  I'll check newer one.
> >>> But it'd be good if you also check in your side.
> >>
> >> Hmm.
> >>
> >> As you probably know, PA does extensively test opening device strings at 
> >> startup, and then never again.
> >> As such, I can understand that PA gets confused if you start adding and 
> >> removing PCM devices, because that changes whether and how different 
> >> device strings can be opened.
> >>
> >> Looking forward, with HDMI, it's a reality that this will happen. And 
> >> therefore we need to deal with it in PA somehow, even if this is 
> >> non-trivial. So the first question would be - what notification 
> >> mechanism should we have to trigger "reprobing"? Are we recommended to 
> >> use the jack detection kcontrol API, or is there something else that 
> >> tells us that suddenly "hdmi:1,2" will actually be worth trying again?
> > 
> > The kcontrol API is already implemented, so it's good to support for
> > it.
> 
> You refer ELD interface?

No, the jack detection kcontrols.

> > If we do check the dynamic PCM probing for HDMI, I'd propose for
> > adding a new PCM class SNDRV_PCM_CLASS_HDMI or such, and set this
> 
> I'm not sure if HDMI devices are different than others. For example, for
> digital S/PDIF inputs, the input stream parameters can change too
> including the signal presence. It would be good to propose one mechanism
> for all plug-and-play wiring schemas.

In that case, it's fine.  PA has no special treatment for such
devices.  (Or, it might face the same problem when it's listed as
"spdif".)

 From what I've seen, there is no big issue in the driver side at all
about dynamic creation/deletion of PCM streams.  All the problem is
about PA, and PA _is_ the reason we need a better hotplug PCM
handling.  So, you cannot think of any solution without considering
how PA would behave.

> > class in patch_hdmi.c.  Then PA can check the sysfs entry and
> > decide whether to reprobe the HDMI entry.
> 
> Please, could you describe more, why we need to have dynamic PCMs for
> HDMI?

It's not about "have to".  It's a possible solution for feasible HDMI
hotplug handling we've discussed since the last year's audio BoF.
As the same topic came up in Plumbers, I stated the patch just as a
proof-of-concept.

> I would prefer to have just a notification, if the cable is
> connected and the PCM layer is ready (ELD stuff). Also, if some physical
> connectors are not used on some hardware, they should/may be blacklisted
> so the driver won't create PCM devices for them.

Using kcontrol notifier is the current solution indeed.  But the whole
coding is missing in PA side, so far.  OTOH, PA has already the
handling of dynamic PCM device creation/deletion (e.g. for
USB-audio).  So, it can be more natural to provide the dynamic PCM
from the kernel for HDMI, too.  The patch was posted to evaluate
that.

> Also, the stream parameter checks seems missing in the HDMI PCM
> implementation. It may be good to fail with -EIO when the cable is not
> connected or unplugged and, eventually, if the end-point PCM parameters
> are changed.

Well, then PA will face a similar problem like this patch.
PA probes the available HDMI devices at start up.  If the device
returns an error -EIO at open when unplugged, PA will continue to
ignore the device.  It's what I understand.  I might be wrong about
that in the recent PA versions, though.

> If the dynamic HDMI PCMs are implemented, are the device numbers fixed
> (related) to physical connectors?

In my patch, it's still fixed.  Just creation is delayed and the slot
is kept.  But it's just my patch, and it doesn't correlate directly
with the idea of dynamic creation/deletion of PCM devices.


Takashi

Re: Dynamic HDMI PCM creation

[Jaroslav Kysela]

Date 17.9.2012 13:46, Takashi Iwai wrote:
> At Mon, 17 Sep 2012 13:03:56 +0200,
> Jaroslav Kysela wrote:
>>
>> Date 17.9.2012 12:40, Takashi Iwai wrote:
>>> At Mon, 17 Sep 2012 12:15:23 +0200,
>>> David Henningsson wrote:
>>>>
>>>> On 09/10/2012 03:01 PM, Takashi Iwai wrote:
>>>>> Hi David,
>>>>>
>>>>> as we discussed at Plumbers, I tried some hack to create/delete
>>>>> HDMI/DP PCM stream per hotplug/unplug.  Test patches are found in
>>>>> sound-unstable git tree topic/hdmi-dynamic-pcm branch
>>>>>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
>>>>>
>>>>> The patches are all small and easy, but it's still in a pretty rough
>>>>> cut.  It won't handle some cases, e.g. unplug during suspend, or
>>>>> such, I'm afraid.  After all, it's just a test.
>>>>>
>>>>> With these patches, the PCM device appears and disappears properly
>>>>> upon HDMI/DP hotplug/unplug on my system.  On mine, it appears as
>>>>> /dev/snd/pcmC0D8 as it's an Intel on-board.  So far, so good.
>>>>>
>>>>> Now the problem is that PA gets confused when this happens.  It can
>>>>> switch to HDMI/DP, but then the analog output disappears from PA's
>>>>> profile.  You cannot switch back to analog output after that, even
>>>>> after you unplug HDMI/DP cable.
>>>>>
>>>>> Or, it might be my PA version...  I'll check newer one.
>>>>> But it'd be good if you also check in your side.
>>>>
>>>> Hmm.
>>>>
>>>> As you probably know, PA does extensively test opening device strings at 
>>>> startup, and then never again.
>>>> As such, I can understand that PA gets confused if you start adding and 
>>>> removing PCM devices, because that changes whether and how different 
>>>> device strings can be opened.
>>>>
>>>> Looking forward, with HDMI, it's a reality that this will happen. And 
>>>> therefore we need to deal with it in PA somehow, even if this is 
>>>> non-trivial. So the first question would be - what notification 
>>>> mechanism should we have to trigger "reprobing"? Are we recommended to 
>>>> use the jack detection kcontrol API, or is there something else that 
>>>> tells us that suddenly "hdmi:1,2" will actually be worth trying again?
>>>
>>> The kcontrol API is already implemented, so it's good to support for
>>> it.
>>
>> You refer ELD interface?
> 
> No, the jack detection kcontrols.

Yep, ok.

>>> If we do check the dynamic PCM probing for HDMI, I'd propose for
>>> adding a new PCM class SNDRV_PCM_CLASS_HDMI or such, and set this
>>
>> I'm not sure if HDMI devices are different than others. For example, for
>> digital S/PDIF inputs, the input stream parameters can change too
>> including the signal presence. It would be good to propose one mechanism
>> for all plug-and-play wiring schemas.
> 
> In that case, it's fine.  PA has no special treatment for such
> devices.  (Or, it might face the same problem when it's listed as
> "spdif".)
> 
>  From what I've seen, there is no big issue in the driver side at all
> about dynamic creation/deletion of PCM streams.  All the problem is
> about PA, and PA _is_ the reason we need a better hotplug PCM
> handling.  So, you cannot think of any solution without considering
> how PA would behave.

I believe we should do it in one consistent way. The kctl wire status
report / jack presence report should be sufficient to detect, if the PCM
device can be re-probed. I don't understand why to do more work in the
driver, because the user space application is broken or lacking a feature.

>>> class in patch_hdmi.c.  Then PA can check the sysfs entry and
>>> decide whether to reprobe the HDMI entry.
>>
>> Please, could you describe more, why we need to have dynamic PCMs for
>> HDMI?
> 
> It's not about "have to".  It's a possible solution for feasible HDMI
> hotplug handling we've discussed since the last year's audio BoF.
> As the same topic came up in Plumbers, I stated the patch just as a
> proof-of-concept.
> 
>> I would prefer to have just a notification, if the cable is
>> connected and the PCM layer is ready (ELD stuff). Also, if some physical
>> connectors are not used on some hardware, they should/may be blacklisted
>> so the driver won't create PCM devices for them.
> 
> Using kcontrol notifier is the current solution indeed.  But the whole
> coding is missing in PA side, so far.  OTOH, PA has already the
> handling of dynamic PCM device creation/deletion (e.g. for
> USB-audio).  So, it can be more natural to provide the dynamic PCM
> from the kernel for HDMI, too.  The patch was posted to evaluate
> that.

I think that USB-Audio is a different thing. Our driver creates new card
for a newly plugged USB hardware and it seems that PA supports only
dynamic card handling, not dynamic device handling.

>> Also, the stream parameter checks seems missing in the HDMI PCM
>> implementation. It may be good to fail with -EIO when the cable is not
>> connected or unplugged and, eventually, if the end-point PCM parameters
>> are changed.
> 
> Well, then PA will face a similar problem like this patch.
> PA probes the available HDMI devices at start up.  If the device
> returns an error -EIO at open when unplugged, PA will continue to
> ignore the device.  It's what I understand.  I might be wrong about
> that in the recent PA versions, though.

I believe that PA should be fixed. For me, it seems unlogical to feed a
stream to hardware which is silent, because the stream parameters do not
match or the wire is not connected.

>> If the dynamic HDMI PCMs are implemented, are the device numbers fixed
>> (related) to physical connectors?
> 
> In my patch, it's still fixed.  Just creation is delayed and the slot
> is kept.  But it's just my patch, and it doesn't correlate directly
> with the idea of dynamic creation/deletion of PCM devices.

OK, fine.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: Dynamic HDMI PCM creation

[David Henningsson]

[added pulseaudio-discuss to cc]

On 09/17/2012 02:20 PM, Jaroslav Kysela wrote:
> Date 17.9.2012 13:46, Takashi Iwai wrote:
>>> I would prefer to have just a notification, if the cable is
>>> connected and the PCM layer is ready (ELD stuff). Also, if some physical
>>> connectors are not used on some hardware, they should/may be blacklisted
>>> so the driver won't create PCM devices for them.

It might be that we could send a snd_ctl_notify on the ELD kcontrol. 
Would that make sense?

>> Using kcontrol notifier is the current solution indeed.  But the whole
>> coding is missing in PA side, so far.  OTOH, PA has already the
>> handling of dynamic PCM device creation/deletion (e.g. for
>> USB-audio).  So, it can be more natural to provide the dynamic PCM
>> from the kernel for HDMI, too.  The patch was posted to evaluate
>> that.
>
> I think that USB-Audio is a different thing. Our driver creates new card
> for a newly plugged USB hardware and it seems that PA supports only
> dynamic card handling, not dynamic device handling.

This is correct. PA supports dynamic cards, not dynamic devices on a 
card. Cards are much simpler because they are always independent of each 
other.

Another question PA needs to deal with is, when this new HDMI PCM device 
is plugged in, what other streams can coexist with this new HDMI stream? 
What if we have an analog + HDMI combined card, but the controller only 
supports one stream to either of them? In that case, we can not even 
probe the HDMI device without disturbing the stream potentially being 
played back through analog.

Brainstorming idea for PA developers: However, if combined analog + HDMI 
combined cards *always* can play back HDMI and analog independent of 
each other, we could actually try to map them as two different cards in 
PulseAudio. Then that HDMI card could disappear as the HDMI cable is 
unplugged.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Dynamic HDMI PCM creation

[David Henningsson]

On 09/10/2012 03:01 PM, Takashi Iwai wrote:
> Hi David,
>
> as we discussed at Plumbers, I tried some hack to create/delete
> HDMI/DP PCM stream per hotplug/unplug.  Test patches are found in
> sound-unstable git tree topic/hdmi-dynamic-pcm branch
>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
>
> The patches are all small and easy, but it's still in a pretty rough
> cut.  It won't handle some cases, e.g. unplug during suspend, or
> such, I'm afraid.  After all, it's just a test.
>
> With these patches, the PCM device appears and disappears properly
> upon HDMI/DP hotplug/unplug on my system.  On mine, it appears as
> /dev/snd/pcmC0D8 as it's an Intel on-board.  So far, so good.
>
> Now the problem is that PA gets confused when this happens.  It can
> switch to HDMI/DP, but then the analog output disappears from PA's
> profile.  You cannot switch back to analog output after that, even
> after you unplug HDMI/DP cable.
>
> Or, it might be my PA version...  I'll check newer one.

Which PA version are you testing with?

> But it'd be good if you also check in your side.

Trying to figure out what's happening here - could you give the output 
of "pacmd list" both before and after things go wrong, as well as a more 
detailed instruction of what you do in what order?

It seems very strange that a profile would disappear during a card's 
lifetime, so probably it's something different happening.

Also; just to clarify - by default PulseAudio only tries one output + 
one input during its probing, which means that if you have a card which 
has both analog and HDMI outputs, by default it does not support 
simultaneous output to both.
As such it seems that "cannot switch back to analog output" is the 
troublesome point here, so exactly how are you trying to switch back, 
and do you get an error message?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Dynamic HDMI PCM creation

[Raymond Yau]

>
> Another question PA needs to deal with is, when this new HDMI PCM device
is plugged in, what other streams can coexist with this new HDMI stream?
What if we have an analog + HDMI combined card, but the controller only
supports one stream to either of them? In that case, we can not even probe
the HDMI device without disturbing the stream potentially being played back
through analog.

Refer to ICH8 datasheet

Independent Bus Master logic for eight general purpose streams: four input
and four output
Support four external Codecs

does it mean that for those hda codecs which support two independent spdif
, the driver can be configured to support two spdif device instead of
slaves ?

e.g. alc1200

Node 0x11 [Pin Complex] wcaps 0x400300: Mono Digital
  Pincap 0x00000010: OUT
  Pin Default 0x99430140: [Fixed] SPDIF Out at Int ATAPI
    Conn = ATAPI, Color = Unknown
    DefAssociation = 0x4, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Connection: 1
     0x10

Node 0x1e [Pin Complex] wcaps 0x400300: Mono Digital
  Pincap 0x00000010: OUT
  Pin Default 0x01456130: [Jack] SPDIF Out at Ext Rear
    Conn = Optical, Color = Orange
    DefAssociation = 0x3, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Connection: 1
     0x06

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=6a05ac4afa90ac9c38fedd3f6940fe8da5d1fcf6

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=0852d7a654f75d22a3c09fd7da4a3551bbb37740

The other case is audio codec and hdmi codec with NVidia controller

can the hda controller support more than two streams?

**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 0: AD198x Analog [AD198x Analog]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 1: AD198x Digital [AD198x Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0