4 slaves in PCM quality

To provide more information on the issue - from what I can see 4 slaves are possible to configure also at 44,1k, PPath refuses to flash only at 48k when max is 3 slaves. So it seems it is very close to the performance boundaries and maybe there is possibility to shift the restrictions slightly ?
The reason 48k is important for me is that in one of the two main audio modes of my product 96k HD audio is streamed using two masters individually paired with tow slave groups and sending two samples of one channel to each slave groups. In the other one master provides audio to two different stereo speaker sets with CD quality - hence the key need for 4 slaves.

Any chance for a TI team reply soon ?

It is a pressing issue as our commercial product launch is very imminent.

Hi Pawel, 

Agree that you have to be very close to the border. I'm guessing you are using host controlled operation with data side channel? If that is the case, then it is the data side channel enabling that eats up the timeslot BW. 

Can you post your project files and I can do some calculations to how far off you are in this config?

Understand that the statement "Note the following guidelines/limitations when selecting streaming formats: 1 or 2 channels: No restrictions" can be confusing, but this is written with regards to which streaming formats that can be chosen and not necessarily typing up all limitations that can happen with all possible configuration setting.  

Also, please note that being just above the critical level for robustness might not be good enough for you application. What will happen is that you will very quickly enter a mode where only every other samples is sent and output is interpolated..not sure if this will be better than using SLAC as the streaming format. 

Regards,
Kjetil

jHi Kjetil,
thanks for the reply and a supportive approach.

Kjetil said:

Agree that you have to be very close to the border. I'm guessing you are using host controlled operation with data side channel? If that is the case, then it is the data side channel enabling that eats up the timeslot BW. 

That's correct, using data channel.

Kjetil said:

Also, please note that bein5875.infadoTests_app.zipg just above the critical level for robustness might not be good enough for you application. What will happen is that you will very quickly enter a mode where only every other samples is sent and output is interpolated..not sure if this will be better than using SLAC as the streaming format. 

It seems instead of solving a problem I have two quite serious now :( My product is aimed at the audiophile market, interpolated samples is not something that I would like to appear outside of my awareness and control. Is it an automatic algorithm and there is no possibility of configuration control whether interpolation is used at all ? I understand that the interpolation mechanism is turned on also when in any configuration when the signal is too weak for slaves due to environment conditions ? Then from my observations there is a point when audio choking/breaks begin - am I correct that at some earlier point interpolation is turned on ? Is there any way of finding out when (any messages) or best to tun it off via configuration ?

For the robustness error I understand that if such an error appears I cannot flash a CC module accepting the risks of lower potential performance, but e.g. knowing that the slaves will be close physically to each other so probably it should compensate for more demanding config ?

I am also surprised that buffer size does not have impact on the robustness caclulation - I can trade off maximum buffering/latency for sample rates and slave number - i.e. throughput.

The problematic configuration is M1 retsam -

Regards, Pawel

At the end of writing last post I got strange problems with the editor hence typos in a few places that I could not correct and the config inserted at a strange place. The last sentence should read: The problematic configuration is M1 master.

2577.infadoTests_app.zip

Hi Pawel,

Will need the .ppwcfg files as, especially for the M1 master. 

Robustness in "out" world consists of two things.
1. How much throughput on average can be lost before audio is muted
2. How many audio slices in a row can be lost before audio is muted

For number 2, the buffering is key as it is all about consecutive samples.  
Your problem however is more related to the overall link capacity, which needs to have at least 10% over-capacity not to fall below the "expected audio robustness below critical level". My guess is that your master configuration as-is, is somewhere close to 4% with the data-side channel (DSC) enabled and the only thing that can bring it up to where it needs to be is disabling the DSC or reduce the number of slaves. Is there an option for you to use the RC commands as an alternative to DSC or is critical information going from master to slave(s)? Now you can argue that 10% is a number set by us and you want to override this for various reasons. We tested this extensively and 10% was really the bare minimum we needed to maintain any reliable link for even the shortest period. Disabling this in your setup sounds like a bad idea, even though the slaves are close physically as I expect there to be people, and potentially moving, in proximity and multi-path effect come into play.

Interpolation is not configurable as this is built deep into our protocol and will occur every time a 'odd' sample is missing. We always give priority to 'odd' slices, and if any of the slaves does not acknowledge reception of 'odd' slices we will priority re-sending this over any 'even' slice. Under normal conditions this should not happen, but with a very low over-capacity, any interference or multi-path issue causing packets to be lost will introduce interpolation in one or more slaves. 

If you want, you can monitor the audio quality using the PS_AUDIO_STATS() command and looking at the SMPL_CONCEAL_COUNT16 and then mute your outputs when this is above your desired level. 

Regards, 
Kjetil

Hi Kjetil,

Kjetil said:

Is there an option for you to use the RC commands as an alternative to DSC or is critical information going from master to slave(s)?

There is lots of messages going in both directions so a lot of development using RC commands  for all types of messages different than standard RC (and of longer length)  would be required. And even that could be not sufficient since  if I understand well RC works only in direction slave -> Master ?

One more thing - RC still requires host-operation and I cannot find any other option that would differentiate between an RC and data channel config in the PPAth soft to affect robustness calculation ?

Kjetil said:

Now you can argue that 10% is a number set by us and you want to override this for various reasons. We tested this extensively and 10% was really the bare minimum we needed to maintain any reliable link for even the shortest period. Disabling this in your setup sounds like a bad idea, even though the slaves are close physically as I expect there to be people, and potentially moving, in proximity and multi-path effect come into play.

No intention to argue with your experience here but I am not sure what is worse - to live with a compromised performance that still can be sufficient or not to have the key functionality of a long-developed product

Kjetil said:

Interpolation is not configurable as this is built deep into our protocol and will occur every time a 'odd' sample is missing. We always give priority to 'odd' slices, and if any of the slaves does not acknowledge reception of 'odd' slices we will priority re-sending this over any 'even' slice. Under normal conditions this should not happen, but with a very low over-capacity, any interference or multi-path issue causing packets to be lost will introduce interpolation in one or more slaves. 

If you want, you can monitor the audio quality using the PS_AUDIO_STATS() command and looking at the SMPL_CONCEAL_COUNT16 and then mute your outputs when this is above your desired level. 

I shall try to look at the command PS_AUDIO_STATS(). Does interpolation is turned on in both cases 1) and 2) that you listed in the beginning ? Does it work this way that it happens automatically when a slave does  not reply and probably there is no room for retransmission and over a certain level of SMPL_CONCEAL_COUNT16 audio breaks begin ?

