[FEATURE] Add second playback PCM device for HDA hardware with different stream id

[perexg]

For Realtek codecs, we need to split Speaker and Headphone (thus use both analog DAC outputs separately). The limitation (on some hardware) is that the speaker is usually connected to one DAC with a fixed rate (48000Hz) and the headphones to other (more rates up to 192kHz are available). Note that the fixed rate for speaker is defined mostly by hardware behind the codec (analog amplifiers) which may be preset by BIOS and Linux drivers are not able to touch them (missing docs/code) at the moment.

The generic driver may create an "Alt Analog" device like:

Card 0: PCH [HDA Intel PCH], device 0: ALC285 Analog [ALC285 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 2: ALC285 Alt Analog [ALC285 Alt Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Unfortunately, this feature is missing for the SOF HDA driver.

@mrhpearson : FYI

[plbossart]

@perexg The main reason why we have a single stream is that most codecs have INTERNAL switching between speakers and headphone. We would need to have information to detect and disable this switch, which is usually configured by obscure platform-specific verbs

We looked at this for @singalsu 's planned addition of endpoint-specific processing and we couldn't figure out how to add support for independent streams.

Also it's not clear if the 'Alt Analog' is actually used by any userspace apps?

Adding @kv2019i @ranj063 @ujfalusi for more comments.

[perexg]

Thank you for this information. I am actually evaluating a way to add support for 192kHz playback through the headphone DAC. With legacy driver, it works with indep_hp hint (and some patches to move the Alt PCM to assigned HP jack and standard PCM to assigned Speaker DAC). I assume that the second PCM will be activated through UCM when the 'Independent HP' control exists and can be set to 'Enabled' state.

Perhaps, there may be a different solution for this issue, but this one looked like a simplest one. The key is that the rate for DACs is shared thus fixed at the moment. Realtek sets this rate to 48kHz in BIOS, because the Linux driver is not able to handle this split properly.

[plbossart]

The problem with the 192kHz stuff is that it needs to be used as an 'exclusive' endpoint where the high-resolution content is played as is without mixers/processing on the host. That's how it's done on Windows. That removes the need to sample-rate convert all notifications/beeps, which is a real hassle. If there is processing/mixer on this high-resolution stream then there will be a power hit for 'regular' applications, and it's not possible to switch dynamically (same issue at 48/44.1kHz really).

[perexg]

Ok, can SOF driver just create second "legacy"/"direct" playback stream with different stream id on the HDA bus without DSP in the middle ? We can configure the codec DAC (assign the stream id) as we need on demand.

The resampling is handled in the sound server on linux for the desktop apps.

[plbossart]

For Intel platfoms, firmware is either not used (snd-hda-intel) or it controls all of the HDaudio streams. we don't have the ability to selectively use the DSP for specific streams and let the host bypass the DSP for other streams.

[ranj063]

For Intel platfoms, firmware is either not used (snd-hda-intel) or it controls all of the HDaudio streams. we don't have the ability to selectively use the DSP for specific streams and let the host bypass the DSP for other streams.

@plbossart just thinking out loud, can chain DMA help in this case?

[perexg]

The rate list is set by topology ? I don't see limiting in the SOF HDA driver for the analog paths based on codec capabilities. The snd_hdac_query_supported_pcm is used only for hdmi.

I found it. snd_hda_codec_parse_pcms call in hdac_hda.c

[plbossart]

For Intel platfoms, firmware is either not used (snd-hda-intel) or it controls all of the HDaudio streams. we don't have the ability to selectively use the DSP for specific streams and let the host bypass the DSP for other streams.

@plbossart just thinking out loud, can chain DMA help in this case?

no, with the chain DMA the stream is still in de-coupled mode.

technically the HDaudio DMA can be programmed as coupled or de-coupled at any time, but it leads to another well-known resource management issue, specifically the DSP memory.

when a DMA is in coupled mode, the hardware uses the DSP memory as a FIFO.
when a DMA is in de-coupled mode, the firmware assumes all the memory is available.

there is no mechanism to tell the firmware what is used by hardware, and since it can be decided at run-time, the firmware would need to write-off the worst-case memory use by the hardware. That's likely to impact product capabilities, so not going to happen.

We could assume that some of the streams are available for coupled-mode only, but we would need to special-case some streams, e.g. 1..4, and require additional changes in kernel and firmware. It's possible technically but it's just not going to happen because of other priorities and shepherding cats.

[perexg]

Ok, at the moment, I just need input if the alternate PCM stream is an option also for SOF or I should dig to find another way to handle the fixed rate constraint for some codec DACs. We can probably detach "unwanted" codec DACs from the active stream id (tag) on HDA codec/bus to not receive a stream with different rate to avoid a wrong output. The question is which stream id (tag) should be used in this situation. Probably an unused one.

EDIT: But in this case, we need to create a notification for the sound server that the rate list changed when speaker / headphone output is switched. We can use probably UCM conflicting device list.

[plbossart]

There's nothing specific about SOF that would prevent the use of an alternate stream. We have support for more DMAs than we really need. If you look at Chrome devices, they all have separate PCM devices for headphone and speakers so that's a well-known configuration.

The difficult point is detecting that this alternate path exists, and the connection with the topology, i.e. if we expose an alternate stream in the topology and it's not physically enabled in the codec then we have a problem at run-time.

Ideally we would need a 'platform' layer that would tell the topology which streams are supported or not, and disable the 'alternate path' somehow.

[plbossart]

I should also add that the direction of travel for SoundWire-based devices is also to have independent 'Functions' for jack and amplifiers, the mutually exclusive use of jack/amps is a thing of the past.
Retrofitting HDaudio to use that model is a tough job though, there are so many variants and configurations that we can almost guarantee some devices will not have the right settings.

[perexg]

if we expose an alternate stream in the topology and it's not physically enabled in the codec then we have a problem at run-time.

I think that you're thinking about a more complex model. I think that it's possible to have the alternate stream which may be used only when the DAC is configured to consume samples from the HDA bus with the proper stream id (tag). When the alternate PCM cannot be used, the open syscall may return -EBUSY or -ENXIO error to tell user space that this PCM stream is not usable. Eventually, we can create a Jack status like for HDMI for this PCM using the ALSA control API. The code which is handling the codec configuration should be able to react on this in struct hda_pcm_stream -> ops.open callback (hda_generic.c).

When I'm looking to the ASoC / SOF code, "Alt Analog" PCM components are ready in the drivers, so it seems really like a missing topology PCM configuration thing. Could you provide signed topologies sof-hda-generic-*.tplg with Alt Analog Out for tests?

[plbossart]

@perexg I was talking about a limitation of the topology framework.

The machine driver and the topology need to be aligned, and the endpoint listed in a topology file MUST be matching a BackEnd dailink created by the machine driver. The other way around is fine, it's perfectly fine to have an extra BE dailink that's not used by the topology.

It's not practical to issue one topology for each possible configuration. We already have this problem with 2ch and 4ch DMIC, every time we have a new variation that's yet another topology that needs to be used. That's not sustainable.