hdspe: AO4S/AI4S support

[br]

Summary

Add support for AO4S/AI4S extension cards to the RME HDSPe AIO card, they are designed as a bracket with 4 stereo TRS jacks each.

https://archiv.rme-audio.de/download/ao4s192_e.pdf
https://archiv.rme-audio.de/download/ai4s192_e.pdf

Test Plan

I have both AO4S and AI4S cards, but tested on OUT1 of AO4S only.

[br]

we actually need to change this patch to support stereo (I currently own just one studio monitor).
Should we do HDSPE_CHAN_AIO_EXT1 for two channels, and HDSPE_CHAN_AIO_EXT2 for another two channels? to support stereo.

[dev_submerge.ch]

In D46409#1057745, @br wrote:

we actually need to change this patch to support stereo (I currently own just one studio monitor).
Should we do HDSPE_CHAN_AIO_EXT1 for two channels, and HDSPE_CHAN_AIO_EXT2 for another two channels? to support stereo.

The current state of the FreeBSD audio stack is that it's easy to split the channels of one pcm device into multiple pcm devices, using virtual_oss for example. In contrast there's almost no support for opening multiple pcm devices to combine them and use their channels in parallel.

Therefore, while two stereo pcm devices would be better than mono, I'd even prefer to combine all four channels into one pcm device for the extension boards. We can make it play / record mono on the first channel, or stereo on the first two channels, when the device is opened that way. The buffer_copy() implementation already handles such cases (for ADAT), I think we'd just have to include mono and stereo in the supported sound format capability list. Would that cover your use cases?

Another question, I didn't have time yet to study the linux code, are there flags in the registers to indicate the presence of the extension boards? They are not hot-swappable I suppose, so I think we shouldn't create those extra pcm devices when the extension boards are not present. I would probably also make a distinction between the AO4S and AI4S, and create separate pcm devices for them. As an option, we could do that as an improvement in a second step, and get it working for you in a "always present" mode first.

[br]

combine all external channels to a single channel

[br]

In D46409#1058233, @dev_submerge.ch wrote:

In D46409#1057745, @br wrote:

we actually need to change this patch to support stereo (I currently own just one studio monitor).
Should we do HDSPE_CHAN_AIO_EXT1 for two channels, and HDSPE_CHAN_AIO_EXT2 for another two channels? to support stereo.

The current state of the FreeBSD audio stack is that it's easy to split the channels of one pcm device into multiple pcm devices, using virtual_oss for example. In contrast there's almost no support for opening multiple pcm devices to combine them and use their channels in parallel.

Therefore, while two stereo pcm devices would be better than mono, I'd even prefer to combine all four channels into one pcm device for the extension boards. We can make it play / record mono on the first channel, or stereo on the first two channels, when the device is opened that way. The buffer_copy() implementation already handles such cases (for ADAT), I think we'd just have to include mono and stereo in the supported sound format capability list. Would that cover your use cases?

Another question, I didn't have time yet to study the linux code, are there flags in the registers to indicate the presence of the extension boards? They are not hot-swappable I suppose, so I think we shouldn't create those extra pcm devices when the extension boards are not present. I would probably also make a distinction between the AO4S and AI4S, and create separate pcm devices for them. As an option, we could do that as an improvement in a second step, and get it working for you in a "always present" mode first.

Agree on merging all external channels to a single PCM. I tested it works as expected for me.
I believe the extension cards are hot swappable. I could not find any AO4S/AI4S card detection bits in the linux code.
I think those AIO ports (2,3,4,5) exposed on the external pin header could be used for other extension cards as well, not just A4S.

[dev_submerge.ch]

In D46409#1058833, @br wrote:

In D46409#1058233, @dev_submerge.ch wrote:

Another question, I didn't have time yet to study the linux code, are there flags in the registers to indicate the presence of the extension boards? They are not hot-swappable I suppose, so I think we shouldn't create those extra pcm devices when the extension boards are not present. I would probably also make a distinction between the AO4S and AI4S, and create separate pcm devices for them. As an option, we could do that as an improvement in a second step, and get it working for you in a "always present" mode first.

Agree on merging all external channels to a single PCM. I tested it works as expected for me.
I believe the extension cards are hot swappable. I could not find any AO4S/AI4S card detection bits in the linux code.

I see flags for the presence of AO4S/AI4S in the new linux driver here, in the status2 register. From the manual they want you to disconnect the power cable before installing them, so I wouldn't try hot-swapping.

But according to the manuals, the expansion board channels are always shown in the windows driver, so I think we can also keep "ext" pcm device always present. Could you please test that there's no harm in using the "ext" pcm device without any expansion boards? Is there an error or does it just run silently?

I think those AIO ports (2,3,4,5) exposed on the external pin header could be used for other extension cards as well, not just A4S.

I don't find any expansion boards mentioned on the same connector. The Word Clock expansion and the older AEB boards are on different connectors, and they don't affect channel layout.

BTW, did you create this review from a diff? Usually there's more context of the unchanged source parts.

We may need additional changes to make the unified pcm device mode work. Maybe I can add expansion board support to the HDSP 9632 driver based on this patch, it should be similar. Then we can supplement these changes.

sys/dev/sound/pci/hdspe.h

126

Can we reorder the flags to position HDSPE_CHAN_AIO_EXT between HDSPE_CHAN_AIO_LINE and HDSPE_CHAN_AIO_PHONE? There's some channel layout logic in hdspe-pcm.c that relies on this, for the unified all-in-one pcm device.

