1 (edited by Manuel 2024-05-09 23:47:16)

Topic: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

I don't know if this is technically feasible but I'll present it here for discussion anyway.

tl;dr: I need more playback channels, and it would be nice if we could have dedicated loopback inputs and outputs that don't use up valuable hardware I/O.

Note: In this post I use the term "channel" to mean "stereo channel" (i.e. 2 x mono channels).

The first request is for more playback channels. I am using Reaper as a virtual control room mixer. I route my system's and Ableton Live's audio output to an unused hardware output in TMFX (ADAT 1/2). This output has the loopback switch enabled. Then, Reaper takes the audio from the ADAT 1/2 input, processes it, and sends it to a number of playback channels, which in turn send audio to hardware outputs for consumption. One of the playback channels sends its audio to an unused hardware output (ADAT 3/4) which also has the loopback swtich enabled. Then other software can use input ADAT 3/4 as its audio input, which enables me to do things such as processing my voice before going into Skype or into screen recording software.

Generally I like to work at 96 kHz. Below is a diagram of my signal flow for both 48 and 96 kHz. In total I need 9 playback channels. At 48 kHz there are 10 playback channels, so I end up with one unused playback channel. However, at 96 kHz, my preferred sample rate, there are only 8, which means I am short by 1 playback channel:

At sample rate = 48 kHZ, there are 4 ADAT channels and the number of playback channels is sufficient (see full-size image):

https://i.vgy.me/6khkdZ.png

At sample rate = 96 kHZ, there are only 2 ADAT channels and the number of playback channels is insufficient (total playback channels needed 9, only 8 channels available) (see full-size image):

https://i.vgy.me/3e64g0.png

The suggestion is to make more playback channels, whilst keeping the hardware ins and outs the same. Unless there is a technical limitation, the decision to make the number of playback channels the same as the number of output channels seems an arbitrary one, and in some cases (such as mine) it would be useful to have more playback channels.

The second suggestion pertains to the loopback function. The loopback function "sacrifices" an input-output pair, which is a problem on audio interfaces with scarce hardware I/O. It would be much better to have dedicated "virtual" loopback outputs that do not consume valuable hardware I/O. It seems wasteful to have physical I/O circuitry and connectors that are there wasting space and power (output amps are on even when not in use and generate heat). This implementation would eliminate the need for the Loopback switch which some users find confusing at first. Another benefit of this approach is that it doesn't require loopback input channels to appear on the input channels row. Audio would simply be routed to the loopback outputs (maybe there could be 2 or even 4 of these) and the driver would present the loopback channels as inputs in our DAW etc.

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

what interface are you talking ?
The little Babyface already has 12 playback channels...?

M1-Sequoia, Madiface Pro, Digiface USB, Babyface silver and blue

3 (edited by Manuel 2024-05-09 22:45:53)

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

waedi wrote:

what interface are you talking? The little Babyface already has 12 playback channels...?

It's the UCX II, and I'm talking stereo channels, not mono. Specifically, the UCX II has 10 stereo playback channels (= 20 mono channels) and that's only if the sample rate is ≤ 48 kHz. At higher sample rates the number of available ADAT channels is reduced due to ADAT technical limitations (because ADAT is ancient tech). RME made the decision to match the number of playback channels to the number of output channels. I have a feeling this is just an arbitrary decision, because the UFX which also uses USB 2.0 supports a greater number of playback channels, so in theory it should be possible to add more playback. The problem is that, in trying match the number of playback channels to the number of output channels, when the sample rate goes up the number of output channels goes down, and so does the number of playback channels.

Page 103 of the UCX II user manual says:

At a sample rate of 48 kHz, up to 40 channels (all inputs and outputs), at 96 kHz 32 channels, at 192 kHz 16 channels can be selected. Therefore at 48 kHz and 96 kHz all available inputs and outputs can be recorded simultaneously.

RME if you are reading this, is that an error? The first half of the paragraph says very clearly that up to 48 kHz all 40 channels can be used, and at 96 kHz only 32 channels, but then the second half says at 48 kHz and 96 kHz all channels can be used? That makes no sense. If all channels could be used at 96 kHz I wouldn't have started this thread.

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

...all available channels ! And at 96kHz less channels are available.

M1-Sequoia, Madiface Pro, Digiface USB, Babyface silver and blue

