Hello,
I am a long time user of XMOS, but new to implementing IEEE AVB. I am exploring a new product design that would like to receive 4 end-points (sinks) simultaneously. From those streams, I would like to listen to audio at 48k from two of the eight channels from each of the four streams (sinks) for a total of eight I2S outputs. I set the "avb_conf.h" to "#define AVB_NUM_SINKS 4" and when I compiled, I received a compile error that informs me that I am out of channel-ends. When I recompile with sinks set to 2, the error message is you are short one channel-end. (Of course, one sink works just fine.) It seems clear the code would like to cooperate, but I do not have enough resources.
I do not need talker functions on this receive-only device. In the header file, I set "#define AVB_1722_1_TALKER_ENABLED 0" but if seemed to not give up its channel_ends. If I could turn off the talker properly, I could hopefully reclaim the needed channel-ends and possible get to three or even four simultaneous end-points sinks and be on my way to a spectacular success.
The fundamental question: is there a way to compile a 1722.1 listener-only with no code for the talker and reclaim the talker's resources, especially the channel-ends.
Many thanks in advance for assistance on this.
IEEE AVB (1722.1) receiving multiple sinks
-
- Member
- Posts: 8
- Joined: Mon Aug 09, 2021 11:53 pm
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
Yes, there is. I have done the opposite for talker only and you can check out this topic: https://www.xcore.com/viewtopic.php?t=5833
I assume you need 4 sinks since you have 4 separate sources? Because if you could incorporate all your inputs into one input stream that would of course allow you to use a single sink. And then you should be able to reduce it to a single stream of 8 channels if that's all you're using (it will save some processing overhead, probably not a deal breaker but would be helpful if you went to a higher sampling rate).
I assume you need 4 sinks since you have 4 separate sources? Because if you could incorporate all your inputs into one input stream that would of course allow you to use a single sink. And then you should be able to reduce it to a single stream of 8 channels if that's all you're using (it will save some processing overhead, probably not a deal breaker but would be helpful if you went to a higher sampling rate).
-
- Member
- Posts: 8
- Joined: Mon Aug 09, 2021 11:53 pm
I believe the information from your earlier posts is all that I needed, just substituting talker for listener and some relatively minor surgery.
Per you comment, I wish that I could combine sources, but they are physically apart, so I do need to have four sinks (but could probably compromise with three.) At any rate, many thanks for your prompt and very helpful reply.
I will post my degree of success when I work my way thought this.
Cheers
Per you comment, I wish that I could combine sources, but they are physically apart, so I do need to have four sinks (but could probably compromise with three.) At any rate, many thanks for your prompt and very helpful reply.
I will post my degree of success when I work my way thought this.
Cheers
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
-
- Member
- Posts: 8
- Joined: Mon Aug 09, 2021 11:53 pm
The earlier post settings and code surgery indeed worked when inverted for removing talkers indeed of listeners. Now available RAM looms its head. We may have to step up to a larger XE216 and save some brain damage. I will post again when a conclusion is reached.
Many thanks again
Many thanks again
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
Fantastic, glad to hear it. Certainly I would propose XE216 as the appropriate part in this case. One thing that could help you out for code size is if you don't need to use 1GbE and can get away with 100Mbps (which will probably be sufficient for your needs from what I can see) that would allow you to save some cores, chanends, and RAM. https://www.xcore.com/viewtopic.php?t=4731
-
- Junior Member
- Posts: 7
- Joined: Wed Aug 11, 2021 7:28 pm
so just a quick note when configured for 2 listeners this way, i noticed in xscope the buffer_Manager_to_tdm no longer runs, my first simple debugging was to place a few print statements to see where things break down. i get to the while loop but never see a send/receive msg.
i used to get these even when listener wasnt connected. is the buffer mgr deadlocked or any suggestions would be appreciated here.
i used to get these even when listener wasnt connected. is the buffer mgr deadlocked or any suggestions would be appreciated here.
-
- Member
- Posts: 8
- Joined: Mon Aug 09, 2021 11:53 pm
Well, after much hard work freeing up channel ends and memory resources (with this board's very helpful advice), the AVB manager accepted the configuration for three streams (all sinks). The system connected to the first stream and glorious music poured forth from the output. However, when an attempt was made to connect to the second stream, the first stream was closed before the connection was made to the second.
It does not seem logical that only one stream can be serviced at a time as long as resources are available. For testing, only a single channel is used per stream, so there is no strain on FIFO's or I2S connections. Assuming that sufficient resources are available, of course, is there a secret handshake to keep open the connection to one stream while opening another or two?
(For reference, we are employing the XE216-512.)
It does not seem logical that only one stream can be serviced at a time as long as resources are available. For testing, only a single channel is used per stream, so there is no strain on FIFO's or I2S connections. Assuming that sufficient resources are available, of course, is there a secret handshake to keep open the connection to one stream while opening another or two?
(For reference, we are employing the XE216-512.)
-
- Member
- Posts: 8
- Joined: Mon Aug 09, 2021 11:53 pm
Well, apologies to this forum. My last post was a false alarm. An oversight occurred in a config file and, once corrected, the system did behave as one would expect. Now glorious music pours forth from three sinks to three I2S outputs.
On the XE216-512, four sinks may be too much, but three definitely work. If there were only some way to steal some RAM from the other tile. Otherwise, the XE232-1024 will likely provide the full capability that we are seeking.
Thanks again for the earlier support which cleared the way to ultimate success.
On the XE216-512, four sinks may be too much, but three definitely work. If there were only some way to steal some RAM from the other tile. Otherwise, the XE232-1024 will likely provide the full capability that we are seeking.
Thanks again for the earlier support which cleared the way to ultimate success.
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
Glad to hear you got this working. Nice work.