Switchable ADAT and SPDIF on optical

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
sflower
Member
Posts: 10
Joined: Thu Feb 16, 2012 6:27 pm

Switchable ADAT and SPDIF on optical

Post by sflower »

Hi there,

I'm currently working with the MC USB Audio board. I'd like to be able to switch the optical connectors between ADAT and SPDIF modes. Is this feasible to do this completely in software?

I can see that the sc_adat modules use 32bit buffered ports, and while SPDIF TX also uses 32bit buffers, the SPDIF RX is using 4 bit buffers. I've tried to make little changes to get ADAT RX working with a 4bit buffer, but so far this have been less than successful!

Thanks,
Steve


User avatar
Ross
XCore Expert
Posts: 966
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

sflower wrote:Hi there,

I'm currently working with the MC USB Audio board. I'd like to be able to switch the optical connectors between ADAT and SPDIF modes. Is this feasible to do this completely in software?

I can see that the sc_adat modules use 32bit buffered ports, and while SPDIF TX also uses 32bit buffers, the SPDIF RX is using 4 bit buffers. I've tried to make little changes to get ADAT RX working with a 4bit buffer, but so far this have been less than successful!

Thanks,
Steve
Can you confirm; you want ADAT or SPDIF available on a optical input, controllable from software?

If so, i strongly suggest you DO NOT try and modify the ADAT Rx code as it is well verified. Instead, kill off the S/PDIF thread, re-setup the port and call the ADAT code as required.
sflower
Member
Posts: 10
Joined: Thu Feb 16, 2012 6:27 pm

Post by sflower »

Ross wrote:Can you confirm; you want ADAT or SPDIF available on a optical input, controllable from software?
Thanks for your quick response Ross. Yep, that's exactly what I want to achieve.
Ross wrote:If so, i strongly suggest you DO NOT try and modify the ADAT Rx code as it is well verified. Instead, kill off the S/PDIF thread, re-setup the port and call the ADAT code as required.
Ok, thanks that has pointed me in the right direction I think. Am I right in thinking the only way to change the buffer at runtime is using the SETTW instruction?
User avatar
Ross
XCore Expert
Posts: 966
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

sflower wrote:
Ross wrote:Can you confirm; you want ADAT or SPDIF available on a optical input, controllable from software?
Thanks for your quick response Ross. Yep, that's exactly what I want to achieve.
Ross wrote:If so, i strongly suggest you DO NOT try and modify the ADAT Rx code as it is well verified. Instead, kill off the S/PDIF thread, re-setup the port and call the ADAT code as required.
Ok, thanks that has pointed me in the right direction I think. Am I right in thinking the only way to change the buffer at runtime is using the SETTW instruction?
No problem, yes SETTW is the correct instruction here. ( You may have to turn the port off/on.. see set_port_use_on() etc)

How do you propose to control this selection? Do keep us updated with your progress.

(An automatic selection of ADAT/SPDIF input would be cool wouldn't it...)
User avatar
Ross
XCore Expert
Posts: 966
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

Ross wrote:
(An automatic selection of ADAT/SPDIF input would be cool wouldn't it...)
Briefly had a think about this... and should be achievable with a little work.

The ADAT rx thread looks like this:

Code: Select all

while (1)
{
    adatReceiver48000(p_adat_rx, c_adat_rx);
    adatReceiver44100(p_adat_rx, c_adat_rx);
}
i.e. when the 48000 loop looses sync it calls the 44100 loop... Essentially auto-selecting between 44.1kHz and 48kHz.
Now, if the spdif rx function was called at this point then you would essentially have an auto select between ADAT and ADAT.

Some things that need considering:
- By default the SPDIF function does not terminate on lose of sync. However building with TEST defined will cause it to (see http://github.xcore.com/sc_spdif/api-rx.html "The function does not return unless compiled with TEST defined in which case it returns any time that it loses synchronisation" )

- You would have to consider how to communicate the nature of the current stream (i.e. ADAT or S/PDIF) to other parts of the system (should be easy)

- The SPDIF thread may loose lock very quickly (it has to try all the frequencies) so you may want to call that one in a loop to give it a bit more chance.

- Of course, you still need to sort the port config out... ;)

I'd be interested in any work you did in this area (both manual and automatic selection) and will provide assistance where I can. I've not seen an audio interface available with an auto-select before.
sflower
Member
Posts: 10
Joined: Thu Feb 16, 2012 6:27 pm

Post by sflower »

Hi Ross,

Sorry for being quiet for so long. Your suggestions were really interesting, but have so far I've not had much luck with them in the (little) time I've had to look at it over the last month.

The current state of plays is when I set the TEST define for SPDIF Rx, and put the Rx function call within an infinite loop, I have no solid clock available. It keeps returning from Rx function. If you have any other pointers that would be great. As soon as I comment out the TEST define it clocks correctly.

I had some success in changing the transfer width though - So even if we can't get automatic detection, we can change the input mode.

Thanks,
Steve
sflower
Member
Posts: 10
Joined: Thu Feb 16, 2012 6:27 pm

Post by sflower »

Bump!
lzg
New User
Posts: 2
Joined: Wed Apr 10, 2024 2:57 am

Post by lzg »

Hello poster and Ross, I am currently trying the output function of SPDIF and ADAT on the same port, but I was unsuccessful. I tried to restart a thread to execute SPDIF and ADAT related code, but unfortunately it failed. I would like to ask you what I need to do with this function and how to make SPDIF stop executing and then proceed with ADAT. I saw this post in 2024 and hope you will still be on this forum. I hope to receive your guidance.
User avatar
Ross
XCore Expert
Posts: 966
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

can you post your code? (or the relevant bit) - lib_spdif has changed considerably since this thread started and as such the information contained in the thread is likely out of date..
lzg
New User
Posts: 2
Joined: Wed Apr 10, 2024 2:57 am

Post by lzg »

I'm very sorry for not replying to you until now. I've been involved in some other things in recent days and I haven't been able to reply in time. I'm deeply sorry. The entire execution process of this part of the code in xmos has a large amount of code and may be confusing. I will I will send you my code execution process and the libraries I use. The libraries I use may not be the latest because there are obvious errors in them, but I have fixed them.
The SpdifTxWrapper() thread is called in the main function. At the same time, the sampling rate and XS1_CT_END signal are transmitted through the channel in the audio thread, audio data is transmitted in the deliver thread, and then the data in the channel is output in the SpdifTransmit() function.Image
You do not have the required permissions to view the files attached to this post.