5 (edited by Manuel 2024-05-09 23:22:57)

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

waedi wrote:

...all available channels ! And at 96kHz less channels are available.

Oh I see, I guess that just refers to DURec recording I guess. To be fair, the way that is worded it could be easily misinterpreted, like I did. The whole manual contains a lot of sentences that are not properly constructed. In any case, the number of playback channels is reduced.

6 (edited by waedi 2024-05-09 23:29:17)

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

What you request is a complete redesign of the interface and of Totalmix.
They would have to add channels that are only enabled in high sample rate for compensating the reduction of channels.
You better buy an interface with enough channels for your demand.
Digiface AVB / Dante / Ravenna have 64 stereo software playback channels (at up to 48kHz).

M1-Sequoia, Madiface Pro, Digiface USB, Babyface silver and blue

7 (edited by Manuel 2024-05-09 23:40:31)

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

waedi wrote:

What you request is a complete redesign of the interface and of Totalmix.
They would have to add channels that are only enabled in high sample rate for compensating the reduction of channels.

But the playback channels are already there, it's just that Totalmix hides and disables them when I increase the sample rate. I don't understand why this is necessary. I can understand hiding ADAT output channels, but disabling "ADAT" playback channels when corresponding ADAT output channels are disabled seems like an entirely cosmetic choice, because playback channels are not really ADAT, AES, analog or anything—they are just internal channels in Totalmix. It would have been more intuitive to name playback channels "Playback 1", "Playback 2" ... "Playback 20" instead. The number of input and output channels reflects the physically available hardware ins and outs, but the number of playback channels could be any number as long as the hardware has sufficient DSP resources to handle it.

So yes, what I propose involves some redisigning but it's very far from being a complete redesign of the interface and Totalmix. I think the question is whether the device has enough resources to handle all all playback channels at any sample rate. The UFX and the UFX II can and those also use USB 2.0, so we know USB is not the bottleneck.

8 (edited by waedi 2024-05-09 23:48:12)

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

See in Dante and Ravenna the channel number is halving when the sample rate is doubled.
This is not ancient Adat behavior it is general digital audio.
Your interpretation of Totalmix is probably wrong.
The audio interface is designed for a certain number of channels.
They not hiding Adat channels, these channels simply don't exist in higher sample rate. So Totalmix shows reality.
The playback channels are not free independet channels, those are part of the interface channel.
You may have to look at a channel like a road or highway. At one end is the input and at the other end the output (-channel).
and somewhere in the middle is an intersection from the software, the software playback channel.
An entry point into the channel.

M1-Sequoia, Madiface Pro, Digiface USB, Babyface silver and blue

9 (edited by Manuel 2024-05-09 23:58:15)

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

waedi wrote:

They not hiding Adat channels, these channels simply don't exist in higher sample rate. So Totalmix shows reality.

True for output channels, but what bout playback channels?

waedi wrote:

The playback channels are not free independent channels, those are part of the interface channel.
You may have to look at a channel like a road or highway. At one end is the input and at the other end the output (-channel).
and somwhere in the middle is an intersection from the software, the software playback channel.
An entry point into the channel.

There are input and output channels in TMFX that correspond 1:1 to physical connectors on the device: analog, AES, SPDIF and ADAT. ADAT in particular has a limit of 8 channels at 48 kHz therefore, if we double the sample rate, the number of audio channels it can carry is halved. Playback channels don't represent physical connectors, therefore they are (or should not be) subject to the limitations of ADAT, and therefore all playback channels should be available regardless of sample rate, assuming the UCX II has enough DSP resources to handle it all.

In any case, only RME can confirm the reasons for this design.

10 (edited by ramses 2024-05-10 06:51:57)

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

The software playback channels match the hardware I/O of the driver/recording interface.

All I/O channels are being transferred instantly, no matter whether the channels are in use or not.
There are only few exceptions to this rule: a) FW driver where you can disable I/O for digital channels and b) HDSPe MADI FX driver with certain optimizations to reduce CPU utilization)

By having more SW playback channels would mean
a) you have "fake" HW outputs that do not exist
b) you have to transfer more channels instantly over USB / PCIe than ever thought (FPGA capacity/performance).