I am attaching a full config, I hope you can suggest a way out.

5670.PurePathProject.zip

Hi Pawel, 

There is lots of messages going in both directions so a lot of development using RC commands  for all types of messages different than standard RC (and of longer length)  would be required. And even that could be not sufficient since  if I understand well RC works only in direction slave -> Master ?

One more thing - RC still requires host-operation and I cannot find any other option that would differentiate between an RC and data channel config in the PPAth soft to affect robustness calculation ?

You are correct. RC only works in the slave -> master direction and would not be a viable option. The difference between RC and DSC is that the first is embedded into the header bytes already present in the timeslot and will not influence capacity for audio. DSC requires setting aside BW on top of the header bytes and will reduce the bandwidth available for audio and re-transmission of audio. 

I shall try to look at the command PS_AUDIO_STATS(). Does interpolation is turned on in both cases 1) and 2) that you listed in the beginning ? Does it work this way that it happens automatically when a slave does  not reply and probably there is no room for retransmission and over a certain level of SMPL_CONCEAL_COUNT16 audio breaks begin ?

Since audio breaks often is a combination of condition 1 and 2, there is no easy way to put a threshold on SMPL_CONCEAL_COUNT where the audio will break. In theory one can loose every other sample while still maintaining the audio link, but in practice this will hardly ever occur and you will be hit by a combination of burst and average packages dropped. 

No intention to argue with your experience here but I am not sure what is worse - to live with a compromised performance that still can be sufficient or not to have the key functionality of a long-developed product

I am attaching a full config, I hope you can suggest a way out.

Understand what you are saying. Did some calculations on your M1 cfg and you are precisely on the border (9% capacity, 2 re-transmission attempts). I will ask the guy behind the configurator how big a job it is to temporarily disable this check so that you can flash and test this for yourself, but this engineer is currently assigned to other tasks and no promise this can or will happen. 

In general I find it problematic that people do not test things with the right configurations earlier in the design phase. This exact configuration seems important to you and you are close to launch, but still have not tested the robustness and co-existence performance of your configuration? I want to put it out there that I do recommend doing these test as early as possible in a design phase to understand if PurePath Wireless can deliver the experience required in any application. 

Regards, 
Kjetil

Hi Kjetil,

I wanted to focus on a pragmatic solution and did not expect these kind of statements of insufficient testing on our side in this particular case, they are unfair and unjustified and rather those who are without sin should cast stones. 
Once it has appeared I would like to shortly clear it but in my view the forum might not be most suitable for this -  I do not have any other contact coordinates - can you contact me on my e-mail ?

Regards, Pawel

Hi Pawel, 

Please do not miss-judge this as a lack of willingness to find a pragmatic solution to this. My comment, although perhaps unfair in this particular case, was a 'in general' comment as posts here on E2E are read by others and there is lessons learned here on both sides. I might have become defensive as the first post from you had some strong wordings like 'very misleading and unfriendly' and 'clear contradiction' that I felt was slightly unfair as-well. 

Please apology the above.

I have reached out to you on email and we can take further discussions off-line.

Regards,

Kjetil