The shortest necessary path to playing audio on Intel HDA

[VSlezak]

No, it is not. It is completely up to you how you will use Mixer node. If you do not want to use it for mixing, it is fine, then you can look at it as node that simply passes data to next node in path.

[eekee]

Is it necessary? I think software mixer is absolutely competent at this job.

At minimum, I think you'll need a master volume control unless the DAC takes >16-bit samples. If you scale down a 16-bit sample digitally, you reduce the volume but leave the noise floor the same. If the output hardware is well-designed, you'll hear tape hiss -- it sounds exactly the same as a poor-quality tape. If it's badly designed, it'll sound much worse.

[wishedtobe]

At minimum, I think you'll need a master volume control unless the DAC takes >16-bit samples. If you scale down a 16-bit sample digitally, you reduce the volume but leave the noise floor the same. If the output hardware is well-designed, you'll hear tape hiss -- it sounds exactly the same as a poor-quality tape. If it's badly designed, it'll sound much worse.

Hardware amplifier and software mixer are both needed to me. Besides, the problem of hiss won't even be considered by me, as the audio files I loaded in my program are low-sampling-rated.

[wishedtobe]

No, it is not. It is completely up to you how you will use Mixer node. If you do not want to use it for mixing, it is fine, then you can look at it as node that simply passes data to next node in path.

Why do I have to go through this node?

[VSlezak]

Why do I have to go through this node?

You need to initialize all nodes in certain path that are physically connected to each other on sound card. If your sound card do not have Mixer node in path you want to enable, you do not need to initialize it. If your sound card do have Mixer node in path, you have to initialize it. It is up to design created by manufacturer.

Theoretical shortest possible path to play sound consists of two nodes: Audio Output -> Output PIN. However many codecs simply do not have those nodes directly connected, and they insert Mixer node between them, so you have: Audio Output -> Mixer -> Output PIN.

But for testing, QEMU do emulate codec with output through two nodes (Audio Output -> Line Out PIN), so if you want to avoid Mixer node, you can use QEMU.

[wishedtobe]

You need to initialize all nodes in certain path that are physically connected to each other on sound card. If your sound card do not have Mixer node in path you want to enable, you do not need to initialize it. If your sound card do have Mixer node in path, you have to initialize it. It is up to design created by manufacturer.

Theoretical shortest possible path to play sound consists of two nodes: Audio Output -> Output PIN. However many codecs simply do not have those nodes directly connected, and they insert Mixer node between them, so you have: Audio Output -> Mixer -> Output PIN.

But for testing, QEMU do emulate codec with output through two nodes (Audio Output -> Line Out PIN), so if you want to avoid Mixer node, you can use QEMU.

I have not figured out the general architecture of it. Is that path gained from 0xF02? Or 0xF00-4?

[VSlezak]

Every node contains list of nodes it has physical connection to, in sense, that it takes data from them. For example Output Pin may have node Audio Output in his connection list, because it takes data from it.

To get connection list you at first need to get informations about this connection list. You can obtain them through verb 0xF00 with data 0x0E (Connection List Length). First seven bits contains number of nodes in list. Eight bit identifies type of entries in connection list (0 = short form, 1 = long form). Short form means that every entry is 1 byte long and long form that it is 2 bytes long.

Content of connection list can be obtained through verb 0xF02. As data you provide index to entries you want to obtain. Here is what specification says about computing this index:

The requested index n is zero based. If the Long Form bit of the Connection List Length parameter
(refer to Section 7.3.4.11) is 1, n must be even, and two long form Connection List entries will be
returned. Therefore, requesting index 0 will return the values at offset 0 and 1, requesting index 2
will return the Connection List Entries at offset 2 and 3, etc. If the Long Form bit of the
Connection List Length parameter is 0, n must be a multiple of four, and four short form
Connection List entries will be returned. Therefore, requesting index 0 will return the values at
offset 0, 1, 2, and 3, requesting index 4 will return the Connection List Entries at offset 4, 5, 6, and
7, etc.

Every entry is number of node to which this connection exist.

Here is example how this all together may work in simplified example. Let's say you have codec with Audio Function Group with four nodes:

Code: Select all