[br]

reorder EXT channel between LINE and PHONE

[br]

In D46409#1059523, @dev_submerge.ch wrote:

But according to the manuals, the expansion board channels are always shown in the windows driver, so I think we can also keep "ext" pcm device always present. Could you please test that there's no harm in using the "ext" pcm device without any expansion boards? Is there an error or does it just run silently?

Let me check

[br]

In D46409#1060137, @br wrote:

In D46409#1059523, @dev_submerge.ch wrote:

But according to the manuals, the expansion board channels are always shown in the windows driver, so I think we can also keep "ext" pcm device always present. Could you please test that there's no harm in using the "ext" pcm device without any expansion boards? Is there an error or does it just run silently?

Let me check

I will check this on the first opportunity, I just don't want to loose work environment when rebooting as lots of windows are opened:)

[br]

In D46409#1062686, @br wrote:

In D46409#1060137, @br wrote:

In D46409#1059523, @dev_submerge.ch wrote:

But according to the manuals, the expansion board channels are always shown in the windows driver, so I think we can also keep "ext" pcm device always present. Could you please test that there's no harm in using the "ext" pcm device without any expansion boards? Is there an error or does it just run silently?

Let me check

I will check this on the first opportunity, I just don't want to loose work environment when rebooting as lots of windows are opened:)

I was just able to disconnect both extension cards on the fly when music was playing (without shutting down the PC), and then connected them back -- music still playing.
so hot swap may actually work

[br]

In D46409#1062688, @br wrote:

In D46409#1062686, @br wrote:

In D46409#1060137, @br wrote:

In D46409#1059523, @dev_submerge.ch wrote:

But according to the manuals, the expansion board channels are always shown in the windows driver, so I think we can also keep "ext" pcm device always present. Could you please test that there's no harm in using the "ext" pcm device without any expansion boards? Is there an error or does it just run silently?

Let me check

I will check this on the first opportunity, I just don't want to loose work environment when rebooting as lots of windows are opened:)

I was just able to disconnect both extension cards on the fly when music was playing (without shutting down the PC), and then connected them back -- music still playing.
so hot swap may actually work

I also managed to unload the snd_hdspe just after physical detachment of extension cards, then load driver when cards are not present, then connected cards back and playback is working

[dev_submerge.ch]

In D46409#1062688, @br wrote:

I was just able to disconnect both extension cards on the fly when music was playing (without shutting down the PC), and then connected them back -- music still playing.
so hot swap may actually work

This means we can start a channel, set the start flag in the register, and the driver runs without the extension boards connected? Recording silence?
If that's the case we can keep the pcm device always present, no harm done.

I will write the HDSP equivalent and add the missing unified pcm device part there, for comparison. Hopefully this weekend.

[br]

In D46409#1063483, @dev_submerge.ch wrote:

In D46409#1062688, @br wrote:

I was just able to disconnect both extension cards on the fly when music was playing (without shutting down the PC), and then connected them back -- music still playing.
so hot swap may actually work

This means we can start a channel, set the start flag in the register, and the driver runs without the extension boards connected? Recording silence?
If that's the case we can keep the pcm device always present, no harm done.

I will write the HDSP equivalent and add the missing unified pcm device part there, for comparison. Hopefully this weekend.

I don't have recording equipment to check but I assume yes.
sounds good

[dev_submerge.ch]

In D46409#1063484, @br wrote:

In D46409#1063483, @dev_submerge.ch wrote:

I will write the HDSP equivalent and add the missing unified pcm device part there, for comparison. Hopefully this weekend.

I don't have recording equipment to check but I assume yes.
sounds good

The snd_hdsp(4) equivalent is in D46837, but we cannot take the unified pcm fix from there because the port mapping logic is somewhat different. I'll propose a fix and maybe some man page amendments in a separate patch.

[dev_submerge.ch]

{F97460426}

This would be my proposed fix for the unified pcm device mode, plus some man page amendments.

@br, could you have a look and integrate this patch with yours if you agree with it? It's a git patch, apply with git am and then squash. Since I cannot test it without the hardware, could you please also try to enable the unified pcm mode?

[br]

In D46409#1067830, @dev_submerge.ch wrote:

{F97460426}

This would be my proposed fix for the unified pcm device mode, plus some man page amendments.

@br, could you have a look and integrate this patch with yours if you agree with it? It's a git patch, apply with git am and then squash. Since I cannot test it without the hardware, could you please also try to enable the unified pcm mode?

we could just commit the patches for different cards separately so preserve authors of patches. I can test unified PCB but not very soon

[dev_submerge.ch]

In D46409#1069049, @br wrote:

In D46409#1067830, @dev_submerge.ch wrote:

{F97460426}

This would be my proposed fix for the unified pcm device mode, plus some man page amendments.

@br, could you have a look and integrate this patch with yours if you agree with it? It's a git patch, apply with git am and then squash. Since I cannot test it without the hardware, could you please also try to enable the unified pcm mode?

we could just commit the patches for different cards separately so preserve authors of patches. I can test unified PCB but not very soon

The HDSP patch is still separate in D46837. What I uploaded here is just a small addendum to your HDSPe patch. I created a review now for that addendum in D46946, but I think it would make sense to squash it together with your patch.