Hello DiyAudio community,
TL;DR: This is a USB transport for audio output (up to 8ch) and input (2ch for now) and user device control (e.g., DSP management) from PC (MacOS/Linux/Windows) thru I2C/GPIO. Including bootloader for remote firmware update, flexible device configuration, HID interface, multiple audio output options, integration with SigmaStudio (simultanious audio playback and ADAU DSP configuration). Compact module available in USB-C and USB-B versions, isolated or non-isolated.
Latest docs, config tool, link to buy:
http://york.eclipsevl.org/
So, the story started when I needed a USB transport for audio output and another channel for device control, such as for managing DSP.
Last time, I solved this problem using a USB hub and a USB to Serial converter. This way, I assembled the required interface from 4 chips:
https://www.diyaudio.com/community/threads/audio-transport-module-york.406025/
(first post)
I tried to combine everything into one XMOS chip. This was also a working solution, but there was a big problem with the availability of the chips, especially in the desired package.
Thus, developing the transport on the pic32mz seemed the most logical to me. The first prototype module was based on Dortonyan’s project from Vegalab: in terms of circuitry, it almost completely repeated the original project and was designed for two-channel audio output, plus a serial interface. During testing of the firmware based on the original source code, several problems were identified when working in different OSs. The serial port was also not fully implemented.
I posted my version of the firmware with fixes in the original thread and on GitHub: https://github.com/eclipsevl/york_pic32mz_uac2_osfw/
After that, I continued working on the functions I needed. The following features were implemented:
1. Bootloader. Necessary for firmware updates via USB, without a programmer.
2. Flexible device configuration using a PC utility (which is also used for firmware updates).
3. HID interface for transmitting service information and device configuration. Initially, I planned to use the serial port, but HID is much more suitable.
4. Serial interface, which can be optionally enabled.
5. Various additional audio output options: s/pdif, 8-channel TDM, dual i2s (for using some DACs channel-by-channel in mono mode). Recently I also added support for old dacs with clock/data/latch interface. I.e. direct connection to dac ICs such as AD1862/PCM1702 etc is also possible without glue logic.
6. Various clocking options: module oscillators, external clock (slave mode), internal PLL clocking.
7. I2C port and library for integration with SigmaStudio: for simultaneous audio input/output and DSP ADAU programming.
This last feature is currently a unique combination and fits well into DSP projects: https://www.diyaudio.com/community/threads/freedsp-octavia.393804/page-18#post-7625685
The configuration and firmware update utility looks like this:
Device name and PID/VID settings
Audio interface settings:
Input of up to 2 PCM channels, up to 192kHz (384kHz with external clocking at 1024fs)
Output of 2 PCM channels, up to 192kHz
(384kHz with external clocking)
Output of 8 channels in TDM8 mode (up to 96kHz, clocked by PLL)
Output of 8 channels in 2xI2S mode
Output of 2 S/PDIF channels, up to 192kHz clocked by PLL
And of course, in the simplest version, this module can work similarly to any USB interface, in slave or master mode.
DSD has not been tested yet.
Photo of the module, second version.
The additional 4-pin connector can be configured as i2c/uart/gpio, and is also used for forced entry into the bootloader (in case of unsuccessful software update).
Available in two versions: USB-C and USB-B. The transport itself is quite compact: it fits into an area of about 2x2 cm - which is important for integration into other devices.
So I'm working on a smaller PCB with same functionality.
Later I'm going to release a software library to basically enable anyone to create their own app for PC to control custom devices: toggle GPIO of USB module/send I2C transactions.
The module is available with USB-B or USB-C, the price is 49 Euro.
For purchase PM me. Also available on Tindie:
Multichannel USB UAC2+HID+CDC interface York
I'm open for requests for additional features but whether it is going to be added to the firmware depends on hardware limitations and time required to implement it.
Latest version of config tool:
https://york.eclipsevl.org/york_config_tool.zip
P.S. Huge thanks to:
1. Alexey (Dortonyan) for publishing the project. His work laid the foundation, and without it, this project would never happen.
2. Beta testers of the first version: @CyberPit, @Ludilu
UPD Oct 28th 2024:
Documentation draft attached
UPD Feb 17th 2025:
Latest docs, config tool, link to buy:
http://york.eclipsevl.org/
TL;DR: This is a USB transport for audio output (up to 8ch) and input (2ch for now) and user device control (e.g., DSP management) from PC (MacOS/Linux/Windows) thru I2C/GPIO. Including bootloader for remote firmware update, flexible device configuration, HID interface, multiple audio output options, integration with SigmaStudio (simultanious audio playback and ADAU DSP configuration). Compact module available in USB-C and USB-B versions, isolated or non-isolated.
Latest docs, config tool, link to buy:
http://york.eclipsevl.org/
So, the story started when I needed a USB transport for audio output and another channel for device control, such as for managing DSP.
Last time, I solved this problem using a USB hub and a USB to Serial converter. This way, I assembled the required interface from 4 chips:
https://www.diyaudio.com/community/threads/audio-transport-module-york.406025/
(first post)
I tried to combine everything into one XMOS chip. This was also a working solution, but there was a big problem with the availability of the chips, especially in the desired package.
Thus, developing the transport on the pic32mz seemed the most logical to me. The first prototype module was based on Dortonyan’s project from Vegalab: in terms of circuitry, it almost completely repeated the original project and was designed for two-channel audio output, plus a serial interface. During testing of the firmware based on the original source code, several problems were identified when working in different OSs. The serial port was also not fully implemented.
I posted my version of the firmware with fixes in the original thread and on GitHub: https://github.com/eclipsevl/york_pic32mz_uac2_osfw/
After that, I continued working on the functions I needed. The following features were implemented:
1. Bootloader. Necessary for firmware updates via USB, without a programmer.
2. Flexible device configuration using a PC utility (which is also used for firmware updates).
3. HID interface for transmitting service information and device configuration. Initially, I planned to use the serial port, but HID is much more suitable.
4. Serial interface, which can be optionally enabled.
5. Various additional audio output options: s/pdif, 8-channel TDM, dual i2s (for using some DACs channel-by-channel in mono mode). Recently I also added support for old dacs with clock/data/latch interface. I.e. direct connection to dac ICs such as AD1862/PCM1702 etc is also possible without glue logic.
6. Various clocking options: module oscillators, external clock (slave mode), internal PLL clocking.
7. I2C port and library for integration with SigmaStudio: for simultaneous audio input/output and DSP ADAU programming.
This last feature is currently a unique combination and fits well into DSP projects: https://www.diyaudio.com/community/threads/freedsp-octavia.393804/page-18#post-7625685
The configuration and firmware update utility looks like this:
Device name and PID/VID settings
Audio interface settings:
Input of up to 2 PCM channels, up to 192kHz (384kHz with external clocking at 1024fs)
Output of 2 PCM channels, up to 192kHz
(384kHz with external clocking)
Output of 8 channels in TDM8 mode (up to 96kHz, clocked by PLL)
Output of 8 channels in 2xI2S mode
Output of 2 S/PDIF channels, up to 192kHz clocked by PLL
And of course, in the simplest version, this module can work similarly to any USB interface, in slave or master mode.
DSD has not been tested yet.
Photo of the module, second version.
The additional 4-pin connector can be configured as i2c/uart/gpio, and is also used for forced entry into the bootloader (in case of unsuccessful software update).
Available in two versions: USB-C and USB-B. The transport itself is quite compact: it fits into an area of about 2x2 cm - which is important for integration into other devices.
So I'm working on a smaller PCB with same functionality.
Later I'm going to release a software library to basically enable anyone to create their own app for PC to control custom devices: toggle GPIO of USB module/send I2C transactions.
The module is available with USB-B or USB-C, the price is 49 Euro.
For purchase PM me. Also available on Tindie:
Multichannel USB UAC2+HID+CDC interface York
I'm open for requests for additional features but whether it is going to be added to the firmware depends on hardware limitations and time required to implement it.
Latest version of config tool:
https://york.eclipsevl.org/york_config_tool.zip
P.S. Huge thanks to:
1. Alexey (Dortonyan) for publishing the project. His work laid the foundation, and without it, this project would never happen.
2. Beta testers of the first version: @CyberPit, @Ludilu
UPD Oct 28th 2024:
Documentation draft attached
UPD Feb 17th 2025:
Latest docs, config tool, link to buy:
http://york.eclipsevl.org/
Last edited:
Would adding SPDIF IN be a big effort? its the only obvious feature missing I see. Of course adding an SPDIF receiver chip is not a big challenge.
It is something I was thinking about too, even put a S/PDIF TOSLINK receiver on the test board.
I also did some basic experiments and in theory it looks possible. However, I can't guarantee that it will work. Main challenge is shortage of computational resources.
If there will be any updates regarding this, I'll post it in this thread.
With additional chip - yeah, it is a no-brainer 🙂
I also did some basic experiments and in theory it looks possible. However, I can't guarantee that it will work. Main challenge is shortage of computational resources.
If there will be any updates regarding this, I'll post it in this thread.
With additional chip - yeah, it is a no-brainer 🙂
I'm not sure how an non-synchronous clock from an external SPDIF source would impact everything inside. (my head spins. . .) Adding an SPDIF receiver chip might be a much better use of resources since its a complex function. Otherwise it looks really interesting. Would the code work on a low power variant of the processor for mobile applications?
Yes, that's one of the two main issues. The only solution I found is to implement a FIFO and dynamically add/drop samples depending on the fill rate. Or try to play with MCU's PLL (but clock quality would not be good).
I just did a quick test, with active playback it takes ~75-80mA from USB (with one oscillator enabled).
What is possible to do is to try to power down all unused peripherials (not sure how much it can save actually) and try to switch to lower clock for the core.
There is no lower power option for this MCU, this one is in smallest package and lowest flash size. What Idd are you looking for?
I just did a quick test, with active playback it takes ~75-80mA from USB (with one oscillator enabled).
What is possible to do is to try to power down all unused peripherials (not sure how much it can save actually) and try to switch to lower clock for the core.
STM32 MCUs have FW for SPDIF input but no support for synchronization to I2S output (SAI). FIFO helps but buffer under/overrun will eventually happen resulting in data errors (samples added or dropped). But this is a common issue with most FIFO devices for SPDIF input. ASRC works better in this sense.
I'm looking at potential headphone applications among other uses and power is a real issue in mobile stuff. Thanks for checking, The SPDIF in is a bigger problem as expected. The only realistic option might be a receiver chip and switch clocks to the recovered clock.
You're right. Unfortunately, there is no enough processor time to implement ASRC.
Do you also want to include SPDIF in the same mobile application?
One more option to save power is to use buck converter instead of LDO. Currently it burns 1.7*0.08 = 136mW out of total 400mW.
Hi,
I've been using the York Pico from @eclipsevl for a few weeeks now, along with the FreeDSP Octavia from @CyberPit , and I'm thrilled with it. The configuration tool works flawlessly, and I've tried both the I2S 2-channel input and the 8-channel TDM input. Currently, I use it primarily as an input from my computer instead of Amanero). There are a lot of modes, adding a bunch of inputs/outputs to the DSP.
Probably the best feature for me is having I2C and I2S over a single USB. Since I'm still developing the application in SigmaStudio, I need to reprogram frequently, and the York Pico seems the most suitable for this. Using a Raspberry Pi and TCP had its issues (programming the EEPROM didn't work, reading large amounts of data didn't work), and the USBi converter required two cables (Amanero + programmer), which was also not ideal. Now, I can send I2S and I2C data to the ADAU via a single USB 🙂. I highly recommend it 🙂
Thanks, Tom
I've been using the York Pico from @eclipsevl for a few weeeks now, along with the FreeDSP Octavia from @CyberPit , and I'm thrilled with it. The configuration tool works flawlessly, and I've tried both the I2S 2-channel input and the 8-channel TDM input. Currently, I use it primarily as an input from my computer instead of Amanero). There are a lot of modes, adding a bunch of inputs/outputs to the DSP.
Probably the best feature for me is having I2C and I2S over a single USB. Since I'm still developing the application in SigmaStudio, I need to reprogram frequently, and the York Pico seems the most suitable for this. Using a Raspberry Pi and TCP had its issues (programming the EEPROM didn't work, reading large amounts of data didn't work), and the USBi converter required two cables (Amanero + programmer), which was also not ideal. Now, I can send I2S and I2C data to the ADAU via a single USB 🙂. I highly recommend it 🙂
Thanks, Tom
Thank you, Tom! 🙂
Couple of updates about the firmware.
1. I've implemented USB<->UART bridge (virtual com port), it now can be enabled from the config tool:
If enabled, the device will be seen composite VCP+Audio interface:
And the UART will be available on 4 pin header. I did ran many tests to check function with big chunks of data, among them - flashing of ESP32. No issues.
2. DSD output. So far, I've only tested output of DoP DSD64 stream. In case if DSD stream is detected, dsd pin goes high and DSD data streamed on sd and wck pins, bit clock - on bck. Main issue with tests of higher rates is software, I could not get it working on any other transports I have as well. Going to try it on Linux.
3. I've realised that in fact current hardware can output 8 channels not only in TDM but also as 4xI2S streams (1xWCK, 1xBCK, 4xSDO). So for next firmware I'm adding such option.
One more option is output for NOS DACs, with left and right channels streamed on different pins, 16/18/20/24/32 bits data width:
Couple of updates about the firmware.
1. I've implemented USB<->UART bridge (virtual com port), it now can be enabled from the config tool:
If enabled, the device will be seen composite VCP+Audio interface:
And the UART will be available on 4 pin header. I did ran many tests to check function with big chunks of data, among them - flashing of ESP32. No issues.
2. DSD output. So far, I've only tested output of DoP DSD64 stream. In case if DSD stream is detected, dsd pin goes high and DSD data streamed on sd and wck pins, bit clock - on bck. Main issue with tests of higher rates is software, I could not get it working on any other transports I have as well. Going to try it on Linux.
3. I've realised that in fact current hardware can output 8 channels not only in TDM but also as 4xI2S streams (1xWCK, 1xBCK, 4xSDO). So for next firmware I'm adding such option.
One more option is output for NOS DACs, with left and right channels streamed on different pins, 16/18/20/24/32 bits data width:
Excuse the dumb question, but did you somehow implement the XMOS functionality inside a PIC?
4x stereo out via I2S is just what the doctor ordered. And these can be streamed via USB with 96 kHz or higher?
4x stereo out via I2S is just what the doctor ordered. And these can be streamed via USB with 96 kHz or higher?
Short answer is yes but to be more accurate, such functions do not necessary require XMOS MCUs. It can be done on PIC/AVR/STM32.
192kHz with 512fs masterclock and up to 384kHz with 1024fs.
The on-board oscillators are 512fs now (can be replaced by 1024fs) but most of high-quality applications have their own clocks on the board (like Crystek or something like that). The module can be configured to use external clock.
Wow, this really sounds like a swiss pocket knife. Is this UAC2 to windows? So will it appear as WDM 8-channel out? Or does one go through ASIO?
Is there a documentation page so I don't have to bother you with all these questions?
Is there a documentation page so I don't have to bother you with all these questions?
I'm still working on it but for now I don't mind questions 🙂
Tested in multichannel D-Class amplifier with ADAU DSP. Configuration used: 8ch TDM output + I2C to configure ADAU from PC with Sigmastudio.
Post: https://www.diyaudio.com/community/...-dsp-bluetooth-aux.376006/page-2#post-7720371
Post: https://www.diyaudio.com/community/...-dsp-bluetooth-aux.376006/page-2#post-7720371
Yes. In this mode the data comes out from following pins:
SD - ch 1,2
WCK - ch 3,4
F0 - ch 5,6
F2 - ch 7,8
BCK or F3 - bit clock
F1 - word clock
New firmware is available, 2.1 (build 1170)
New version of the config tool:
https://drive.google.com/file/d/1KD0tD1A-tqQU4ZUBEmwYzT9An9vlKMAg/view?usp=drive_link
Updates: 8 channel (4xI2S) output option is added.
New version of the config tool:
https://drive.google.com/file/d/1KD0tD1A-tqQU4ZUBEmwYzT9An9vlKMAg/view?usp=drive_link
Updates: 8 channel (4xI2S) output option is added.