Node 2: Audio Output
Node 3: Audio Output
Node 4: Mixer
Node 5: Output Pin

You want to enable Output PIN. So you request Connection List Length on node 5 (verb 0xF00, data 0x0E). Node returns 0x01 = short form, one entry. You request connection list entries (verb 0xF02, data 0x00). Node returns 0x00000004 = entry with value 4. This means that Output PIN is taking data from node 4 Mixer.

You request Connection List Length on node 4. Node returns 0x02 = short form, two entries. You request connection list entries (verb 0xF02, data 0x00). Node returns 0x00000302 = entry with value 2 and entry with value 3. This means that Mixer is taking data from node 2 Audio Output and node 3 Audio Output.

Audio Output nodes do not have connection list, because they are never taking data from other nodes, instead they are providing data for other nodes.

So now you find all physical connections between nodes:

Code: Select all

Audio Output (node 2)
                      \
                    Mixer (node 4) -> Output Pin (node 5)
                      /
Audio Output (node 3)

If you do not want to use mixing capability of mixer, you can enable Output PIN through one of those two paths:

Code: Select all

Audio Output (node 2) -> Mixer (node 4) -> Output Pin (node 5)

Audio Output (node 3) -> Mixer (node 4) -> Output Pin (node 5)

[wishedtobe]

To get connection list you at first need to get informations about this connection list. You can obtain them through verb 0xF00 with data 0x0E (Connection List Length). First seven bits contains number of nodes in list. Eight bit identifies type of entries in connection list (0 = short form, 1 = long form). Short form means that every entry is 1 byte long and long form that it is 2 bytes long.

How can I access a 16-bit node?

[VSlezak]

As far as I know, node number can be only in range 0-255, so you use normal verb form. Short form entries are used only up to node number 127 (seven bits), so therefore there are long form entries that allow usage of nodes up to 255 (eight bits).

[wishedtobe]

How can I access a 16-bit node?

Bit 27 allows for an indirect addressing mechanism (to be specified) for codecs that have more than 127 nodes to address and, therefore, use the long form (15-bits) of node addressing.

What did that mean? Is this mechanism used by vendors, waiting for a specific driver to work?

[VSlezak]

Honestly, I do not know. Because specification never talks about indirect access mechanism again, it may be vendor specific. However so far I never seen codec with more than 127 nodes, it seems that they are rare.

[wishedtobe]

Now let's summarize my tasks: iterate through each widget, with every output pin to be switched on; search for the nearest output converter in the connection list, and connect them to stream 0; allocate 0x20 bytes where lowest 0xc bits of the address are 0, and store the length and the base address sized 0x10 twice; finally set stream running bit to 1, then it can be working.

[VSlezak]

You do not need to enable every Output Pin. Every Output Pin is giving audio to some specific output device, so on real hardware this would result on audio simultaneously playing from speakers and headphones, what is probably not wanted result. You need to enable only Output Pins with devices you want to enable. So I would add, that during iteration step you need to also parse types of devices connected to Pins, and then decide which ones you want to use.

Also stream 0 do not exist. Value 0 indicates that node (or Stream Descriptor) is not connected to any stream. You should use stream 1.

For rest, I am not exactly sure what do you mean by "store the length and the base address sized 0x10 twice", if you mean writing physical address of Buffer Entries, writing number of Buffer Entries and writing length of all audio samples described by Buffer Entries to Stream Descriptor, than it should be fine.

[wishedtobe]

You do not need to enable every Output Pin. Every Output Pin is giving audio to some specific output device, so on real hardware this would result on audio simultaneously playing from speakers and headphones, what is probably not wanted result. You need to enable only Output Pins with devices you want to enable. So I would add, that during iteration step you need to also parse types of devices connected to Pins, and then decide which ones you want to use.

I just want to simplify this process to its best, so I'm not going to deal with plug-and-play etc. I'll switch on every pins whether it's connected to a headphone plug or not.

[VSlezak]

In my opinion it is much harder way than just switch on path of one speaker PIN. If you want to have output from all PINs at once, you will need to enable much more nodes than just nodes in path of one output PIN. But it is not impossible, so of course, you can try it.