Esp regarding b)
If you introduced such a change to have more SW playbacks than HW output channels, then you will always run into problems. What number should it be? 40, 80, 100, 150?
- for USB2 more than 68 would be too high
- for an HDSPe MADI FX only 50 or 100 SW Playback channels would be too low
- for some FPGA (programmable CPU) the number of channels might also be too high CPU wise.

How would you name those channels if there are no real HW outputs behind it that are easily "explainable" for the average DAW user? Some people are having already difficulties with TM FX "as is".

So, everything fits much better if the SW Playbacks match 1:1 with the real HW outputs.

An alternative idea might be, to add a certain fix amount of virtual channels (8 or 16) just for the purpose of having more SW playbacks and virtual HW in/outputs. I made already such a proposal in the past.

But I fear that the efforts for such a drastic change would be too high.
- Number of Test cases
- Firmware/FPGA changes for a lot of stuff (6 main drivers * 2 OS * amount of units
- driver changes
- TM FX changes

If you need more SW Playbacks or more possibilities for loopback recording of a number of Submixes the best solution is to get a recording interface with enough spare channels.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14

11

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

In Double and Quad Speed audio transmission uses significantly higher resources, so in most cases it is even impossible to have the same number of channels available. Interfaces with ADAT and MADI basically match the situation in the OS, at double and quadruple sample rates the number of channels must go down.

Also note that 'phantom channels' do use resources, in the driver, by the OS and the hardware.

For that reason we also never added pure Loopback channels.

Regarding automatic removal of not working channels - it should be obvious that most users would have a big problem with channels that claim to be there but don't do anything. It's confusing and will cause failures in usage.

Regards
Matthias Carstens
RME

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

MC wrote:

In Double and Quad Speed audio transmission uses significantly higher resources, so in most cases it is even impossible to have the same number of channels available. Interfaces with ADAT and MADI basically match the situation in the OS, at double and quadruple sample rates the number of channels must go down.

Also note that 'phantom channels' do use resources, in the driver, by the OS and the hardware.

For that reason we also never added pure Loopback channels.

OK so it's a limitation of the hardware, then it makes sense. I'm guessing the UFX has a more powerful FPGA to be able to handle a higher channel count.

I don't suppose it would be possible in a future update to allow users to choose which channels are disabled in double and quad speed? For example, at 96 kHz I'm using only 12 input channels (8 analog and 4 for loopbacks) and there are a total of 16. At the same time, I need 18 playback channels but there are only 16. I would happily trade ADAT 1/2/3/4, which I am not using, for 4 playback channels.

MC wrote:

Regarding automatic removal of not working channels - it should be obvious that most users would have a big problem with channels that claim to be there but don't do anything. It's confusing and will cause failures in usage.

I agree and I will add that just hiding channels that become disabled following a change of sample rate is also a source of confusion. For example, I am  currently trying to stick to 48 kHz just so I can have the extra playback channels, but I just opened a DAW project that requests a sample rate of 96 kHz. After I open that project, the sample rate automatically changes and initially everything seems to work until I need to use a channel that has become disabled behind my back. Looking at the TotalmixFX GUI, initially nothing unusual jumps at me. It's only after I finally notice some of my playback channels is missing that I go "aha!". Personally, I think graying out the disabled channels might be more "visual", like this:

https://i.vgy.me/gNAvSz.png

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

I guess, the limit is more on USB2 data transmision capacity, than DSP. But maybe also DSP plays role....

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

Kubrak wrote:

I guess, the limit is more on USB2 data transmision capacity, than DSP. But maybe also DSP plays role....

The bottleneck cannot be USB2.0 because the UFX II, which also uses USB2.0, can handle more I/O channels than the UCX II.

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

According to RME USB2 can handle 70/70 channels SS. So, 35/35 DS 17/17 QS. UCX II has 8 analog outs, ADAT (2 ch in QS) and AES/EBU (I guess - 2 ch).  12/17 of the bandwitch is used.

UFX II has four more analogs out and one ADAT (2ch), so 18/17 bandwitch is used.

So probably the limit is 72/72 SS, 36/36 DS and 18/18 QS.

So, you could have at QS at most six more virtual outs, if DSP would handle it... Would it be worth all the problems? And it would introduce inconsistences. UCX could have it, but UFX not (it probably uses the whole USB2 bandwitch at QS)....

16 (edited by Manuel 2024-05-10 21:43:44)

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

Kubrak wrote:

So, you could have at QS at most six more virtual outs, if DSP would handle it... Would it be worth all the problems? And it would introduce inconsistences. UCX could have it, but UFX not (it probably uses the whole USB2 bandwitch at QS)....

I'm pretty sure RME won't implement this, but for UCX II users it would be added value and honestly I don't think it would be a problem. There are  more confusing things in TotlamixFX, like playback channels that are named after hardware outputs even though they don't represent hardware outputs. See my earlier message, playback channels should be named "Playback 1", "Playback 2", etc, then it wouldn't matter if the number of playback channels and the number of outputs didn't match.

The UFX may not get the extra playback channels but it has more physical ins and outs, which give people a good reason to get the UFX over the UCX. In other words, and this is why I started this thread, I wouldn't buy a UFX just to get two more playback channels, but I would buy a UFX to get extra hardware connections if I need them.

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

There could be 9 stereo playback channells at most at QS. It is USB2 bandwitch limit. So, it would fit your use case....

But there is another reason for having as many play channels as physical outs.... And it is DAW mode of TotalMix... That also explains why playback channels are named as they are and not Out1, Out1, .... So no way for your request even if RME would be keen for....

I do not kow, how you use your setup, but maybe using snapshots and workspaces you could fit in playback channels available. If not, maybe to add Digiface USB to your setup would give you, what you need. It has 4 ADAT plugs in and 4 out and is small and unexpensive.

World is not ideal, the life is about compromises.

18 (edited by ramses 2024-05-11 10:20:05)

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

Manuel wrote:
Kubrak wrote:

So, you could have at QS at most six more virtual outs, if DSP would handle it... Would it be worth all the problems? And it would introduce inconsistences. UCX could have it, but UFX not (it probably uses the whole USB2 bandwitch at QS)....

I'm pretty sure RME won't implement this, but for UCX II users it would be added value and honestly I don't think it would be a problem. There are  more confusing things in TotlamixFX, like playback channels that are named after hardware outputs even though they don't represent hardware outputs.

This is for sure not the only issue with such an implementation.
Think about FPGA capacity.

Features like Room EQ are already not possible with any hardware:
802 FS yes, 802 no, HDSPe MADI FX with newer models yes, older HW versions no.

Such a drastic change in design makes only sense if all RME devices worked this way.
I doubt that this can be implemented with all devices.
And having two different versions of TM FX which look completely different makes no sense at all.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

Yes sure, I have mentioned also possible DSP limit and that it would "break" unified approach to all RME devices, in earlier posts...

And anyway one would not reach "Do not disable playback channels at higher sample rate" even for UCX, not speaking about UFX or Digiface USB. There would be limit on the USB2 bandwitch and DSP capability...

20 (edited by Manuel 2024-05-11 12:12:53)

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

Kubrak wrote:

Yes sure, I have mentioned also possible DSP limit and that it would "break" unified approach to all RME devices, in earlier posts...

And anyway one would not reach "Do not disable playback channels at higher sample rate" even for UCX, not speaking about UFX or Digiface USB. There would be limit on the USB2 bandwitch and DSP capability...

I took a look at the UCX II PCB a while ago and it uses a dedicated USB interface IC (specifically the Microchip USB3250), which supports 480Mbps transfer rate, therefore USB can't be the bottleneck. It could be the bottleneck in the UFX II because it supports a higher channel count which means it may be close to maxing out the available USB 2.0 bandwidth. My UCX II uses the Xilinx XC6SLX16 FPGA chip (current production units use a newer FPGA as confirmed by MC in another thread on this forum). I don't know what FPGA chip is used in the UFX II but I assume it's a more capable one than the UCX II's, hence the limitations in terms of channel count.

In any case, I leave my commenst here and I'm glad RME have noticed this thread. Maybe some of these suggestions could be implemented in future RME products, if technically feasible.

21 (edited by ramses 2024-05-11 13:25:58)

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

Manuel wrote:

I took a look at the UCX II PCB a while ago and it uses a dedicated USB interface IC (specifically the Microchip USB3250), which supports 480Mbps transfer rate, therefore USB can't be the bottleneck. It could be the bottleneck in the UFX II because it supports a higher channel count which means it may be close to maxing out the available USB 2.0 bandwidth. My UCX II uses the Xilinx XC6SLX16 FPGA chip (current production units use a newer FPGA as confirmed by MC in another thread on this forum). I don't know what FPGA chip is used in the UFX II but I assume it's a more capable one than the UCX II's, hence the limitations in terms of channel count.

In any case, I leave my commenst here and I'm glad RME have noticed this thread. Maybe some of these suggestions could be implemented in future RME products, if technically feasible.

Sorry, but this seems to be wrong understood by you.

This microchip only provides access to the physical layer of USB. This is the same for all technologies, that there is a component, that simply provides access to the physical Layer (be it USB, network, etc).

EDIT: we had this discussion I think a couple of years ago where RME detailed it as somebody claimed that RME would use 3rd party USB chips and then I think MC clarified, that this is only the chip for PHY (physical access) and that - as "advertized" / designed - the USB communication is otherwise fully handled by the FPGA.

What makes RME's design special in terms of stability, performance, low latency is, that the FPGA handles the communication to the host, no matter whether we talk about Firewire, USB, etc. By this RME has everything in their hand on this side of the communication.

Most other devices are using 3rd party chips for the USB communication which can not be reprogrammed like a FPGA.
If that 3rd party chip is lame or if it turns out, that it has a bug, then nothing can be done.
In contrast to that, RME is able to reprogramm the FPGA by firmware update.

If you think about bandwidth / capacity / number of channels then the PHY has nothing to do with it.
Of course the chip providing the access to the physical Layer of USB will be compliant to the maximum capacity according to the USB specification.

But this has nothing to do about how many channels the RME device handles or is able to handle. Either this is limited by the capacity and performance of the FPGA that is being used in the device another reason could also be, how RME wants to design the product that users have a good user experience. Possibly both.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14

22 (edited by Manuel 2024-05-11 13:48:12)

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

ramses wrote:
Manuel wrote:

I took a look at the UCX II PCB a while ago and it uses a dedicated USB interface IC (specifically the Microchip USB3250), which supports 480Mbps transfer rate, therefore USB can't be the bottleneck. It could be the bottleneck in the UFX II because it supports a higher channel count which means it may be close to maxing out the available USB 2.0 bandwidth. My UCX II uses the Xilinx XC6SLX16 FPGA chip (current production units use a newer FPGA as confirmed by MC in another thread on this forum). I don't know what FPGA chip is used in the UFX II but I assume it's a more capable one than the UCX II's, hence the limitations in terms of channel count.

In any case, I leave my commenst here and I'm glad RME have noticed this thread. Maybe some of these suggestions could be implemented in future RME products, if technically feasible.

Sorry, but this seems to be wrong understood by you.

This microchip only provides access to the physical layer of USB. This is the same for all technologies, that there is a component, that simply provides access to the physical Layer (be it USB, network, etc).

EDIT: we had this discussion I think a couple of years ago where RME detailed it as somebody claimed that RME would use 3rd party USB chips and then I think MC clarified, that this is only the chip for PHY (physical access) and that - as "advertized" / designed - the USB communication is otherwise fully handled by the FPGA.

What makes RME's design special in terms of stability, performance, low latency is, that the FPGA handles the communication to the host, no matter whether we talk about Firewire, USB, etc. By this RME has everything in their hand on this side of the communication.

Most other devices are using 3rd party chips for the USB communication which can not be reprogrammed like a FPGA.
If that 3rd party chip is lame or if it turns out, that it has a bug, then nothing can be done.
In contrast to that, RME is able to reprogramm the FPGA by firmware update.

If you think about bandwidth / capacity / number of channels then the PHY has nothing to do with it.
Of course the chip providing the access to the physical Layer of USB will be compliant to the maximum capacity according to the USB specification.

But this has nothing to do about how many channels the RME device handles or is able to handle. Either this is limited by the capacity and performance of the FPGA that is being used in the device another reason could also be, how RME wants to design the product that users have a good user experience. Possibly both.

That is exactly what I said if you re-read my post: USB 2.0 (480 mpbs) isn't the bottleneck, it's what happens after the interface IC that determines how much signal processing can be performed

Re: FR: Do not disable PLAYBACK channels at sample rate > 48 kHz

I "misunderstood" you in the way as it sounded that you want to tell that increasing the channel capacity should (easily) be possible because of this chip ... And I wanted to explain that it doesn't depend on this chip alone.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14